《21天转型微服务实战营》 学习笔记

《21天转型微服务实战营》 学习笔记

1 微服务架构知识介绍

• 微服务简介
• 容器与容器平台
• 微服务架构模式
• 微服务开发框架
• Service Mesh
• 微服务平台

1.1 什么是微服务

• 微服务架构是一种架构模式，它要求开发者以一种不同于以往的开发方式进行软件开发，设计功能比较单一，拥有接口的服务，他们都可以被独立的构建，测试，部署。

• 微服务是得益于DevOps文化的发展，持续集成工具的成熟，越来越多的公司向敏捷转型，微服务架构模式可以指导企业开发出具有可伸缩，弹性，高可用的系统，从以往的几个月的上线频率，缩短为几周甚至几天。

• 传统软件是由单一服务构成，微服务提倡将一个软件按照功能模块进行划分。

1.2 为什么使用微服务

• 独立运行：服务异常不再彼此影响，必要时将非核心功能隔离，不影响主要功能运转。一个服务实例崩溃不会影响其他实例，整体系统依然正常。按功能伸缩，当某个模块算力需求变化时只进行该功能实例的伸缩，而不是整个系统的伸缩，减少资源浪费。

• 独立升级：一个小特性的更改或者bug fix不会影响大部分功能的正常运转

• 代码复用：一套代码可以用于不同的独立系统中，在公司内部或者开源社区中进行分享。比如，支付服务，用户管理服务，认证鉴权。

• 技术演进：单体服务使用陈旧的技术，想象你过去使用struts1+spring，你想升级struts2来获得一定的收益，接着你想整体切换到Spring MVC,彻底摆脱struts框架，不断地切换框架为工程稳定性带来风险，而陈旧的框架又无人维护。而微服务项目不受旧代码拘束。

• 语言限制：当你发现某个新功能更适合使用Go而不是java时该怎么办，Java也不是万金油，每种语言都有适合自己的场景，微服务使开发者能根据服务场景选择语言。招聘开发者也不必局限于语言

• 团队：小团队运作更加敏捷，配合紧密，开发周期短，组织扩张灵活

1.3 微服务面临的挑战

1.3.1 具体挑战

1. 持续集成：大量的工程，需要一个持续集成工具自动完成编译，打包，发布，部署等工作
2. 版本管理：大量的版本，就会遇到兼容性问题。你需要让项目可控
3. 文档管理：版本在持续升级，服务接口不匹配。你需要一个文档管理系统，并让开发者严格遵守文档进行开发
4. 生命周期管理：服务运行期，需要一个平台管理服务，除了部署，启停，还要能够在服务崩溃时自动拉起服务
5. 运维：运维人员操作服务，查看指标，日志，分布式调用链，更改配置项都由于微服务架构而变得比以往更加复杂
6. 调试：在开发期你如果依赖于很多微服务，如何方便地在本地去调用依赖的服务。
7. 网络调用：从过去本地的内存栈调用变为了网络调用，不再可靠
8. 安全：如何控制不让未经授权的调用者访问到自己的数据
9. 如何云服务化：转型微服务涉及一系列的工作，处理以上复杂的问题需要大量的基础代码研发，如何能驾驭诸多的技术和文化变更

1.3.2 构建微服务系统是困难的

1.4 容器与容器平台

容器的出现帮助了微服务技术体系的成熟，这是至关重要的一环

容器和微服务是天生一对，在过去的虚拟机时代中，VM的启停甚至长达数分钟，在进行弹性伸缩时，假设你设置了这样的伸缩条件“CPU负载高于80%时，新增一台机器“，那么很可能在你没有得到一台新机器前，现存的VM中的服务就已经被压垮，继而引发级联崩溃。

1.5 微服务模式

1.5.1 微服务模式—注册发现

1.5.2 微服务模式—路由管理

微服务A已经根据微服务名查询到了相关的实例信息并放置于本地内存，如上图表格，那么如何决定自己到底要选择哪一批实例进行访问呢？
可以看到每个实例都具有一定的属性，上表中有2个属性版本与数据中心。那么编写算法根据微服务名和属性筛选服务实例，最终就可以决定要访问的服务实例的集合了

1.5.3 微服务模式—客户端负载均衡

当在路由过程中决定了一个实例集合后，就可以对集合实行负载均衡算法，选择其中一个实例访问，即客户端负载均衡，区别于nginx这样的传统负载均衡组件，负载均衡直接在客户端，也就是你的业务进程内部进行。

1.5.4 微服务模式—熔断

当服务发生错误，超时等问题，系统需要将这部分非核心功能隔离，以免引起级联崩溃上图，Service1，调用api2，访问service4完成一个业务，当这个api2出现死锁时，将引起下游未做超时处理服务沾满线程池，最终大范围瘫痪，导致其他功能失效，想想如果更加庞大的系统，是一个多大的灾难，异常将被放大。如果能够在访问api2达到一定超时次数就将api2隔离掉，不再发生网络调用，那么就不再产生新的死锁，系统稳定性就会提升

道理就像战舰的隔离仓，当遇到漏水的船舱时要将有问题的船舱隔离以避免灾难蔓延。

1.6 开发框架

要完成以上的功能需要在微服务中编写代码，而这些代码都可以作为通用库来提供，这就是微服务开发框架。

开发者引入框架并学习开发方式，配置方式，就可以快速开发出具备微服务特性的应用。我们称这种模式为chassis，华为云提供java-chassis与go-chassis 2种语言框架，供用户选择。

1.7 Service Mesh

Service Mesh同样解决微服务面临的问题，但是以另一种结题思路完成的我们在第7层使用各种开发框架，如传统开发框架Spring MVC， 微服务开发框架java-chassis，go-chassis等等，编码时直接调用。

2 微服务入门之编写

•开发第一个微服务
•服务契约
•开发服务调用者

2.1 开发第一个微服务

创建一个空的maven工程，然后在pom文件中加入如下依赖：

创建一个简单的CSEJavaSDK微服务只需要引入cse-solution-service-engine包，但我们仍然推荐大家使用管理依赖依赖，这在项目依赖关系复杂时可以有效降低依赖管理复杂度。

2.2.1 创建一个main类

CSEJavaSDK使用的默认日志组件是Log4J，并在此基础上进行了一些默认的配置，可以开箱即用。

2.2.2 创建服务的REST接口类

• 一个微服务可以有多个接口契约。这里使用@RestSchema注解声明HelloService是一个契约id为hello的REST接口，同时会在启动时生成相应的契约。

• 这里的REST接口是以Spring MVC风格开发的。CSEJavaSDK支持的开发风格有REST(JAX-RS、Spring MVC）和RPC，开发者可以自由选用。

• 在src\main\resources\目录下创建一份microservice.yaml文件
  

2.1.3 运行AppMain类

可以在ServiceStage的微服务控制台看到provider服务

2.2 发布

调用http://127.0.0.1:8080/provider/v0/hello/Bob，可以得到provider服务的应答

2.3 服务契约

点击provider服务的记录查看详情，我们能看到一份服务契约。

服务契约描述了微服务的接口，是在启动过程中由CSEJavaSDK根据微服务REST接口类（这里是HelloService.java）自动生成的。如果你观察一下provider服务的启动日志，会发现在日志里也将生成的契约打印出来了。

服务契约不仅仅是一份接口文档，它也约束了CSEJavaSDK运行时接收请求和返回应答的行为。
CSEJavaSDK使用的服务契约是Swagger契约，用户可以从网上搜索到相关资料。关于REST接口定义的约束，可以参考接口定义和数据类型。

TIPS：

• 服务契约描述了服务的接口，因此契约内容的变化可以认为是服务接口变化了。在正式的生产环境中这应该是不允许随意发生的。
• 修改provider服务的接口，重启服务，可以发现服务启动失败，因为它的契约与服务中心中保存的契约不一致。
• 如果碰到这种问题，在正式的生产环境中推荐的处理方式是在microservice.yaml文件中升级微服务版本；开发环境也可以考虑删除服务中心里的provider服务记录，或者配置service_description.environment=development。

2.4 开发微服务调用者

开发一个consumer服务来调用provider服务，pom.xml文件和main类完全相同，定义一个REST接口类接收外部请求并调用provider服务：

• CSEJavaSDK支持JAX-RS、Spring MVC和RPC三种开发风格，一般我们推荐用户使用前两种，配合CSEJavaSDK自动生成服务契约的能力开发更方便。
• CSEJavaSDK提供了两种微服务调用方式，RPC方式和RestTemplate方式。
  consumer服务的microservice.yaml文件与provider服务基本一致，但是注意它的服务名称需要改为“consumer” ，服务监听地址改为“0.0.0.0:9090” 。
  启动consumer服务，可以在ServiceStage的微服务控制台看到consumer服务。调用consumer服务的两个接口，可以看到通过RPC方式和RestTemplate方式都能够成功调用provider。
  
  

3 感知微服务和CSE的交互

•服务中心
•配置中心
•monitor
•通过代理连接CSE服务

3.1 支撑微服务运行的服务

在microservice.yaml文件中，我们配置了三个地址，微服务启动的时候，会从配置文件中读取这些地址，分别连接华为云微服务引擎（Cloud Service Engine，CSE）的三个服务：
•服务中心（service center，sc）
•配置中心（config center，cc）
•monitor

3.2 服务中心

服务中心提供了微服务注册、管理、发现功能。
•当一个provider微服务实例启动时，会将自己的服务信息、实例信息等注册到sc。
•当consumer服务需要调用provider时，会去sc查询provider的服务契约、实例列表等信息，将请求发往实例列表中记录的实例。
•没有服务中心，微服务无法实现相互调用，因此服务中心是微服务实例启动时必须要连接的服务。

配置项

3.3 配置中心

•配置中心提供了存储、管理配置项的功能。
•通过连接配置中心，微服务可以获得运行时动态变更配置的能力。
•服务治理功能的配置也是由配置中心下发的。
•配置中心客户端包含在org.apache.servicecomb:config-cc包中。

配置项

3.3 monitor

monitor服务允许微服务实例上报吞吐量等数据，并在CSE的服务治理页面上展示相关数据。Monitor功能包含在com.huawei.paas.cse:cse-handler-cloud-extension包中。

配置项

3.4 通过代理连接CSE服务

如果开发调试环境无法直接连接华为云CSE服务，CSEJavaSDK也提供了代理配置，允许通过代理连接sc/cc/monitor服务。参见代理设置。
代理配置在microservice.yaml文件中，示例如下所示：

4 微服务实例的生命周期分析

•服务启动流程
•服务发现
•服务退出

4.1 服务启动流程

一个微服务实例在启动过程中主要经历的流程有：
•初始化日志框架
•加载本地配置（包括System Property、环境变量、配置文件）
•实例化Spring Bean
•初始化SCBEngine
•注册服务

4.1.1 注册服务的流程

•当env为默认环境或production环境时，不允许出现服务实例本地与sc上的服务契约不一致的情况（一旦契约不一致会走左图中的红色路径）
•env=development时，服务实例会将不一致的接口契约注册到sc，覆盖sc上原有的契约（如下图）

4.1.2 微服务实例注册到sc

当微服务实例注册到sc上去后，启动流程完成。如果有一些操作需要在服务启动完成时执行，可以定义一个org.apache.servicecomb.core.BootListener去监听事件，并在接收到AFTER_REGISTRY事件时触发操作的执行。

4.2 服务发现

Consumer服务调用provider服务时，需要去服务中心查询provider服务的契约、实例列表等信息，然后才能对provider发起调用：
•查询条件包括AppID、serviceName、environment、versionRule，如果碰到consumer端找不到provider服务的问题，除了检查provider服务的实例有没有注册到sc，还需要检查这四个配置项是否有问题
•查询到provider端服务信息后，consumer会从sc下载该provider服务的全部契约，加载到本地
•Consumer端加载provider服务信息的过程发生在consumer第一次调用该provider的时候，如果consumer服务的实例在启动后一直没有调用provider，则它一直不会去sc查询和加载provider服务信息

4.3 服务退出

CSEJavaSDK向JVM注册了一个shutdown hook，以实现优雅停机，在JVM进程退出时进行一系列的清理操作，其中包括：
•向服务中心注销本实例
•停止接收请求，并等待已接受的请求处理完成
由于JVM的限制，要确保优雅停机功能正常触发，需要用户正常停止JVM进程，而不能强制杀进程。以Linux操作系统为例：
•kill ${PID} 的方式停止微服务进程可以触发优雅停机
•kill –0 ${PID} 的方式强制停止微服务进程则不会触发优雅停机

异常情况

如果微服务实例遭遇异常情况，没有调用sc接口注销自身实例就停止运行。sc会通过感知心跳超时的方式下线实例。前面的课程中提到微服务连接sc的配置中有心跳时间间隔和允许连续心跳失败次数这两个配置，假设心跳时间间隔为t，允许心跳失败次数为n，则sc检测到实例连续心跳失败n+1次的时候下线实例，从实例异常退出到sc下线实例的时延T的取值范围是tn < T <t(n+1) ，按照默认值计算为90-120秒

5 教你如何配置你的微服务

• microservice.yaml配置文件
• 环境变量、System property
• 动态配置
• 通过API获取配置
• 日志配置

5.1 microservice.yaml配置文件

微服务实例启动时会从classpath下加载microservice.yaml配置文件：
• 如果多个jar包下都有microservice.yaml文件，那么他们都会被加载
• 磁盘目录下的microservice.yaml配置文件的优先级高于jar包内的配置文件
• 可以通过在microservice.yaml文件内配置servicecomb-config-order来指定优先级

5.2 环境变量、System property

微服务实例启动时也会从环境变量、系统属性中加载配置

• Linux系统的环境变量不允许有点号”.”，但CSEJavaSDK框架会自动将配置项key
中的下划线映射为点号，因此我们可以将点转换为下划线来配置环境变量
• 环境变量的优先级高于配置文件，system property的优先级高于环境变量

5.3 动态配置

微服务实例连接配置中心后，可以从配置中心获取动态配置

• 动态配置的优先级是最高的，并且可以在运行时刷新
• 服务治理所使用的诸多控制逻辑也是由配置项来控制的。实现服务动态治理的方
式就是通过配置中心动态下发配置项

5.4 通过API获取配置

CSEJavaSDK使用统一的API来获取配置，用户使用配置的时候，不需要关心从环
境变量或者配置中心来读取配置，框架已经自动为用户从各个配置来源读取配置，
并根据优先级规则将所有配置进行了合并和覆盖。

优先级： 动态配置> system property > 环境变量> 配置文件

5.4.1 代码

将provider服务的sayHello方法的应答的前缀从固定的"Hello,"改为从配置项获取：

5.4.2 添加配置

在microservice.yaml文件中加上配置：
此时启动服务进行调用，情况如下

将provider服务的详情页面配置hello.sayHelloPrefix=Hi,，再次调用服务发现应答已
经产生变化：

5.5 日志配置

5.5.1 默认值

• CSEJavaSDK默认使用的日志框架是Log4j，并且给出了一份默认的配置，在
org.apache.servicecomb:foundation-common包的log4j.properties文件内。

5.5.2 如何配置

• CSEJavaSDK提供了accesslog功能，可以在传输方式为REST over Vertx的条件
下使用，accesslog默认也是基于Log4j打印的，配置文件在
org.apache.servicecomb:transport-rest-vertx包的log4j.properties文件内。
• 如果要覆盖默认的日志配置，在项目的resources/config目录下配置一份
log4j.properties文件即可。

6 CSE实战之开发网关

•使用DefaultEdgeDispatcher开发网关服务
•使用URLMappedEdgeDispatcher开发网关服务

6.1 EdgeService网关介绍

EdgeService是CSEJavaSDK提供的网关服务。网关服务可以作为微服务系统的边界，对外提供REST接口，将用户发送的RESTful请求转发给内部微服务。

EdgeService预置了默认的请求转发模块，可以根据简明的规则将请求转发到后端微服务，也允许用户开发更复杂的自定义规则转发机制。

EdgeService本身也是一个微服务，开发和配置方式与普通的微服务类似。用户可以通过扩展机制在EdgeService中定制各种业务功能。

6.2 使用DefaultEdgeDispatcher开发网关服务

6.2.1 开发

开发一个EdgeService网关服务所需引入的maven配置与开发普通微服务基本一致，只是需要多引入一个edge-core包的依赖：

定义服务的main类和microservice.yaml配置文件

•Main类的定义与普通微服务完全相同
•microservice.yaml配置文件与普通微服务基本相同，只是需要额外增加一些请求转发规则的配置

6.2.2 启动服务

启动edge、provider、consumer服务，通过edge分别调用provider和consumer，调用成功：

6.3 使用URLMappedEdgeDispatcher开发网关服务

除了DefaultEdgeDispatcher，CSEJavaSDK也提供了URLMappedEdgeDispatcher，允许用户指定请求URL和微服务的映射关系。
使用URLMappedEdgeDispatcher开发EdgeService的方法和使用DefaultEdgeDispatcher基本一致，只在microservice.yaml中的请求转发规则上有所不同。

启动成功

启动edge、provider、consumer服务，通过edge分别调用provider和consumer，调用成功：

6.4 EdgeService网关转发机制

•由前文可以看出，DefaultEdgeDispatcher的配置较为简单，但对于EdgeService接收的请求URL格式有一定的要求；URLMappedEdgeDispatcher的转发规则较为灵活，但配置相对更繁琐一点。
•推荐用户在设计微服务的时候预先规划好各微服务的请求URL格式，可以减少后期服务演进过程中碰到的接口兼容性问题。

7 CSE实战之框架扩展机制

• Handler扩展机制
• Filter扩展机制
• 异常转换扩展机制
• 请求处理流程简介

7.1 Handler扩展机制

Handler机制工作于用户业务代码接收REST请求之前和发送REST请求之后，支持
默认/服务两个级别的配置。

多个handler之间是链式工作的，每个handler的handle方法处理完成后，由下一个
handler继续处理该次请求。

7.1.1 开发一个Handler

这里在provider服务里开发了一个
handler，该handler会检查调用
sayHello方法的请求：
• 如果name是stranger，则返回
403错误
• 如果是其他名字则允许调用

注意：handle方法内要么调用
Invocation#next方法将请求向后传
递；要么调用AsyncResponse的各
种方法终止请求处理流程，返回一
个应答。但是绝不能存在逻辑分支，
既不向后传递请求，也不返回应答，
这样会将该请求挂住，导致请求无
法发往下游服务。

7.1.2 配置文件

这里在provider服务里开发了一个
handler，该handler会检查调用
sayHello方法的请求：
• 如果name是stranger，则返回
403错误
• 如果是其他名字则允许调用
注意：handle方法内要么调用
Invocation#next方法将请求向后传
递；要么调用AsyncResponse的各
种方法终止请求处理流程，返回一
个应答。但是绝不能存在逻辑分支，
既不向后传递请求，也不返回应答，
这样会将该请求挂住，导致请求无
法发往下游服务。

要想使用自定义的Handler，首先用户需要在
resources/config/目录下放置一份cse.handler.xml配置
文件，并在其中声明自己的handler的ID和handler类型。

7.1.3 使用handler

要在handler链中加载并使用handler，还需要在microservice.yaml配置文件中显式
声明handler链的配置，将demo-handler加进去。

在一开始搭建微服务时引入的cse-solution-service-engine包内带有一份默认的
handler链配置，大家可以打开这个包观察一下它提供的microservice.yaml配置文件。

为了不损失原有的功能，我们复制一份默认的provider端handler链配置，并将自己
的demo-handler加在handler链的开头。

7.1.4 启动provider服务

调用它的sayHello方法，如果传入的名字不是stranger，则
provider返回200的响应；如果传入的名字是stranger，则provider返回403响应。

7.2 Filter扩展机制

• Filter机制有两个接口，即HttpServerFilter和HttpClientFilter。
• Filter扩展机制工作于Handler扩展机制的外层，HttpServerFilter在provider端
handler前工作，HttpClientFilter在consumer端handler后工作。
• Filter机制只有全局级别的生效范围。

HttpServerFilter

HttpServerFilter中的常用方法介绍如下：

HttpClientFilter中的常用方法介绍如下：

7.2.2 开发一个HttpServerFilter

现在我们在edge服务中定义一个HttpServerFilter：

这里的Filter的目的是从请求中获取名为
LetStrangerPass的header，将其存入
InvocationContext中向下游的provider服务传递。

当provider服务的DemoHandler从
InvocationContext中取出LetStrangerPass并且
其值为true时，就允许stranger请求访问sayHello
方法。

7.2.3 定义一份SPI配置文件

为了edge服务能够加载该filter，我们还需要定义一份SPI配置文件：

SPI机制（Service Provider Interface）是一种JDK内置的服务提供发现机制。
开发者扩展了哪个接口，那么对应的SPI配置文件的名字必须是与该接口相同的，文件的内容是该接口的实现类的名字。

7.2.4 DemoHandler的逻辑

我们修改一下provider服务中的DemoHandler的逻辑，如果能从InvocationContext
中取出LetStrangerPass，并且其值为true，则允许stranger访问sayHello方法：

7.2.5 完成

通过edge调用provider时，如果设置header
LetStrangerPass=true，则使用name=stranger
的参数也可以调用sayHello方法。

7.3 异常转换扩展机制

如果用户的业务代码抛出了InvocationException异常，则框架会将
InvocationException中的data直接序列化为响应消息的body。如果是其他的异常，
则返回的响应消息状态码为490/590，响应body为CommonExceptionData。

我们也提供了异常转换扩展机制，允许用户捕获不同类型的异常后，将其转换为响应消息：

• 该机制允许按优先级排列和选取异常转换器
• 可以定义特定类型的异常转换器，转换该类型及其子类的异常

7.3.1 开发

我们来定义一个IllegalArgumentException的转换器作为例子。

首先我们在provider服务的greeting方法中增加一个检查，如果person参数的属性缺
失，则抛出一个IllegalArgumentException。

7.3.2 greeting方法

调用provider服务的greeting方法，不传name字段，可以看到provider服务返回的状
态码是590，错误信息是Cse Internal Server Error，此时请求错误的信息没有展示
出来。

7.3.3 IllegalArgumentException的转换器

现在我们来定义一个针对IllegalArgumentException的转换器

7.3.4 SPI配置文件

ExceptionToProducerResponseConverter的扩展类也是通过SPI机制加载的，因此
需要定义一份SPI配置文件

7.3.5 greeting方法

再次调用provider服务的greeting方法，此时响应消息是转换后的错误信息

7.4 请求处理流程简介

一个请求发送到某微服务，触发服务执行业务逻辑，调用下游服务方法的总体流程如图所示。

• Filter机制只有全局作用范围，Handler机制有全局和服务级作用范围

• 注意异常转换扩展捕获异常的位置，如果异常不是由业务逻辑抛出，而是由Handler等抛出的，则不在它的处理范围内

• Handler由handler.xml定义加载，Filter和异常转换机制由SPI机制加载，这些机制的实现类都不是由Spring Bean机制加载和管理的，因此Autowired等Bean自动注入功能无法在这些扩展类里使用

• 如果要在这些扩展类里获取Spring Bean，可以考虑使用BeanUtils#getBean方法，但要注意获取时机不能太早，否则可能对应的Spring Bean还没有被Spring框架实例化

• EdgeService网关服务只有consumer端handler，没有provider端handler

8 CSE实战之负载均衡

• 负载均衡策略
• 请求重试机制
• 实例隔离机制

8.1 负载均衡策略

8.1.1 介绍

CSEJavaSDK的负载均衡机制是客户端负载均衡：
• 微服务实例启动时会将自己的实例信息（包括IP、端口号等）注册到sc，并且通过心跳机制维持本实例的在线状态。

• consumer定时去服务中心查询provider的实例（第一次查询发生在consumer第一次调用provider的时候，之后默认30秒去sc查一次），并缓存在本地。

• consumer调用provider时会通过负载均衡机制从缓存的provider实例列表中选取一个作为本次请求发送的地址。

• 内置的负载均衡策略有RoundRobin、Random、WeightedResponse、SessionStickiness，其中默认使用的是RoundRobin。

8.1.2 启动consumer实例

启动一个consumer实例，三个provider实例，调用consumer的greeting方法，可以看到consumer默认是使用RoundRobin策略调用三个provider的。连续调用consumer6次，三个provider的日志记录分别是：

从时间顺序上可以看出，consumer服务的6次请求是由三个provider实例轮流处理的。

8.1.3 登录后台

登陆ServiceStage页面，依次点击“应用开发”->“引擎列表”->“控制台”->“服务治理”，在应用选择下拉框里选择“Training21Days-HelloWorld”，进入该应用的治理页面

8.1.4 consumer服务

在服务治理页面的右边点击选择consumer服务，将其负载均衡策略修改为“随机”

重新调用consumer的greeting方法，可以看到三个provider实例接收greeting请求的分布情况变为随机的了

8.2 请求重试机制

当遭遇网络连接超时、实例下线等问题时，consumer服务默认会尝试选择下一个provider服务实例进行调用，来尽量保证业务调用的成功。

• 默认的重试机制配置是retryOnSame=0,retryOnNext=1，即在同一个provider实例上重试零次，选择下一个provider实例重试一次

• 并不是所有的错误都会让consumer端进行重试，具体判断逻辑请参考ServiceComb-Java-Chassis中的DefaultRetryExtensionsFactory类

• 默认的重试机制配置在cse-solution-service-engine包的microservice.yaml文件中

8.2.1 模拟

我们可以模拟一下实例意外停止的场景来测试重试机制。
强制停止一个provider实例（注意不要是正常退出，否则触发实例优雅停机的话我们的可用时间窗口太短），然后调用consumer的greeting方法：

可以看到，虽然有的请求花费的时间长一点，但是仍然会调用成功的。如果观察consumer服务的日志，可以发现，有时候consumer会选取那个被强制关闭的provider实例，但是在抛出java.net.ConnectException: Connection refused 异常后，consumer会向另一个provider实例发送请求并调用成功。

8.3.2 治理

在治理页面上我们可以动态地调整重试机制的配置，治理页面的重试机制名为容错。大家可以在页面上选择一下容错策略为Failover，前往consumer服务的详情页面查看配置项

8.3.4 配置项

从配置项页面可以看到，Failover策略就是默认的tryOnSame=0，tryOnNext=1策略。

Tips:
大家可以在页面上尝试一下其他的几种重试策略。CSE的大部分治理策略都是通过配置项管理的，在治理页面上进行治理操作后，可以到这里查看对应的配置项。

8.4 实例隔离机制

如果consumer在调用某个provider实例时频繁报错，则consumer会将该provider实例隔离，等待一段时间后再尝试向其发送请求。

• 默认隔离规则是连续5次调用某实例失败后隔离该实例
• 默认隔离60秒后将被隔离实例放回可选provider实例列表中，但当次请求是否被路由到该实例仍取决于路由策略的选择
• 如果尝试对被隔离实例进行调用时失败了，则该实例立即重新进入隔离状态，等待下一个60秒重试机会；调用成功则从隔离状态恢复
• 并非所有的调用失败都会计入实例隔离的判断机制里

8.4.1 模拟

我们仍然启动一个consumer实例、三个provider实例，先调用consumer的方法，测试consumer会正常地将请求路由到三个provider实例上去。

接着强制关闭一个provider实例，连续调用consumer服务，可以看到consumer在调用强制关闭的provider实例几次之后，将这个实例隔离并且不再调用了。

实例隔离触发机制除了连续调用失败，还有错误率阈值。但在某些问题场景下，出错实例会积累很高的错误率。

此时如果要让每隔60秒的尝试调用机制将错误率慢慢拉低到阈值以下，来解除实例的隔离状态，会花费相当长的时间。因此我们推荐大家使用默认的连续调用失败机制判断实例隔离，方便问题实例的快速隔离和正常实例的快速恢复。

8.5 小结

• CSEJavaSDK的负载均衡策略是客户端负载均衡，默认策略是轮询

• 重试策略可以在provider端实例意外退出、网络断连时保证consumer端业务调用不出错。默认的重试策略是tryOnNext=1,tryOnSame=0

• 实例隔离机制可以快速将问题实例从consumer端的实例缓存列表中排除，减小业务调用受问题实例影响的概率

• 今天的课程所讲的内容都在ServiceComb开源文档中有说明，推荐阅读：https://docs.servicecomb.io/java-chassis/zh_CN/referenceshandlers/
loadbalance.html

9 CSE实战之服务治理

• 限流策略
• 服务熔断
• 服务降级
• 灰度发布

9.1 限流策略

• CSEJavaSDK支持客户端和服务端的限流策略，限制每秒钟最大请求数

• 支持default、微服务、schema（契约）、operation（接口）限流四个粒度的限流

• 治理页面支持的是服务端微服务级限流配置

• 限流策略是实例级限流，例如，配置provider服务的服务端流控为1000QPS，如果有两个provider服务实例，则他们可以接收共计2000QPS的流量

9.1.1 如何配置

在provider服务上配置限流策略为对edge服务限流至1QPS，通过edge服务连续调用consumer和provider服务。

观察provider服务中打印的日志，可以看到每秒钟provider只处理一次来自edge服务的请求，其他请求都以429状态码返回的。而对于来自consumer的请求，provider正常处理并返回200状态码。

9.2 服务熔断

• 对于一个分布式系统，如果某个请求的调用链中的某个服务出现故障，响应变慢，会导致整个链路的响应变慢，请求堆积。

• 当这种情况变得越来越严重的时候，占用的资源会越来越多，到达系统瓶颈，造成整个系统崩溃，所有请求都不可用。

9.2.1 基本介绍

• 熔断可以将问题服务隔离开，令请求可以快速返回

• 待问题服务变为正常状态后，再从熔断状态中恢复过来

通过这种机制，我们可以临时断开次要业务路径，保障系统整体的可用性。

9.2.1 手动熔断

熔断可以手动开启，也可以自动开启。其触发方式不同，但效果相同。

这里我们选择edge服务，手工熔断其调用consumer服务的sayHello方法的路径。

通过edge服务调用consumer服务的sayHello方法和greeting方法，可以看到sayHello方法已经调不通了，但greeting方法仍然能够调通

9.2.2 自动熔断

我们也可以在页面上配置自动熔断规则。默认的自动熔断规则需要在10秒内存在20次以上的调用，错误率达到50%时触发熔断，在我们的实验中较难触发。

这里我们将熔断规则改为：
• 熔断效果维持30秒
• 错误率达到50%时触发熔断
• 10秒内有3个以上的请求时开始判断错误率

为了避免实例隔离机制对熔断现象的干扰，我们这里将实例隔离关闭。

TIPS：这里对熔断机制、隔离机制的调整是为了更方便地展示熔断的现象，并不是推荐的配置。如果您对于微服务熔断能力还不熟悉，建议先维持默认配置，在实践中根据实际需求再进行调整。

9.3 服务降级

这里讲的降级策略是指服务调用出错时的处理策略，可以对应参考ServiceComb文档资料中的降级策略的容错配置。

CSEJavaSDK提供两种降级策略，即抛出异常和返回null，默认为抛出异常

为了让降级的效果更明显，我们将降级策略修改为returnnull

9.3.1 请求超时

可以看到，当edge调用consumer超时时，返回的响应不再是490错误，而是200，消息体为空熔断发生后，edge服务返回的也是空消息体

9.3.2 触发熔断

9.4 灰度发布

• CSEJavaSDK支持灰度发布功能，可以实现版本平滑过渡升级

• 支持按百分比引流和按请求参数特征引流两种方式

9.4.1 新建灰度测试

9.4.2 验证发布效果

为了验证灰度发布的效果，我们开发一个0.0.2版本的provider服务，它的sayHello方法会根据时间返回不同的问候信息。

修改sayHello方法后，升级provider服务为0.0.2版本来启动provider服务

将新旧版本的provider服务各启动一个实例，在
治理页面看到的微服务情况如左图所示
此时通过edge连续调用sayHello方法，应该是新
旧两个版本的应答交替返回，即两个版本的
provider服务实例都是可用的服务实例，在轮询
策略下依次被调用

9.4.3 自定义灰度规则

进入provider服务的详情页面->灰度发布页面，点击添加发布规则，添加如
左图所示的自定义灰度规则

10 CSE实战之微服务线程模型和性能统计

• 线程模型简介
• 性能统计（Metrics）

10.1 线程模型简介

ServiceComb（CSEJavaSDK）是基于Vert.x开发的。

Vert.x是一个依赖Netty，具有异步非阻塞特点的框架，它是CSEJavaSDK高性能的基础，但也让CSEJavaSDK的线程模型看上去与传统的服务框架有所不同。

CSEJavaSDK线程模型的说明可以参考开源文档，使用CSEJavaSDK原生的默认开
发方式时，其传输方式为Rest over Vertx传输方式。

10.1.1 同步模型

原生的CSEJavaSDK框架开发的微服务默认工作于同步模式，传输方式为Rest over Vertx模式，基于Vert.x进行网络通信。

在此模式下，左图中橙色的部分是在网络线程中处理的，该部分逻辑代码是异步的，以避免阻塞网络线程；蓝色的部分是在业务线程池中处理的，可以是同步代码。

10.1.1.1服务端方面

当请求到达微服务实例时，首先是网络线程从网络连接中接收到请求，经过一些处理后切换到业务线程运行provider端handler链、HttpServerFilter、用户的业务逻辑。

切换到业务线程后，网络线程就可以去处理下一个请求了。这样可以使网络线程一直处于处理请求的状态，开发者要避免做阻塞网络线程的操作，如访问数据库、以同步逻辑代码发送REST请求等。

10.1.1.2 客户端方面

客户端方面，业务线程发送请求时，首先会在业务线程中对请求做一些处理（包括consumer端handler链、HttpClientFilter），然后转移到网络线程中进行发送。在等待应答的过程中，业务线程会一直处于阻塞状态。等到网络线程返回应答后，会通知业务线程继续运行后面的逻辑。

10.1.2 reactive模型

除了同步模式，CSEJavaSDK也支持Reactive模式，该模式下所有的处理逻辑都运行在网络线程中。为避免阻塞网络线程，provider端服务接口代码和consumer端调用代码都需要是异步风格的。

Reactive模式的开发较为复杂，用户有兴趣的话可以查阅ServiceComb-Java-Chassis的资料了解相关信息。

Reactive在性能方面有着巨大的优势，但是却并非完美无缺的。它最大的问题就是要求整个项目的代码都运行于异步非阻塞的状态。一旦有一些第三方系统只有同步接口，比如某些数据库驱动三方件，那么这些地方的调用就不能直接放在业务逻辑中，否则会造成网络线程阻塞，性能打折扣。而即使使用线程池将其隔离，也会因为线程上下文的切换而带来额外开销。同时，异步风格的代码有违一般开发人员的习惯，写出来的代码可能不如传统的同步风格代码那么容易理解、调试和定位问题。

因此，是否使用Reactive模式进行开发，需要设计和开发人员结合实际情况进行取舍。

10.2 性能统计

CSEJavaSDK自带了一个简单好用的性能统计模块，只需要在maven依赖中引入metrics-core即可使用：

为开启metrics日志打印功能，还需要在microservice.yaml文件中配置：

TIPS：由于引入metrics-core模块会增加两个契约healthEndpoint和metricsEndpoint，分别描述的是健康检查和性能数据的REST接口，因此需要删除服务中心里的旧服务记录以更新契约。

11 CSE实战之使用CSEGoSDK开发微服务

•开发CSEGoSDK微服务
•开发CSEGoSDK服务调用者

11.1 准备工作

创建一个新的GO项目从华为云上下载CSEGoSDK压缩包，并解压到项目的vendor下

11.2 创建Rest接口

我们创建一个struct，名为XXX,然后创建XXX的Hello方法，该法必须参数为*restful.Context

11.3 编写urlpatterns

11.4 创建一个main.go

在main.go中我们需要将我们刚刚创建的Service进行注册

在main.go中使用chassis.RegisterSchema方法进行注册，使用chassis.Init()进行初始化，使用chassis.Run()进行启动服务，CSEGoSDK支持rest协议和grpc协议，开发者可以自由选择

在main.go同级目录下创建conf目录，并在conf目录下创建下chassis.yaml和microservice.yaml文件

11.5 运行main.go

可以在ServiceStage的微服务控制台上可以开到server-demo 服务

注意：如果直接使用IDE启动，需要配置环境变量CHASSIS_HOME=/{path}/{to}/demo/service/

至此，你已经使用CSEGoSDK成功开发出了微服务。调用http://127.0.0.1:9090/provider/v0/hello/Bod，得到server以下的回复

12 CSE实战之CSEGoSDK场景实战

• 熔断
• 限流
• 容错
• 灰度

12.1 熔断

熔断：该功能在服务运行时，能很好的隔离上游服务。在熔断的保护下，如果请求错误过多，服务将停止对该服务访问。

12.1.1 熔断支持：

12.1.1.1 全局配置

该配置对所有的服务的所有请求都起作用，只要服务任何一个接口达到熔断条件将导致该服务所有接口都被熔断隔离。

12.1.1.2 服务级别配置

此时熔断只对所配置的服务器作用，没有配置的服务将使用默认配置或全局。此时与全局类似，某个服务的一个接口导致熔断也会影响其他接口不同正常使用。

12.1.1.3 API级别配置

API级别的配置仅对API生效，即使同一个服务API之间互相不影响。如/hello接口发生错误导致熔断，/hi接口依旧可以正常使用

12.1.2 配置示例

12.1.2.1 全局配置示例

12.1.2.2 服务级别配置示例

12.2 限流

12.2.1 介绍

用户可以通过配置限流策略限制Provider端或Consumer端的请求频率，使每秒请求数限制在最大请求量的大小。其中Provider端的配置可限制接收处理请求的频率，Consumer端的配置可限制发往指定微服务的请求的频率。使用是，需要添加以下handler ：provider添加ratelimiter-provider，consumer添加ratelimiter-consumer。

12.2.2 配置

限流配置在rate_limiting.yaml中，同时需要在chassis.yaml的handler chain中添加ratelimiter-provider。其中qps.limit.[service] 是指限制从service 发来的请求的处理频率，若该项未配置则global.limit生效。Consumer端不支持global全局配置，其他配置项与Provider端一致，handler chain添加ratelimiter-consumer。

12.2.3 配置演示

• consumer端
  
  

• provider端
  
  

12.3 容错

在CSEGoSDK提供自动重试的容错能力，用户可配置retry及backOff策略自动启用重试功能

12.3.1 类型

默认情况下CSEGoSDK支持三种容错类型

• zero：固定重试时间为0的重试策略，即失败后立即重试不等待
• constant：固定时间为backoff.minMs的重试策略，即失败后等待backoff.minMs再重试。
• jittered：按指数增加重试时间的重试策略，初始重试时间为backoff.minMs，最大重试时间为backoff.MaxMs。推荐此方法

12.3.2 配置实例

12.4 灰度发布

应用于AB测试场景和新版本的灰度升级等相关场景。CSEGoSDK通过对路由的管理实现以上场景，以下重点讲述CSEGoSDK如何通过router的管理实现灰度发布。

12.4.1 路由管理

路由策略可应用于AB测试场景和新版本的灰度升级，主要通过路由规则来根据请求的来源、目标服务、Http Header及权重将服务访问请求分发到不同版本的微服务实例中。

12.4.2 配置路由管理

路由管理使用router.yaml进行配置。同时也支持API方式进行设置，本文并不介绍，推荐使用router.yaml进行配置。

12.4.3 路由规则说明

• 匹配特定请求由routeRule.{targetServiceName}.match配置，匹配条件是：source（源服务名）、source tags及headers，另外也可以使用refer字段来使用source模板进行匹配。
• Match中的Source Tags用于和服务调用请求中的。sourceInfo中的tags进行逐一匹配。
• Header中的字段的匹配支持正则、=、!=、>、<、>=、<=七种匹配方式。
• 如果未定义match，则可匹配任何请求。
• 转发权重定义在routeRule.{targetServiceName}.route下，由weight配置。
• 服务分组定义在routeRule.{targetServiceName}.route下，由tags配置，配置内容有version和app。

13 CSE实战之异构技术栈相互调用

• 启动CSEJavaSDK开发的provider
• 启动CSEGoSDK开发的consumer互相调用

13.1 启动consumer和provider

13.1.1 provider启动

首先我们运行基于CSEJavaSDK的provider服务，并且启动edge服务。成功运行后请在ServiceStage下确保服务已成功注册。

13.1.2 consumer启动

将consumer的监听端口改为8081。同时我们也需要为Day11中的demo配置契约文件。契约可以在你启动Java后，在ServiceStage上获取，进入服务详情后，点击服务契约并选择Yaml显示,如下图:

13.2 调用CSEGoSDK consumer

调用127.0.0.1:8000/rest/consumer/v0/hello?name=Alice 调用成功后，查看Javaprovider日志，如果成功看到下图证明成功。

查看Day6中的edge日志。下面日志为同时启动了Java和Go的consumer

成功访问后，可以看到以下访问日子

14 CSE实战之其他服务何如接入CSE

• 创建springboot服务(默认熟练运用springboot)
• 为Springboot服务绑定mesher
• CSEGoSDK开发的provider和consumer

14.1 创建springboot服务

创建一个maven项目，引入springboot所需的jar包，为了方便测试，该服务需要具有两个接口一个作为服务提供者接口，另外一个作为客户端接口，该服务将和使用CSEGoSDK开发的服务端和客户端进行访问。

14.2 绑定mesher

在创建好springboot服务后，我们需要为刚刚创建好的绑定一个mesher，在绑定mesher之前，我们需要将springboot的代理设置为mesher的监听地址。本文通过Java的ProxySelector进行代理设置

14.2.1.从华为云下载mesher，请点击mesher下载

下载解压如下：

14.2.2 mesher配置

修改microservice.yaml,将服务名修改为springboot，并新增APPLICATION_ID：Training21Days-HelloWorld

14.3 启动mesher:

除了使用mesher提供的启动脚本启动外我们亦可以直接运行mesher.exe(mesher)，在运行之前，我们需要设置环境变量SPECIFIC_ADDR,SPECIFIC_ADDR支持格式：rest:port,grpc:port，http:port。可同时写两个如下，设置后运行mesher.exe(mesher)。
e.g.
export SPECIFIC_ADDR=rest:80

修改完并启动mesher后，可以在serverstage下看到如下

14.4 开发CSEGoSDK服务

我们在Day11时已经开发了provider和consumer，此时我们可以直接使用

• 修改Day11中的consumer访问服务名为springboot

同时按照Day11的启动方式将Day11的provider和consumer进行启动

14.5 访问服务

访问springboot服务的consumer接口，/consumer/v0/{path}。调用http://127.0.0.1:9091/consumer/v0/hello/Bod,反馈结果

15 微服务云应用平台介绍

•ServiceStage是什么
•ServiceStage的使用场景
•ServiceStage的应用案例

15.1 ServiceStage是什么

ServiceStage是集华为全面云化转型成功经验和技术创新成果为一体的一站式应用云平台，面向企业提供EI、区块链、微服务、移动和Web类应用开发的全栈解决方案，帮助用户快速创建企业级云原生应用，加速业务创新。

15.2 企业基于ServiceStage可以快速构建行业应用

15.3 场景一：微服务开发和管理

• 基于契约(Open API)的开发模式：让微服务的开发、测试、文档、协作和管控活动标准化、自动化
• 高性能REST/RPC微服务开发框架：打包了微服务注册、发现、通信和治理等基础能力，开箱即用
• 一站式微服务治理控制台：提供微服务负载均衡、限流、降级、熔断、容错、错误注入等治理能力
• 提供ServiceComb、Spring Cloud、ServiceMesh商业版

15.4 场景二：Web应用快速开发和部署

支持Java、PHP、Node.js、.NET、Go、Python 等等。开发者只需轻松编写代码即可。

开发者只需使用ServiceStage+任意源码仓库，通过流水线功能实现轻松部署和更新。

15.5 场景三：持续集成和持续交付

基于ServiceStage流水线全流程“自助式”开发、集成、验证与上线

15.6 场景四：灰度发布

什么是灰度发布：为保障新特性能平稳上线，可以通过灰度发布功能选择少部分用户试用，降低发布风险。更安全的发布方式，让业务上线不仅仅是快。

16 微服务应用开发之本地工具

•微服务框架简介
•本地轻量化服务中心简介
•Mesher简介
•远程调试工具简介
•密钥生成工具简介
•本地轻量化微服务引擎简介
•Eclipse ServiceStage插件简介

16.1 微服务框架之CSE Java SDK

16.1.1 基本介绍

CSE Java SDK开发微服务(简称CSE)，可以最大化的简化开发门槛，提升产品上线速度。同时可以获得微服务运行时高可靠性保证、运行时动态治理等一系列开箱即用的能力。

CSE支持使用调用链(对服务的调用进行监控),支持使用仪表盘(查看自己的运行相关数据),还支持使用分布式事务TCC、文件上传等。

不仅我们强大的ServiceComb应用可以接入到我们CSE中去,连我们众所周知的Spring Cloud应用也可以方便的接入到CSE提供的基础服务。

16.1.2 接入CSE服务有如下好处

1. 开发者可以专注于业务系统的开发，把精力从中间件的可靠性评估、集群部署、运维监控等复杂的事情中解放出来。
2. 实现业务快速交付和敏捷开发。利用PaaS平台，根据业务规模，动态的调整资源使用，降低业务风险。

16.2 微服务框架之CSE GoSDK

CSE(Cloud Service Engine) Go Chassis是华为推出的产品级微服务开发框架。使用CSE Go Chassis开发微服务，可以最大化的简化开发门槛，提升产品上线速度。同时可以获得微服务运行时高可靠性保证、运行时动态治理等一系列开箱即用的能力。

16.3 本地轻量化服务中心

LocalServiceCenter是CSE微服务框架的注册中心,记录了服务和服务地址的映射关系,在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用。本地轻量化服务中心可用于本地开发调试，其作用相当于是本地起的一个Eureka。

有容器版本，Windows版本和Linux版本，用户可以根据自己的场景选择合适的版本

16.4 Mesher

Mesher是Service Mesh的一个具体的实现，是一个轻量的代理服务以Sidecar的方式与微服务一起运行。

Service Mesh是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，Service Mesh保证请求可以在这些拓扑中可靠地传输。在实际应用当中，Service Mesh通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但应用程序不需要知道它们的存在。

16.5 远程调试工具

云上调试（CloudDebug）主要用于支撑华为云的租户调试人员对单个集群内微服务实例中的Java程序进行远程调试。（是一个eclipse插件,可以直接在eclipse上操作,对集群的微服务进行查询和调试）

16.5.1 查询功能

可对集群内所有的微服务进行查询，查询结果展示在插件UI界面中的“Service List”中。针对某一微服务，查询属于该微服务的所有实例名和实例的集群内IP地址，并将查询结果展示在插件UI界面中的“Instance List”中。

16.5.2 远程调试功能

CloudDebug主要设计用于对华为云ServiceStage租户集群内微服务实例中的Java程序进行远程调试，支持所有通用Java调试功能，如程序断点、变量查看、堆栈查看等。

16.6 密钥生成工具

密钥生成工具是一个加密工具包,基于共享秘钥的AES256加解密存储方案，通过工具生成秘钥物料，然后使用工具利用秘钥文件对指定的明文进行加密。例如可以使用这种方法对数据库密码进行加密，使用的时候再使用CSE SDK接口进行解密。

在ServiceStage场景中,我们经常会用这个密钥生成工具对我们AK/SK进行加密。

16.7 本地轻量化微服务引擎

本地轻量化微服务引擎是集成了本地轻量化服务中心和配置中心及console界面,下载该zip包,解压并运行,我们可以直接在本地跑微服务,将微服务注册在本地的注册中心及配置中心,看到服务的注册情况及运行情况。
下图就是本地的console界面：

16.8 Eclipse ServiceStage插件

Eclipse ServiceStage插件使应用开发者能轻易实现在本地eclipse上与华为云微服务云应用平台的集成,能够在eclipse上对servicestage的应用进行配置、创建、更新及应用状态的查询。该插件暂只支持Tomcat和Node.js应用.

17 微服务应用实战之快速上线

• 一键式部署
• 模板生成微服务
• 多代码仓库支持
• 多语言、多运行环境支持
• 编译构建
• 多部署引擎支持
• 中间件集成

17.1 一键式部署

ServiceStage作为华为云的应用管理平台，为微服务上线提供了端到端的流程

17.2 模板生成微服务

对于微服务的新创建场景，ServiceStage提供了主流框架的模板，生成微服务工程骨架，用户只需聚集业务实现

17.3 多代码仓库支持

ServiceStage支持直接从代码部署微服务，对接主流代码仓库github，gitlab等通过OAuth授权访问

17.4 多语言、多运行环境支持

支持多种主流开发语言：java, php, nodejs, 同时提供docker镜像以支持更灵活的定制场景

17.5 编译构建

1、自动根据代码语言进行编译环境准备，集成maven，gradle，ant等构建工具。
2、自适应的编译命令。如对于java，指定编译命令> build.sh > mvn > gradle > ant
3、docker镜像构建。如果没提供Dockerfile，自动生成

17.6 多部署引擎支持

ServiceStage集成CCE，CCI，虚机3个部署引擎，封装了底层引擎的复杂，聚集业务
应用本身

17.7 中间件集成

集成RDS，DCS，微服务引擎等中间件，提供一站式使用体验

18 微服务应用实战之服务治理

• 治理能力
• 负载均衡
• 限流
• 降级
• 灰度发布

18.1 治理能力

基于ServiceComb框架，对微服务提供了负载均衡，限流，降级，容错，熔断，错误注入，灰度发布等治理能力。

18.2 负载均衡

基于Ribbon的负载均衡方案，
支持随机、顺序、基于响应时间的权值等多种负载均衡路由策略

18.3 限流

为避免个别接入流量的峰涌导致系统的崩溃，可以配置限流策略

用户在provider端使用限流策略，可以限制指定微服务向其发送请求的频率，达到限制每秒钟最大请求数量的效果

18.4 降级

降级策略是当服务请求异常时，微服务所采用的异常处理策略。

降级策略有三个相关的技术概念：“隔离”、“熔断”、“容错”：

18.4.1 隔离

是一种异常检测机制，常用的检测方法是请求超时、流量过大等。一般的设置参数包括超时时间、同时并发请求个数等。

18.4.2 熔断

是一种异常反应机制，“熔断”依赖于“隔离”。熔断通常基于错误率来实现。一般的设置参数包括统计请求的个数、错误率等。

18.4.3 容错

是一种异常处理机制，“容错”依赖于“熔断”。熔断以后，会调用“容错”的方法。一般的设置参数包括调用容错方法的次数等。

把这些概念联系起来：当"隔离"措施检测到N次请求中共有M次错误的时候，"熔断"不再发送后续请求，调用"容错"处理函数。这个技术上的定义，是和Netflix Hystrix一致的，通过这个定义，非常容易理解它提供的配置项，参考：

https://github.com/Netflix/Hystrix/wiki/Configuration。

当前ServiceComb提供两种容错方式，分别为返回null值和抛出异常。

18.5 灰度发布

ServiceComb微服务支持两种灰度策略

18.5.1 流量权重

18.5.2 自定义参数

根据接口参数进行灰度导流

19 微服务应用运维之应用监控

•云化场景下分布式应用的运维挑战
•云化场景下应用的统一运维监控
•全链路监控：覆盖从Browser与Mobile端侧到数据中心全链路
•应用拓扑分析：应用关系与异常一目了然、故障下钻
•业务会话监控：监控每笔交易的KPI数据，提升用户体验
•非侵入式数据采集：一键式采集部署，用户无感知

19.1 云化场景下分布式应用的运维挑战

相比传统的开发运维模式，云化场景下的分布式微服务应用关系更为复杂，随着应用复杂度的不断提升、用户数量的不断增加，海量业务下如何保障应用正常、如何快速完成问题定位、如何快速找到性能瓶颈，已经成为应用运维的巨大挑战。

19.2 云化场景下应用的统一运维监控

统一运维监控管理：资源、应用、业务一站式监控与分析。

19.3 全链路监控：覆盖从Browser与Mobile端侧到数据中心全链路

19.4 应用拓扑分析：应用关系与异常一目了然、故障下钻

19.5 业务会话监控：监控每笔交易的KPI数据，提升用户体验

19.6 非侵入式数据采集：一键式采集部署，用户无感知

20 微服务应用运维之调用追踪

•云化场景下分布式应用的运维挑战
•云化场景下应用的调用链跟踪
•调用追踪之性能瓶颈定界
•调用追踪之故障辅助定位

20.1 云化场景下分布式应用的运维挑战

相比传统的开发运维模式，云化场景下的分布式微服务应用关系更为复杂，随着应用复杂度的不断提升、用户数量的不断增加，海量业务下如何保障应用正常、如何快速完成问题定位、如何快速找到性能瓶颈，已经成为应用运维的巨大挑战。

20.2 云化场景下应用的调用链跟踪

20.3 调用追踪之性能瓶颈定界

20.3.1 问题背景

客户系统出现性能问题，某个接口调用耗时过长。使用调用追踪进行性能分析。

20.3.2 问题价值点

客户表示之前有一处代码使用了递归逻辑，通过调用追踪发现时延800ms，优化代码后下降到20ms，认为确实可以发挥很大作用。

20.4 调用追踪之故障辅助定位

20.4.1 问题背景

客户微服务有30个，系统某次调用出现问题，对于这类复杂的系统，需要借助调用追踪功能进行定位。

20.4.2 问题价值点

对于复杂的系统，通过调用追踪可以迅速找到出现问题的实例，避免客户运维逐一排查。大大节省客户运维时间，提高运维效率。