云服务器内容精选

华为云首页用户手册

使用ServiceComb引擎

微服务引擎 CSE-业务场景治理:创建治理策略

创建治理策略登录微服务引擎控制台。在左侧导航栏选择“ServiceComb引擎专享版”。单击待操作的引擎。选择“业务场景治理”。当ServiceComb引擎版本为2.0.0及以上且小于2.4.0时，选择“微服务治理”。未开启安全认证的ServiceComb引擎，请执行6。开启安全认证的ServiceComb引擎，请执行5。在弹出的“安全认证”对话框输入账号名及其密码，单击“确定”。首次连接ServiceComb引擎，请输入root账号名及创建ServiceComb引擎时输入的密码。创建账号请参考新增账号。在“治理策略”页签，单击“创建治理策略”。选择治理方式，单击“创建治理”，设置参数。限流参数名称参数说明治理策略名称输入治理策略的名称。业务场景设置治理策略适用的业务场景：单击“选择业务环境”，选择已创建好的业务场景名称。单击“创建业务场景”，创建业务场景。单位请求数设定请求数及时间段的值。当限流对象对当前服务实例的设定时间段内的请求数量超过设定的值，超过部分将会被限流，返回错误码429。重试参数名称参数说明治理策略名称输入治理策略的名称。业务场景设置治理策略适用的业务场景：单击“选择业务环境”，选择已创建好的业务场景名称。单击“创建业务场景”，创建业务场景。响应错误码选择响应错误码，用于定义哪些错误类型会触发重试。重试次数设置重试次数。重试策略选择重试策略：固定间隔重试：重试间隔时间固定。指数间隔重试：采取指数退避算法确定重试间隔时间。重试间隔时间设置重试的间隔时间。 “重试策略”选择“固定间隔重试”：设置重试的固定间隔时间。 “重试策略”选择“指数间隔重试”：设置重试的基准时间、时间单位（s/ms）。隔离仓参数名称参数说明治理策略名称输入治理策略的名称。业务场景设置治理策略适用的业务场景：单击“选择业务环境”，选择已创建好的业务场景名称。单击“创建业务场景”，创建业务场景。最大并发数根据实际系统的实际业务处理能力，设置业务的最大并发数。阻塞计时设置阻塞计时时间及单位（s/ms）。当请求超出最大并发数时，超出阻塞计时时间范围后，该请求会被丢弃。熔断参数名称参数说明治理策略名称输入治理策略的名称。业务场景设置治理策略适用的业务场景：单击“选择业务环境”，选择已创建好的业务场景名称。单击“创建业务场景”，创建业务场景。熔断范围滑动窗口类型选择滑动窗口类型。时间：时间窗口。请求数：请求数量窗口。滑动窗口大小设置滑动窗口的大小。 “滑动窗口类型”为“时间”：最近n秒/分钟时间范围内的调用会被记录和统计。 “滑动窗口类型”为“基于计数”：最近n次的调用会被记录和统计。其中，n为您设置的滑动窗口的大小。调用次数基线设置调用次数基线，即开启统计调用错误率至少需要达到的调用数量。例如，设置“调用次数基线”为10，为统计错误率，则至少要记录10个调用。熔断开启条件错误率阈值熔断勾选“错误率阈值熔断”时生效，设置“错误率阈值”，即调用错误的百分比。当调用错误率不小于错误率阈值时，发生熔断，返回响应码429。慢请求熔断勾选“当慢请求达到您定义的比例时，开启熔断”时生效，设置以下参数：慢请求定义：慢请求阈值定义，响应时间超过该阈值的请求都是慢请求。慢请求比例：慢请求阈值，达到指定的慢请求比例时，发生熔断，返回响应码429。单击“创建”，治理策略开始生效。在治理策略列表，单击业务场景所在行的：单击治理策略所在行“操作”列的“启用策略”，可启动已关闭的治理策略，使治理策略生效。单击治理策略所在行“操作”列的“关闭策略”，可关闭已启动的治理策略。单击治理策略所在行“操作”列的“编辑”，可对治理策略进行编辑。单击治理策略所在行“操作”列的“删除”，可删除已关闭的治理策略。

微服务引擎 CSE 使用ServiceComb引擎
微服务引擎 CSE-业务场景治理:治理策略说明

治理策略说明支持限流、熔断、重试和隔离仓等策略的配置，具体说明见下表。治理策略名称说明限流面对流量风暴，或可预知的流量冲击，对非重点业务场景进行限流，防止瞬时流量过大造成服务和数据崩溃，导致服务不可用。重试当服务遇到一些非致命性的错误（如偶尔超时）时，可以通过重试的方式来避免服务的最终失败。隔离仓面对大规模并发流量风暴，或可预知的流量冲击，对并发流量进行控制，防止瞬时并发流量过大造成服务和数据崩溃，导致服务不可用。熔断当某业务场景的错误率超过设定阈值时，为了保证整体业务系统的可用性，在此后的一分钟内该业务场景下的所有请求会被拒绝。然后再以50%的比率接受服务请求并统计业务的错误率，直至该业务场景下的错误率降低到设定阈值以下。

微服务引擎 CSE 使用ServiceComb引擎
微服务引擎 CSE-Mesher简介:什么是Mesher

什么是Mesher Mesher是Service Mesh的一个具体的实现，是一个轻量的代理服务以Sidecar的方式与微服务一起运行。 Service Mesh是由William Morgan定义： Service Mesh是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，Service Mesh保证请求可以在这些拓扑中可靠地传输。在实际应用当中，Service Mesh通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但应用程序不需要知道它们的存在。随着云原生应用的崛起，Service Mesh逐渐成为一个独立的基础设施层。在云原生模型里，一个应用可以由数百个服务组成，每个服务可能有数千个实例，而每个实例可能会持续地发生变化。服务间通信不仅异常复杂，而且也是运行时行为的基础。管理好服务间通信对于保证端到端的性能和可靠性来说是非常重要的。 Service Mesh实际上就是处于TCP/IP之上的一个抽象层，假设底层的L3/L4网络能够点对点地传输字节（同时，也假设网络环境是不可靠的，所以Service Mesh必须具备处理网络故障的能力）。从某种程度上说，Service Mesh有点类似TCP/IP。TCP对网络端点间传输字节的机制进行了抽象，而Service Mesh则是对服务节点间请求的路由机制进行了抽象。Service Mesh不关心消息体是什么，也不关心它们是如何编码的。应用程序的目标是“将某些东西从A传送到B”，而Service Mesh所要做的就是实现这个目标，并处理传送过程中可能出现的任何故障。与TCP不同的是，Service Mesh有着更高的目标：为应用运行时提供统一的、应用层面的可见性和可控性。Service Mesh将服务间通信从底层的基础设施中分离出来，让它成为整个生态系统的一等公民——它因此可以被监控、托管和控制。

微服务引擎 CSE Mesher使用ServiceComb引擎指南