1. 什么是SentinelSentinel，中文翻译为哨兵，是为微服务提供流量控制、熔断降级的功能，它和Hystrix提供的功能一样，可以有效的解决微服务调用产生的“雪崩”效应，为微服务系统提供了稳定性的解决方案。随着Hytrxi进入了维护期，不再提供新功能，Sentinel是一个不错的替代方案。通常情况，Hystrix采用线程池对服务的调用进行隔离，Sentinel才用了用户线程对接口进行隔离，二者相比，Hystrxi是服务级别的隔离，Sentinel提供了接口级别的隔离，Sentinel隔离级别更加精细，另外Sentinel直接使用用户线程进行限制，相比Hystrix的线程池隔离，减少了线程切换的开销。另外Sentinel的DashBoard提供了在线更改限流规则的配置，也更加的优化。从官方文档的介绍，Sentinel 具有以下特征:§  丰富的应用场景： Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、实时熔断下游不可用应用等。§  完备的实时监控： Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。§  广泛的开源生态： Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。§  完善的 SPI 扩展点： Sentinel 提供简单易用、完善的 SPI 扩展点。您可以通过实现扩展点，快速的定制逻辑。例如定制规则管理、适配数据源等。2  如何在Spring Cloud中使用SentinelSentinel作为Spring Cloud Alibaba的组件之一，在Spring Cloud项目中使用它非常的简单。现在以案例的形式来讲解如何在Spring Cloud项目中使用Sentinel。本项目是在之前nacos教程的案例基础上进行改造。在工程的pom文件加上sentinel的Spring Cloud起步依赖，代码如下：1.    <dependency>2.         <groupId>org.springframework.cloud</groupId>3.         <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>4.         <version>0.9.0.RELEASE</version>5.    </dependency>在工程的配置文件application.yml文件中配置，需要新增2个配置：§  spring.cloud.sentinel.transport.port: 8719 ，这个端口配置会在应用对应的机器上启动一个 Http Server，该 Server 会与 Sentinel 控制台做交互。比如 Sentinel 控制台添加了1个限流规则，会把规则数据 push 给这个 Http Server 接收，Http Server 再将规则注册到 Sentinel 中。§  spring.cloud.sentinel.transport.dashboard: 8080，这个是Sentinel DashBoard的地址。1.    server:2.      port: 87623.    spring:4.      application:5.        name: nacos-provider6.      cloud:7.        nacos:8.          discovery:9.            server-addr: 127.0.0.1:884810.       sentinel:11.         transport:12.           port: 871913.           dashboard: localhost:8080写一个RestController，在接口上加上SentinelResource注解就可以了。1.    @RestController2.    public class ProviderController {3.     4.        @GetMapping("/hi")5.        @SentinelResource(value="hi")6.        public String hi(@RequestParam(value = "name",defaultValue = "forezp",required = false)String name){7.     8.            return "hi "+name;9.        }10.    11.   }关于@SentinelResource 注解，有以下的属性：§  value：资源名称，必需项（不能为空）§  entryType：entry 类型，可选项（默认为 EntryType.OUT）§  blockHandler / blockHandlerClass: blockHandler 对应处理 BlockException 的函数名称，可选项§  fallback：fallback 函数名称，可选项，用于在抛出异常的时候提供 fallback 处理逻辑。启动Nacos，并启动nacos-provider项目。文末有源码下载链接。3    Sentinel DashBoardSentinel 控制台提供一个轻量级的控制台，它提供机器发现、单机资源实时监控、集群资源汇总，以及规则管理的功能. Sentinel DashBoard下载地址：https://github.com/alibaba/Sentinel/releases下载完成后，以以下的命令启动1.    java -jar sentinel-dashboard-1.6.1.jar默认启动端口为8080，可以-Dserver.port=8081的形式改变默认端口。启动成功后，在浏览器**问localhost:8080，就可以显示Sentinel的登陆界面，登陆名为sentinel，密码为sentinel。登陆sentinel dashboard成功后，并多次访问nacos-provider的localhost:8080/hi接口，在nacos访问信息如下：sentinel dashboard显示了nacos-provider的接口资源信息。在/hi资源处设置接口的限流功能，在“+流控”按钮点击开设置界面如下,设置阈值类型为 qps，单机阈值为2。设置成功后可以在流控规则这一栏进行查看，如图所示：4    测试多次快速访问nacos-provider的接口资源http://localhost:8762/hi，可以发现偶尔出现以下的信息：Blocked by Sentinel (flow limiting)正常的返回逻辑为hi forezp由以上可只，接口资源/hi的限流规则起到了作用。5    在FeignClient中使用SentinelHystrix默认集成在Spring Cloud 的Feign Client组件中，Sentinel也可以提供这样的功能。现以案例的形式来讲解如何在FeignClient中使用Sentinel，z本案例是在之前的nacos教程案例的nacos-consumer工程上进行改造，除了引入spring-cloud-starter-alibaba-sentinel，还需要引入spring-cloud-starter-openfeign，代码如下：1.        <dependency>2.                <groupId>org.springframework.cloud</groupId>3.                <artifactId>spring-cloud-starter-openfeign</artifactId>4.            </dependency>5.            <dependency>6.                <groupId>org.springframework.cloud</groupId>7.                <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>8.                <version>0.9.0.RELEASE</version>9.            </dependency>在配置文件中需要加上sentinel.transport. dashboard配置外，还需要加上feign.sentinel.enabled的配置，代码如下：1.    server:2.      port: 87633.    spring:4.      application:5.        name: nacos-consumer6.      cloud:7.        nacos:8.          discovery:9.            server-addr: 127.0.0.1:884810.       sentinel:11.         transport:12.           port: 871913.           dashboard: localhost:808014.    15.   feign.sentinel.enabled: true写一个FeignClient，调用nacos-provider的/hi接口：1.    @FeignClient("nacos-provider")2.    public interface ProviderClient {3.     4.        @GetMapping("/hi")5.        String hi(@RequestParam(value = "name", defaultValue = "forezp", required = false) String name);6.    }写一个RestController调用ProviderClient，代码如下：1.    @RestController2.    public class ConsumerController {3.     4.        @Autowired5.        ProviderClient providerClient;6.     7.        @GetMapping("/hi-feign")8.        public String hiFeign(){9.           return providerClient.hi("feign");10.       }11.   }在FeignClient中，Sentinel为Feign调用生成了资源名策略定义，定义规则为httpmethod:protocol://requesturl。启动nacos-consumer工程，在Sentinel DashBoard生成了如下的资源信息：添加流控，QPS为2，在浏览器上快速多次点击访问http://localhost:8763/hi-feign，浏览器在正常情况下是能够正常返回如下的信息：hi feign在被限流的时候返回错误信息。需要注意的是，被限流的时候FeignClient并不会调用nacos-provider的接口，而是在nacos-consumer工程里直接报错。6    源码下载https://github.com/forezp/SpringCloudLearning/tree/master/springcloud-alibaba/nacos-discovery-sentinel7    参考资料https://github.com/alibaba/Sentinel/releaseshttps://github.com/alibaba/Sentinel/tree/master/sentinel-dashboardhttps://github.com/spring-cloud-incubator/spring-cloud-alibaba/wiki/Sentinelhttps://github.com/alibaba/Sentinel/wiki/%E6%8E%A7%E5%88%B6%E5%8F%B0原创作者：方志朋作者简介：SpringCloud中国社区联合创始人，博客访问量突破一千万，爱好开源，热爱分享，活跃于各大社区，保持着非常强的学习驱动力，终身学习践行者，终身学习受益者。目前就职于国内某家知名互联网保险公司，担任DEVOPS工程师，对微服务领域和持续集成领域研究较深，精通微服务框架Spring Cloud

2019-03-22 15:25:04.396 ERROR: [config-center-vert.x-eventloop-thread-0] org.apache.servicecomb.config.client.ConfigCenterClient[426] - Config update from https://cse.cn-north-1.myhuaweicloud.com failed. Error message is [The timeout period of 9000ms has been exceeded while executing GET /v3/default/configuration/items?dimensionsInfo=gateway-server%40spring-cloud-application%231.0.0&revision=default for host cse.cn-north-1.myhuaweicloud.com].2019-03-22 15:25:15.163 ERROR: [registry-vert.x-eventloop-thread-0] org.apache.servicecomb.serviceregistry.client.http.RestUtils[93] - GET /v4/default/registry/existence?appId=spring-cloud-application&type=microservice&serviceName=gateway-server&env&version=1.0.0 fail, endpoint is cse.cn-north-1.myhuaweicloud.com:443, message: Connection timed out: no further information: cse.cn-north-1.myhuaweicloud.com/43.254.0.77:4432019-03-22 15:25:15.164 WARN : [registry-vert.x-eventloop-thread-0] org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl[105] - invoke service [/v4/default/registry/existence] failed, retry.2019-03-22 15:25:15.165 INFO : [registry-vert.x-eventloop-thread-0] org.apache.servicecomb.serviceregistry.client.IpPortManager[100] - Change service center address from cse.cn-north-1.myhuaweicloud.com:443 to cse.cn-north-1.myhuaweicloud.com:4432019-03-22 15:25:16.440 ERROR: [config-center-vert.x-eventloop-thread-0] org.apache.servicecomb.config.client.ConfigCenterClient[426] - Config update from https://cse.cn-north-1.myhuaweicloud.com failed. Error message is [Connection timed out: no further information: cse.cn-north-1.myhuaweicloud.com/43.254.0.77:443].2019-03-22 15:25:28.593 ERROR: [config-center-vert.x-eventloop-thread-0] org.apache.servicecomb.config.client.ConfigCenterClient[426] - Config update from https://cse.cn-north-1.myhuaweicloud.com failed. Error message is [The timeout period of 9000ms has been exceeded while executing GET /v3/default/configuration/items?dimensionsInfo=gateway-server%40spring-cloud-application%231.0.0&revision=default for host cse.cn-north-1.myhuaweicloud.com].2019-03-22 15:25:36.234 ERROR: [registry-vert.x-eventloop-thread-0] org.apache.servicecomb.serviceregistry.client.http.RestUtils[93] - GET /v4/default/registry/existence?appId=spring-cloud-application&type=microservice&serviceName=gateway-server&env&version=1.0.0 fail, endpoint is cse.cn-north-1.myhuaweicloud.com:443, message: Connection timed out: no further information: cse.cn-north-1.myhuaweicloud.com/43.254.0.77:4432019-03-22 15:25:36.235 WARN : [registry-vert.x-eventloop-thread-0] org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl[105] - invoke service [/v4/default/registry/existence] failed, retry.2019-03-22 15:25:36.236 INFO : [registry-vert.x-eventloop-thread-0] org.apache.servicecomb.serviceregistry.client.IpPortManager[100] - Change service center address from cse.cn-north-1.myhuaweicloud.com:443 to cse.cn-north-1.myhuaweicloud.com:4432019-03-22 15:25:40.648 ERROR: [config-center-vert.x-eventloop-thread-0] org.apache.servicecomb.config.client.ConfigCenterClient[426] - Config update from https://cse.cn-north-1.myhuaweicloud.com failed. Error message is [Connection timed out: no further information: cse.cn-north-1.myhuaweicloud.com/43.254.0.77:443].2019-03-22 15:25:52.813 ERROR: [config-center-vert.x-eventloop-thread-0] org.apache.servicecomb.config.client.ConfigCenterClient[426] - Config update from https://cse.cn-north-1.myhuaweicloud.com failed. Error message is [The timeout period of 9000ms has been exceeded while executing GET /v3/default/configuration/items?dimensionsInfo=gateway-server%40spring-cloud-application%231.0.0&revision=default for host cse.cn-north-1.myhuaweicloud.com].2019-03-22 15:25:57.325 ERROR: [registry-vert.x-eventloop-thread-0] org.apache.servicecomb.serviceregistry.client.http.RestUtils[93] - GET /v4/default/registry/existence?appId=spring-cloud-application&type=microservice&serviceName=gateway-server&env&version=1.0.0 fail, endpoint is cse.cn-north-1.myhuaweicloud.com:443, message: Connection timed out: no further information: cse.cn-north-1.myhuaweicloud.com/43.254.0.77:4432019-03-22 15:26:04.862 ERROR: [config-center-vert.x-eventloop-thread-0] org.apache.servicecomb.config.client.ConfigCenterClient[426] - Config update from https://cse.cn-north-1.myhuaweicloud.com failed. Error message is [Connection timed out: no further information: cse.cn-north-1.myhuaweicloud.com/43.254.0.77:443].2019-03-22 15:26:17.037 ERROR: [config-center-vert.x-eventloop-thread-0] org.apache.servicecomb.config.client.ConfigCenterClient[426] - Config update from https://cse.cn-north-1.myhuaweicloud.com failed. Error message is [The timeout period of 9000ms has been exceeded while executing GET /v3/default/configuration/items?dimensionsInfo=gateway-server%40spring-cloud-application%231.0.0&revision=default for host cse.cn-north-1.myhuaweicloud.com].2019-03-22 15:26:18.415 ERROR: [registry-vert.x-eventloop-thread-0] org.apache.servicecomb.serviceregistry.client.http.RestUtils[93] - POST /v4/default/registry/microservices fail, endpoint is cse.cn-north-1.myhuaweicloud.com:443, message: Connection timed out: no further information: cse.cn-north-1.myhuaweicloud.com/43.254.0.77:4432019-03-22 15:26:18.416 WARN : [registry-vert.x-eventloop-thread-0] org.apache.servicecomb.serviceregistry.client.http.ServiceRegistryClientImpl[105] - invoke service [/v4/default/registry/microservices] failed, retry.2019-03-22 15:26:18.417 INFO : [registry-vert.x-eventloop-thread-0] org.apache.servicecomb.serviceregistry.client.IpPortManager[100] - Change service center address from cse.cn-north-1.myhuaweicloud.com:443 to cse.cn-north-1.myhuaweicloud.com:443

在上一篇 《ServiceComb + SpringCloud Ribbon使用篇》中介绍了负载均衡的概念和ServiceComb协同SpringCloud Ribbon的使用, 本篇将从源码角度介绍ServiceComb是如何实现与SpringCloud Ribbon协同工作的。一. ServiceComb对接 Spring Cloud Ribbon思路在Ribbon的wiki介绍页(https://github.com/Netflix/ribbon/wiki/Working-with-load-balancers)可以发现这样的描述：ServerList - this can be static or dynamic. If it is dynamic (as used by DynamicServerListLoadBalancer), a background thread will refresh and filter the list at certain interval这段介绍了ServerList接口，该接口既可以是静态获取服务实例列表也可以是动态获取的。如果是动态获取服务列表（被DynamicServerListLoadBalancer使用），会有一个后台线程在特定得时间间隔负责刷新和过滤服务列表。也就是说，我们只要实现了ServerList接口，加上相应的配置让Ribbon获取到，就能向Ribbon提供ServiceComb自己的服务发现逻辑。如下图↓↓↓ServiceComb 在如下的org.apache.servicecomb:spring-boot-starter-discovery项目中实现了ServerList接口和相应的配置。<dependency>   <groupId>org.apache.servicecomb</groupId>   <artifactId>spring-boot-starter-discovery</artifactId>   <version>1.1.0</version></dependency>二. 源码分析项目结构如下图，红色方框内为接入SpringCloud Ribbon组件的相关类。下面我们分别来看看这几个类↓↓↓ScbRibbonConfigurationConfiguration 表示这是一个spring的配置类EnableConfigurationProperties 使@ConfigurationProperties注解生效ConditionalOnBean 只有特定名称或者类型的Bean存在于BeanFactory时才创建某个BeanAutoConfigureAfter 只有在指定类的配置类配置完后才会生效RibbonClients 允许在一个类中声明多个RibbonClient注解注意Ribbon是懒加载的，而该类在RibbonAutoConfiguration初始化配置之后才会执行配置，所以该类也是懒加载ScbRibbonClientConfiguration在ScbRibbonConfiguration类中的RibbonClients注解指定了ScbRibbonClientConfiguration来实例化RibbonClient。 如下，该类实例化了一个ServerList对象，实际类型为ServiceCombServerList，该对象会替换DynamicServerListLoadBalancer类里的ServerList对象。ServiceCombServerList在Ribbon体系中，ServerList接口负责获取服务实例列表。ServiceComb使用ServiceCombServerList实现了该接口。该类使用了ServiceComb内置的服务发现能力。ServiceCombServerList构造器里使用discoveryTree添加了一个过滤器ScbRibbonEndpointDiscoveryFilter。•DiscoveryTree是ServiceComb Registry包的类。ServiceComb Registry包提供了服务注册，服务发现与过滤器等能力。•ScbRibbonEndpointDiscoveryFilter继承了AbstractEndpointDiscoveryFilter，而AbstractEndpointDiscoveryFilter实现了DiscoveryFilter。DiscoveryFilter接口主要管理实例进行分组、缓存getInitialListOfServers方法获取初始的servers；getUpdatedListOfServers方法获取更新的serversScbRibbonEndpointDiscoveryFilterScbRibbonEndpointDiscoveryFilter继承于AbstractEndpointDiscoveryFilter类，观察AbstractEndpointDiscoveryFilter代码可发现有一个discovery方法,这个方法会被DiscoveryTree使用以获取服务列表。此时已进入ServiceComb Registry包内部，具体的细节不展开分析。关于filter类，实际上查看DiscoveryTree的源码可发现一些信息，如下是DiscoveryTree的doDiscovery方法，该方法属于ServiceCombServerList获取服务实例列表的调用链上，而该方法会将这个获取信息的任务交给DiscoveryFilter类去处理。小结本文向社区读者从源码角度阐述了ServiceComb是如何与SpringCloud Ribbon协同工作的。 [单纯使用的用户实际上不必关心这些细节]  非常欢迎爱好者们向社区提问和贡献代码:)下篇将介绍ServiceComb内置的负载均衡的能力，内置的能力可支持定制化重试策略。如在阅读代码时有任何疑问想交流，欢迎扫码加入进微信群。期待志同道合的朋友们加入ServiceComb的大门为你们敞开~用心做开源，不忘初衷前期阅读 [学习微服务-第6天] 负载均衡之ServiceComb + SpringCloud Ribbon[学习微服务-第5天]ServiceComb+Zipkin源码解读[学习微服务-第4天]ServiceComb+Zipkin[学习微服务-第3天] ServiceComb内置高性能网关服务[每天学习微服务-源码解读] ServiceComb+SpringCloud Zuul[每天学习微服务-网关]ServiceComb+SpringCloud Zuul-----------------------------------------------了解更多信息请访问： 官方网站http://servicecomb.apache.org/ Github代码仓库https://github.com/apache?q=ServiceComb

在微服务架构中，客户端负载均衡是指负载均衡器作为客户端软件的一部分,客户端得到可用的服务实例列表然后按照特定的负载均衡策略,分发请求到不同的服务。ServiceComb内置了客户端负载均衡组件，开发者可以非常简单的使用。具体可参考:https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/loadbalance.html 本文将介绍ServiceComb与SpringCloud的Ribbon负载均衡组件协同工作，以构建微服务应用。ServiceComb已适配对应的接口和配置，用户用极简单的方法配置后即可使微服务应用具备负载均衡的能力。示例以下通过一个服务提供者provider-service和消费者consumer-service作为demo演示。provider-service会启动3个微服务实例，消费者端consumer-service使用Ribbon负载均衡调用proveder-service服务的接口。其中consumer-service在调用provider-service提供的接口时会打印出真实调用的URL ↓↓↓完整示例地址：https://github.com/lisenwork/servicecomb-demo/tree/master/servicecomb-ribbon 预置条件:  示例应先安装启动服务与注册中心ServiceCenter，详细步骤请参考官网↓↓↓http://servicecomb.apache.org/cn/users/setup-environment/#%E8%BF%90%E8%A1%8Cservice-center 一开发服务消费者comsumer-service只需三步即可开发拥有负载均衡能力的微服务步骤如下：01添加依赖新建pom文件，引入如下依赖。完整pom文件内容请参考↓↓↓https://github.com/lisenwork/servicecomb-demo/blob/master/servicecomb-ribbon/consumer-service/pom.xml     02配置 在resources目录下新建ServiceComb配置文件microservice.yaml。配置微服务信息↓↓↓03项目入口新建启动类ConsumerApplication.java。如下图，启动类里同时实例化一个RestTemplate对象。该对象用于后面的服务间接口调用。新建ConsumerController.java。在该类的consumer方法里使用Ribbon的API动态获取服务实例，并打印出被选中的实例的真实IP地址和端口。最后调用服务实例的接口，获取结果并返回。04启动项目根目录下执行命令 mvn spring-boot:run二开发服务提供者provider-service01添加依赖新建pom文件，引入如下依赖。完整pom文件内容请参考↓↓↓https://github.com/lisenwork/servicecomb-demo/blob/master/servicecomb-ribbon/provider-service/pom.xml 02配置 在src/main/resources目录下新建microservice.yaml03项目入口新建启动类ProviderApplication.java新建ProviderController.java。只向外提供/provider接口04启动 服务提供者要启动3个微服务实例。打开microservice.yaml文件，分别修改微服务监听端口为8888，8889，8890，在项目根目录下执行3次命令 mvn spring-boot:run演示浏览器访问http://localhost:7777/consumer，重复刷新一定次数，观察控制台，会发现服务消费者会轮询调用服务提供者的三个实例。小结本文向社区读者从读者角度阐述了ServiceComb是如何支持SpringCloud Ribbon的。我们也非常欢迎爱好者们向社区提问和贡献代码。下章我们将介绍ServiceComb+SpringCloud Ribbon源码篇。如果在阅读代码时有任何疑问想交流，欢迎扫码加入进微信群。期待志同道合的朋友们加入ServiceComb的大门为你们敞开~用心做开源，不忘初衷前期阅读[学习微服务-第5天]ServiceComb+Zipkin源码解读[学习微服务-第4天]ServiceComb+Zipkin[学习微服务-第3天] ServiceComb内置高性能网关服务[每天学习微服务-源码解读] ServiceComb+SpringCloud Zuul[每天学习微服务-网关]ServiceComb+SpringCloud Zuul了解更多信息请访问官方网站http://servicecomb.apache.org/ Github代码仓库https://github.com/apache?q=ServiceComb

上一篇文章我们介绍了ServiceComb与SpringCloud的Zuul网关组件协同工作，以构建微服务应用。为了给ServiceComb做贡献的伙伴提供指引，本篇将介绍ServiceComb与SpringCloud Zuul的集成源码。ServiceComb 对接 Spring Cloud Zuul 思路ServiceComb没有修改SpringCloud Zuul的源代码，而是利用了 SpringCloud 提供的可扩展的接口。Spring Cloud Zuul官网有如下两段描述▼▼▼•Zuul starter不包括服务发现客户端, 所以为了实现基于service ID的路由转发，你必须同时在类路径下提供一个服务发现客户端 （ 可以使用 Eureka ）•DiscoveryClientRouteLocator 过滤器从一个DiscoveryClient（例如Eureka）和属性文件中加载了路由定义信息。详情参考：https://cloud.spring.io/spring-cloud-netflix/multi/multi__router_and_filter_zuul.html从以上的描述看，SpringCloud Zuul允许我们自定义服务发现客户端来实现自己的服务发现逻辑。其中DiscoveryClient接口是Spring Cloud Commons提供的与服务治理相关的抽象接口，Spring Cloud Commons做了一层抽象，很好的解耦了服务治理体系，使得我们可以轻易的替换不同的服务治理设施。在我们的上篇文章[每天5分钟学习微服务-网关]ServiceComb+SpringCloud Zuul中实现的zuulserver项目中，pom文件中有如下依赖↓↓↓以上就是一个自定义discovery client。这个discovery client是专门与ServiceComb的服务与发现注册中心ServiceCenter进行交互的。如下图所示，客户端和各个微服务都与Zuul网关直接通信，而Zuul网关通过ServiceComb Discovery与ServiceCenter获取服务的实例信息（真实IP地址和端口等）ServiceComb Discovery源码分析目录结构源码从github上下载↓↓↓https://github.com/apache/servicecomb-java-chassis/tree/master/java-chassis-spring-boot/spring-boot-starter/spring-boot-starter-discovery   很明显这是一个自定义的SpringBoot的starter项目。关于SpringBoot自定义starter可以参考： Creating your own starter（https://docs.spring.io/spring-boot/docs/1.5.12.RELEASE/reference/htmlsingle/#boot-features-custom-starter）springboot的starter项目一般是做自动配置（auto-configure）。那么以下按照starter项目的思路来分析。1. 自动配置入口org.apache.servicecomb.springboot.starter.discovery包下面的ScbDiscoveryClientConfiguration类中和ScbRibbonConfiguration类中找到了AutoConfigureBefore和AutoConfigureAfter注解AutoConfigureBefore：类级别的注解，在指定类初始化配置之前自动执行当前配置类AutoConfigureAfter：类级别的注解，在指定类初始化配置之后自动执行当前配置类tips:查看spring.factories文件是否有org.springframework.boot.autoconfigure.EnableAutoConfiguration的配置或者包下面的类是否有@AutoConfigureBefore，@AutoConfigureAfter注解2. ScbDiscoveryClientConfiguration类这是一个Spring自动配置类，在这个类里只实例化了DiscoveryClient对象这个配置类只实例化了一个DiscoveryClient对象。重点来了，这个DiscoveryClient对象就是给Zuul使用的！！！ 最终会被Zuul的 DiscoveryClientRouteLocator 过滤器 用来加载路由定义信息。3. ScbRibbonConfiguration类这是个Spring自动配置类，这个类是为了导入配置类RibbonAutoConfiguration.class代码如上，没有任何实现，注意看注解@RibbonClients ，指定了ScbRibbonClientConfiguration类来配置RibbonClient。下面看这个类。4. ScbRibbonClientConfiguration类这个类是Spring配置类，实例化了Ribbon相关的BeanServerList是Ribbon框架的东西（Ribbon是客户端负载均衡框架）。ServerList是获取服务列表的接口ServiceCombServerList类继承于抽象类AbstractServerList，而AbstractServerList实现了ServerList接口接着看下ServiceCombServerList做了什么事情。5. ServiceCombServerList 类这个类是给Ribbon使用，负责获取服务实例信息（真实IP地址和端口等）。重点在下面这个方法，这个方法使用DiscoveryTree对象真正获取服务实例。最终返回的是可用微服务实例的真实ip地址和端口。DiscoveryTree是ServiceComb的service-registry包的，这个包是负责服务注册的。DiscoveryTree的逻辑比较复杂，可以通过下面的处理流程了解其处理过程。参考官方文档 ↓↓↓https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/loadbalance.html感兴趣的同学可以研究下ServiceComb的service-registry包的实现，这里不展开分析。DiscoveryTree最终会调用到ServiceRegistryClientImpl.findServiceInstances方法▼▼▼ServiceRegistryClientImpl.findServiceInstances在这个方法内直接调用ServiceCenter的rest接口Const.REGISTRY_API.MICROSERVICE_INSTANCES来获取相应的微服务实例信息（http://127.0.0.1:30100/v4/default/registry/instances）文/末/小/结本文向社区读者从源码角度阐述了ServiceComb是如何支持SpringCloud Zuul的。单纯使用的用户实际上不必关心这些细节：）当然，我们也非常欢迎爱好者们向社区提问和贡献代码。下章我们将介绍ServiceComb内置的EdgeService网关能力。如果在阅读ServiceComb对Zuul相关支持代码时有任何疑问想交流，欢迎扫码加入进微信群。

在微服务架构模式中后端服务的实例数一般是动态的，于客户端而言很难发现动态改变的服务实例的访问地址信息，服务网关能对用户提供统一的入口。 ServiceComb Java-Chassis 内置了网关服务EdgeService，开发者可以非常简单的搭建一个EdgeService服务。具体可参考：https://docs.servicecomb.io/java-chassis/zh_CN/edge/by-servicecomb-sdk.html 本文将介绍ServiceComb与SpringCloud的Zuul网关组件协同工作，以构建微服务应用。ServiceComb在自身的处理链HandlerTrain中已完成Zuul的对接，用户用极简单的方法配置后即可使微服务应用具备网关服务的能力。为使读者更好地理解，本文将编写一个简单的Hello微服务，并启动2个实例来进行演示。Hello微服务提供hello/{name}接口，只需从前端输入参数name就可从后端微服务获取到程序员百看不厌的Hello world结果。微服务模式下的Hello应用模型技术准备ServiceComb 作为后端微服务核心框架ServiceCenter 作为服务发现与注册中心SpringCloud Zuul 组件做服务网关环境准备以下环境为Windows 64位系统●安装git，详情可参考git安装教程https://git-scm.com/book/zh/v2/%E8%B5%B7%E6%AD%A5-%E5%AE%89%E8%A3%85-Git●安装JDK 1.8，详情可参考JDK安装教程。https://docs.oracle.com/javase/8/docs/technotes/guides/install/install_overview.html●安装Maven 3.x，详情可参考Maven安装教程https://maven.apache.org/install.htmlServiceCenter安装下载地址：http://mirrors.hust.edu.cn/apache/servicecomb/servicecomb-service-center/1.1.0/下载后解压如下▼在该目录下双击service-center.exe即可启动，命令窗口中出现如下信息基本代表ServiceCenter启动成功，从这个信息也可以得知ServiceCenter监听的是30100端口，等下配置文件要用到。问题点：有可能会有如下信息，这个一般是端口被占用，很可能你打开了两个ServiceCenter，都关闭后再打开就可以了。↓↓↓示例一、后端微服务 HelloService01添加依赖新建maven项目HelloService，pom文件如下02配置新建ServiceComb配置文件src/main/resources/microservice.yaml，内容如下▼03项目入口新建启动类HelloApplication.java，内容如下▼新建Controller类HelloController.java （这里我习惯SpringMvc的叫法，重点看注解）04启动到此，Hello微服务就写完了。这里要启动2个实例。1.先打包，执行mvn clean package2.在项目根目录下target目录下将lib目录和生成的jar包复制到另一个目录中 3.复制jar包，修改其中一个jar包微服务启动端口号为8888（通过WinRar解压缩软件打开jar包并打开microservice.yaml文件修改里面的rest端口号） 4.在当前目录打开两个cmd命令窗口，分别执行命令java -jar HelloService-7777.jar和java -jar HelloService-8888.jar 。此时已经启动了2个微服务实例。二、编写Zuul网关服务01 添加依赖新建maven项目 zuulserver，pom文件如下02配置文件新建springboot配置文件src/main/resources/application.yaml，内容如下新建ServiceComb配置文件src/main/resources/microservice.yaml，内容如下03项目入口新建启动类 ZuulApplication.java新建静态文件 src/main/resources/static/index.html，内容如下 （static目录是按springboot项目规范，属于应用静态文件根目录）04启动到此，网关服务器写完，如下在IDEA里面直接启动应用三. 演示效果浏览器访问http://localhost:8080/ ，如下图。 在输入框中输入姓名，就可以在下面看到打招呼的信息连续点击几次打招呼按钮，可以在启动的2个Hello微服务实例的控制台中看到被调用的信息，如下图（由于这里使用的ServiceComb默认的负载均衡策略 轮询，可见到两个实例都均被调用，关于负载均衡，我们将在后续的文章中解读）。此时用户并不需要关心具体哪个实例被调用了，访问的是哪个后端的实例地址，它只要访问网关就可以了：）总结从以上的示例可以看出，通过 ServiceComb 结合SpringCloud Zuul 实现服务网关功能只需一些简单的配置。后续可以在网关服务上实现统一的鉴权，日志记录，和自定义过滤器等。参考[1] SpringCloud Zuulhttps://cloud.spring.io/spring-cloud-netflix/multi/multi__router_and_filter_zuul.html  [2] ServiceCombhttp://servicecomb.apache.org/cn/docs/quick-start/    

本帖最后由 李白云 于 2018-2-5 10:43 编辑可否比较一下ServiceComb与Spring Cloud，甚至dubbo，方便选型参考？

RT