## 一、Spring Cloud与Netflix Netflix是一家做视频网站的公司,之所以要说一下这个公司是因为Spring Cloud在发展之初,Netflix做了很大的贡献。包括服务注册中心Eureka、服务调用Ribbon、Feign,服务容错限流Hystrix、服务网关Zuul等众多组件都是Netflix贡献给Spring Cloud社区的。 但这些组件在使用过程中也多多少少的暴露了一些弊病,比如: * 服务网关Zuul是基于servlet开发的,使用阻塞IO,在高并发情况下性能表现一般。 * 公共服务组件过多,部署一个Spring Cloud微服务,公共服务组件就占用了很多的服务器资源。 所以,很多的厂商就基于Spring Cloud设计理念,开发自己的组件,其中比较著名的就是Spring Cloud Alibaba和携程的apollo。 ![](https://img.kancloud.cn/b6/a1/b6a1d8ff09364ddc6f675f07b7f234b0_1219x698.png) 上图中绿色对号的基本上都是Spring Cloud社区第二代组件,也是目前建议使用的组件。图中红色X号的组件,都基本上面临着淘汰与替换。 ## 二、核心事件追踪 笔者一直关心着Spring Cloud社区的发展,下面将近两年社区的大事件集中展现一下: * 2018年6月底,Eureka 2.0 开源工作宣告停止,继续使用风险自负。 * 2018年11月底,Hystrix 宣布不再在开源版本上提供新功能。 * 2018年12月,Spring官方宣布Netflix的相关项目进入维护模式(Maintenance Mode)。 从此,Spring Cloud逐渐告别netflix时代。 * 2018年10月31日,Spring Cloud Alibaba正式入驻了Spring Cloud官方孵化器,并在maven中央库发布了第一个版本。 与此同时,Spring Cloud团队内部维护的组件也在积极的更新换代。 ## 二、服务注册中心选型 * Eureka:Spring Cloud与Netflix的大儿子,出生的时候家里条件一般,长大后素质有限。 * Nacos:后起之秀,曾经Spring Cloud眼中“别人家的孩子”,已经纳入收养范围(Spring Cloud Alibaba孵化项目)。 * Apache Zookeeper:关系户,与hadoop关系比较好 * etcd:关系户,与kubernetes关系比较好 * Consul:关系户,曾经与docker关系比较好 如果你的应用已经使用到了hadoop、kubernetes、docker,在Spring Cloud实施过程中可以考虑使用其关系户组件,避免搭建两套注册中心,节省资源。但是二者兼容使用说说容易,真正用起来还需要功夫。目前看,笔者觉得最佳选择应该是Nacos。 ## 三、分布式配置管理 目前可选的分布式配置管理中心,有阿里的Nacos、携程的Apollo、和Spring Cloud Config。 * 如果你希望完成单纯的分布式配置集中管理,其实三者都能满足你的需求。 * 如果你考虑到已经用Nacos实现了服务注册中心,不想单独搞出来一个配置管理中心,合二为一的话,nacoos可能是你的最佳选择 * 携程的Apollo与nacos很多相似之处,有颇多的亮点。从笔者的使用感受而言,目前apollo从文档细节到方便度要好于nacos(截止2020年4月)。但是nacos毕竟开源时间较短,依托alibaba的支持,有很大的潜力和发展空间。 * spring cloud config对比其他两者,在功能以及友好度方面都逊色。唯一的优点可能是它比较轻量级。 | 对比项目/配置中心 | spring cloud **config** | **apollo** | **nacos(重点)** | | --- | --- | --- | --- | | 开源时间 | 2014.9 | 2016.5 | 2018.6 | | 配置实时推送 | 弱支持(Spring Cloud Bus) | 支持(HTTP长轮询1s内) | 支持(HTTP长轮询1s内) | | 版本管理 | 支持(Git) | 自动管理 | 自动管理 | | 配置回滚 | 弱支持(Git+Bus) | 支持 | 支持 | | 配置的灰度发布 | 理念上支持,可操作性不强 | 支持 | 1.1.0开始支持 | | 权限管理 | 不支持(没有区分用户、角色、权限的概念) | 支持 | 1.2.0开始支持 | | 多集群多环境 | 对集群概念支持较弱 | 支持 | 支持 | | 多语言 | 只支持Java | Go,C++,Python,Java,.net,OpenAPI | Python,Java,Nodejs,OpenAPI | | 分布式高可用最小集群数量 | **Config**\-Server2+Git+MQ | **Config**2+Admin3+Portal\*2+Mysql=8 | **Nacos**\*3+MySql=4 | | 配置格式校验 | 不支持 | 支持 | 支持 | | 通信协议 | HTTP和AMQP | HTTP | HTTP | | 数据一致性 | Git保证数据一致性,**Config**\-Server从Git读取数据 | 数据库模拟消息队列,**Apollo**定时读消息 | HTTP异步通知 | ## 三、服务网关 服务网关这块就不多说了,没有任何悬念,Spring Cloud Gateway在各方面都碾压Zuul,Zuul2也基本上是胎死腹中。还有一些第三方厂商开发的微服务网关,但基本上没有形成气候! ## 四、熔断限流 #### Hystrix 2018年12月,Spring官方宣布Netflix的相关项目进入维护模式(Maintenance Mode)。不再开发新的功能,但是Hystrix整体上还是比较稳定的,对于老用户不必更换,影响也不大。 #### resilience4j Hystrix停更之后,Netflix官方推荐使用resilience4j(https://github.com/resilience4j/resilience4j ),它是一个轻量、易用、可组装的高可用框架,支持熔断、高频控制、隔离、限流、限时、重试等多种高可用机制。 #### Sentinel(重点) Sentinel(https://github.com/alibaba/Sentinel )是阿里中间件团队开源的,面向分布式服务架构的轻量级高可用流量控制组件,主要以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。 https://github.com/alibaba/Sentinel/wiki/Guideline:-%E4%BB%8E-Hystrix-%E8%BF%81%E7%A7%BB%E5%88%B0-Sentinel |Sentinel | Hystrix | resilience4j | | --- | --- | --- | | 隔离策略 | 信号量隔离(并发线程数限流) | 线程池隔离/信号量隔离 | 信号量隔离 | | 熔断降级策略 | 基于响应时间、异常比率、异常数 | 基于异常比率 | 基于异常比率、响应时间 | | 实时统计实现 | 滑动窗口(LeapArray) | 滑动窗口(基于 RxJava) | Ring Bit Buffer | | 动态规则配置 | 支持多种数据源 | 支持多种数据源 | 有限支持 | | 扩展性 | 多个扩展点 | 插件的形式 | 接口的形式 | | 基于注解的支持 | 支持 | 支持 | 支持 | | 限流 | 基于 QPS,支持基于调用关系的限流 | 有限的支持 | Rate Limiter | | 流量整形 | 支持预热模式、匀速器模式、预热排队模式 | 不支持 | 简单的 Rate Limiter 模式 | | 系统自适应保护 | 支持 | 不支持 | 不支持 | | 控制台 | 提供开箱即用的控制台,可配置规则、查看秒级监控、机器发现等 | 简单的监控查看 | 不提供控制台,可对接其它监控系统 |