Spring Cloud笔记（2）组件的搭配和选择

2020-04-02 本文已影响0人飞空之羽

上一篇文章介绍了Spring Cloud的基本设计思想，就是为构建一个良好的分布式系统提供了一系列的最佳实践和模式，同时也针对各个模式提供了一些开箱即用的工具，开发者通过组合不同的工具就能够快速构建出符合自身业务特点的微服务系统。

但是Spring Cloud针对每一种分布式模式提供的解决方案或整合的工具都不止一个，我们应该在繁多的候选者里面去进行挑选和比较呢？在这里就来做一个简单的梳理，看看每一个组件的优势和适用场景大概有哪些。Spring Cloud提供的主要特性包括下面几个：

服务注册与发现：通过使用独立的组件进行服务的注册和查询，可以实现调用方和服务提供方的信息解耦，这个应该算是微服务系统中最核心的特性。Spring Cloud本来一直是使用Eureka作为注册中心的，但随着Netflix宣布Eureka 2.0不再进行开发和维护以后，很多新的替代方案也逐渐的成熟起来了，包括 Consul，Nacos 等

注册中心	优点	缺点
Eureka	使用人数最多也最成熟，Spring Cloud Netflix的默认实现，网上资料非常丰富；无需独立部署，可以嵌入到应用内（就是一个servlet程序）	不会再有新版本更新了，后面会逐步被替代
Consul	作为Eureka的官方候补，是Spring Cloud目前主要支持的实现，各方面功能都很全面，没有明显短板
Nacos	阿里开源的产品，功能对标Consul，不仅支持CP也支持AP ,使用Dubbo时的首选注册中心
ZooKeeper	大部分项目本身也依赖于ZooKeeper，所以无需单独再进行部署了；资料非常多；多数人比较熟悉	没有集成健康检查；不支持http协议，客户端需要集成SDK

下面是网上找的一个特性对比图，其实大多数特性实际项目里面也用不到，所以还是要以项目的实际情况来进行选择:

主流微服务产品对比图.png

API网关：这里的网关指的是外部系统（前端，手机端等等）访问微服务的一个反向代理服务器，微服务之间的调用不需要经过网关，功能类似于传统的nginx。默认的实现是zuul，但和Eureka的情况类似，Netflix后续的2.0版本不断跳票，Spring忍无可忍最后自己搞了一个的网关Spring Cloud Gateway 出来。后面zuul 2.0开源以后，Spring Cloud似乎也不打算再集成进来了。

API网关	优点	缺点
zuul 1	和eureka的优点基本一致	基于Servlet 2.5构建，阻塞式的 API，不支持长连接，比如 websockets ；性能不太好；1.x的版本后续不会有重大更新了
Spring Cloud Gateway	Spring的亲儿子，后续的维护集成应该不用担心；基于 Spring Boot 2.x 响应式的、非阻塞式的 API开发，性能更好，也支持长连接；官方还给出了一个性能比较：spring-cloud-gateway-bench
Nginx	大家都会用；性能最高。其实如果不打算用过滤器，熔断这些特性，Nginx也是不错的选择	缺少一些高级特性：比如熔断，限流，过滤器等等

服务间调用和负载均衡：这个的选择比较少，常用的是Feign(声明式http客户端)+Ribbon(客户端负载均衡)；另一种选择是使用阿里的Dubbo。Spring也开发了自己的负载均衡器 spring-cloud-loadbalancer，但并不是顶级项目，而是合并到 spring-cloud-commons项目中的，目前看来并不太成熟，配置项很少。

服务间调用	优点	缺点
Feign	常规搭配，基于HTTP协议的声明式客户端，内置了Ribbon提供客户端负载均衡的功能；更符合REST风格的接口；易于测试	采用http+json进行传输，性能会差一些
Dubbo	自带负载均衡策略；可以使用自有的二级制RPC协议，占用带宽更少，性能更好；如果要使用的话最好采用Spring Cloud Alibaba套件的整套解决方案	服务调用方需要依赖于提供方的接口Jar包，解耦并不彻底；RPC协议不利于测试和文档生成

断路器：系统中的每一个服务不能都保证所有的时间一直可用，一旦有某个服务发生故障，无法正常提供服务，那么服务的调用方仍然会持续请求，产生大量的积压线程，最终导致调用方也耗尽资源崩溃。这样单个服务的故障会被逐步放大，也就是所谓的“雪崩”效应。为了避免这种情况，就需要引入熔断机制。利用断路器对某个服务的故障进行监控，一旦发现服务不可用，就立即对调用方返回错误响应（或者做一些应急处理，也就是服务降级），避免了调用方的长时间等待。目前Spring Cloud已经集成的断路器有：Hystrix，Sentinel，Resilience4j。它们之间的比较可以参考这里

断路器功能对比.png

配置中心	优点	缺点
Spring Cloud Config	和Spring Cloud适配的最好（毕竟是一家开发的）,定义良好的REST风格API，自动转换配置文件的格式	需要结合版本控制工具使用，如GIT,SVN等等，动态更新需要配合Spring Cloud Bus和MQ组件使用；没有管理界面
Consul	直接利用Consul 的KV存储功能来存储配置项，如果采用Consul作为注册中心则不需要再引入额外的系统；提供了配置查看和编辑的界面
Nacos	同上
ZooKeeper	无管理界面，其它同上

Spring Cloud笔记（2） 组件的搭配和选择