spring Cloud全家桶及微服务架构的核心概念

了解Spring Cloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

Spring Cloud中的核心组件

Spring Cloud的本质是在 Spring Boot 的基础上，增加了一堆微服务相关的规范，并对应用上下文（Application Context）进行了功能增强。既然 Spring Cloud 是规范，那么就需要去实现，目前Spring Cloud 规范已有 Spring官方，Spring Cloud Netflflix，Spring Cloud Alibaba等实现。通过组件化的方式，Spring Cloud将这些实现整合到一起构成全家桶式的微服务技术栈。

Spring Cloud Netflix组件

组件名称	作用
Eureka	服务注册与发现
Ribbon	客户端负载均衡
Feign	声明式服务调用
Hystrix	客户端容错保护
Zuul	API服务网关

Spring Cloud Alibaba组件

组件名称	作用
Nacos	服务注册与发现+配置中心
Sentinel	客户端容错保护

Spring Cloud原生及其他组件

组件名称	作用
Consul	服务注册与发现
Config	分布式配置中心
Gateway	API服务网关
Sleuth/Zipkin	分布式链路追踪

微服务中的核心概念

在上面介绍Spring Cloud组件的时候，介绍了很多相关的概念，如服务注册与发现、API网关、链路追踪等等。

服务注册与发现

服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。

服务发现：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。

负载均衡

负载均衡是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。

服务熔断

熔断这一概念来源于电子工程中的断路器（Circuit Breaker）。在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。

图中是典型的服务雪崩问题，当服务A调用服务B、服务B调用服务C，此时服务C出现问题无法给服务B响应，服务B一直等待，出现大量请求堆积，导致服务B崩溃，同样道理会导致服务A崩溃，最终引起整个服务调用链路的崩溃问题。
为了解决服务雪崩的问题，引入了服务熔断机制。

链路追踪

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控即链路追踪。

API网关

随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：

• 客户端需要调用不同的url地址，增加难度；
• 在一定的场景下，存在跨域请求的问题；
• 每个微服务都需要进行单独的身份认证。

针对这些问题，API网关顺势而生。

API网关直面意思是将所有API调用统一接入到API网关层，由网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。

关于停更的影响

先上一张图如下：

这次Spring Cloud组件的停更造成的影响还是很大的，按照图中依次来说一说停更后的影响。

服务注册与发现

在停更之前很多项目上服务注册与发现都是使用的Eureka，后续还有使用consul作为替代方案的。但是到目前为止，主流的基本都换成了Spring Cloud Alibaba的Nacos，当然还有很多项目使用更为zookeeper，但是Nacos已经成为主流，已经被广大公司和研发人员认可，在新建项目或者改造项目基本都会使用Nacos，除非公司特殊要求使用consul、zookeeper。

服务调用（负载均衡）

Ribbon也是在停更的队列中，说是要出一个LoadBalancer，但是目前根据调研，正式使用的相对较少，在这一块还是Ribbon作为主流，但是需要做好随时替换成LoadBalancer或者其他更好的负载均衡组件的准备。

服务调用

Feign也算是彻底玩完了，现在市面上的公司相信已经基本没有有的了，都替换成了OpenFeign，所以在这块的技术选型的时候，就不用绞尽脑汁想选什么组件啦，直接上OpenFeign就对了。

服务降级

服务熔断和降级，Hystrix已经很少使用了，但是Hystrix的思想还是很经典很值得借鉴的，如果在准备学习这一块的，可以不深入学，但是可以作为一个了解项，对学习其他相关的组件也很有益。resilience4j虽然被提出，但是使用上还未被广泛，因此在技术选型的时候慎用。现在更多的是使用Spring Clound Alibaba的Sentinel。

服务网关

在Spring Cloud刚出来的两年，Zuul是很火的，随着停更的浪潮，Zuul也是退出了历史舞台，虽然说Spring Cloud想根据Zuul出一个Zuul2，但是目前好像效果并不好，在技术选型中，网关还是优先和推荐的还是Gateway。

服务配置

Spring Cloud Config虽然也不差，但是Spring Cloud Alibaba的Nacos更胜一筹，在能够解决服务注册与发现的同时，还是解决服务配置，岂不是更香，能够一个组件解决的事情，为何要用两个组件呢，再说Spring Cloud Config已经停更了。

服务总线

Spring Cloud Alibaba的Nacos也是可以解决服务总线的问题，原来的Spring Cloud Bus也淡出了研发界的视线。一个Nacos组件同时替代了Eureka、Config、Bus，你说气不气人。因此更体现了Nacos的重要性。

总结

现在市面上最为流行的组合就是Spring Cloud+Spring Cloud Alibaba，使用的组件组合如下：

• Nacos：服务注册与发现、服务总线、服务配置
• Ribbon：服务调用的负载均衡
• OpenFeign：服务调用
• Sentinel：服务熔断与降级
• Gateway：服务网关