上一篇文章介绍了Spring Cloud的基本设计思想，就是为构建一个良好的分布式系统提供了一系列的最佳实践和模式，同时也针对各个模式提供了一些开箱即用的工具，开发者通过组合不同的工具就能够快速构建出符合自身业务特点的微服务系统。
但是Spring Cloud针对每一种分布式模式提供的解决方案或整合的工具都不止一个，我们应该在繁多的候选者里面去进行挑选和比较呢？在这里就来做一个简单的梳理，看看每一个组件的优势和适用场景大概有哪些。Spring Cloud提供的主要特性包括下面几个：
服务注册与发现：通过使用独立的组件进行服务的注册和查询，可以实现调用方和服务提供方的信息解耦，这个应该算是微服务系统中最核心的特性。Spring Cloud本来一直是使用Eureka作为注册中心的，但随着Netflix宣布Eureka 2.0不再进行开发和维护以后，很多新的替代方案也逐渐的成熟起来了，包括 Consul，Nacos 等，以下4种组件Spring Cloud都提供了集成方案：
-
Eureka: 使用人数最多也最成熟，Spring Cloud Netflix的默认实现（目前集成的版本仍然是1.19.1），网上资料非常丰富；无需独立部署，可以嵌入到应用内（就是一个servlet程序）。但Eureka 1后续不会再有新版本更新了，2.0又不会开源，应该会逐步被替代。
-
Consul：作为Eureka的官方候补，是Spring Cloud目前主要支持的实现，各方面功能都很全面，没有明显短板.
-
Nacos：阿里开源的产品，功能对标Consul，CAP模型中不仅支持CP也支持AP ,使用Dubbo时的首选注册中心
-
ZooKeeper: ZooKeeper是一个通用的分布式协调器，多数开发者已经比较熟悉了，当然也可以作为注册中心使用，Spring Cloud也提供了集成的支持，如果项目本身也依赖于ZooKeeper，就无需再单独部署新的组件了；但zookeeper缺少一些对于注册中心来说比较重要的特性，比如健康检查和DNS服务集成等，需要自行开发。
下面是网上找的一个特性对比图，其实大多数特性实际项目里面也用不到，所以还是要以项目的实际情况来进行选择:
API网关：这里的网关指的是外部系统（前端，手机端等等）访问微服务的一个反向代理服务器，微服务之间的调用不需要经过网关，功能类似于传统的nginx。默认的实现是zuul，但和Eureka的情况类似，Netflix后续的2.0版本不断跳票，Spring忍无可忍最后自己搞了一个网关出来 Spring Cloud Gateway 出来。后面zuul 2.0开源以后，Spring Cloud似乎也不打算再集成进来了。
-
zuul 1 : 和eureka的优点基本一致，成熟，流行。缺点是基于Servlet 2.5构建，阻塞式的 API，性能不够好；不支持长连接，比如 websockets 。1.x的版本后续也不会有重大更新了
-
Spring Cloud Gateway : Spring的亲儿子，后续的维护集成应该不用担心；基于 Spring Boot 2.x 响应式的、非阻塞式的 API开发，性能更好，也支持长连接 ；官方还给出了一个性能比较：spring-cloud-gateway-bench
-
Nginx : 说到反向代理Ngnix简直是丰碑一样的存在，性能是最好的，结合Consul Template也能够实现服务的动态负载均衡。但缺点是和Spring Cloud整合相对困难一些，缺少类似于过滤器，断路保护等特性的原生支持。
服务间调用和负载均衡：这个的选择比较少，常用的是Feign(声明式http客户端)+Ribbon(客户端负载均衡)，但Spring Cloud Ribbon项目目前已经处于维护状态，使用时会有警告；另一种选择是使用阿里的Dubbo。Spring也开发了自己的负载均衡器 spring-cloud-loadbalancer，但并不是顶级项目，而是合并到 spring-cloud-commons项目中的，可以用来取代Ribbon的位置。
-
Feign : 常规搭配，基于HTTP协议的声明式客户端，内置了Ribbon提供客户端负载均衡的功能；更符合REST风格的接口；易于测试 | 采用http+json进行传输，性能会差一些
-
Dubbo : 自带负载均衡策略；可以使用自有的二级制RPC协议，占用带宽更少，性能更好 ；如果要使用的话最好采用Spring Cloud Alibaba套件的整套解决方案；但Dubbo的服务调用方需要依赖于提供方的接口Jar包，解耦并不彻底 ；由于使用的是自定义协议，跨语言调用比较困难（其它语言也有一些配套组件，如dubbo2.js, dubbo-go，但比较小众）
断路器：系统中的每一个服务不能都保证所有的时间一直可用，一旦有某个服务发生故障，无法正常提供服务，那么服务的调用方仍然会持续请求，产生大量的积压线程，最终导致调用方也耗尽资源崩溃。这样单个服务的故障会被逐步放大，也就是所谓的“雪崩”效应。为了避免这种情况，就需要引入熔断机制。利用断路器对某个服务的故障进行监控，一旦发现服务不可用，就立即对调用方返回错误响应（或者做一些应急处理，也就是服务降级），避免了调用方的长时间等待。目前Spring Cloud已经集成的断路器有：Hystrix，Sentinel，Resilience4j。它们之间的比较可以参考 这里
配置中心：采用统一的配置中心的主要目的是为了简化运维和动态刷新配置。Spring Cloud集成了的解决方案包括下面几种：
-
Spring Cloud Config : 和Spring Cloud适配的最好（毕竟是一家开发的）,以文件的方式加载远程配置，提供了定义良好的REST风格API用来访问配置文件，且可以自动转换配置文件的格式 ；但需要结合结合版本控制工具使用，如GIT,SVN等等；动态配置更新还需要配合Spring Cloud Bus和MQ组件使用；也没有提供维护配置的界面
-
Consul : 直接利用Consul 的KV存储功能来存储配置项，如果采用Consul作为注册中心则不需要再引入额外的系统 ；可以在Consul的管理台直接编辑配置信息
-
Nacos : 同上
-
ZooKeeper : 无管理界面，其它同上
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
