spring Cloud全家桶及微服务架构的核心概念
文章目录
-
- 了解Spring Cloud
- Spring Cloud中的核心组件
-
- Spring Cloud Netflix组件
- Spring Cloud Alibaba组件
- Spring Cloud原生及其他组件
- 微服务中的核心概念
-
- 服务注册与发现
- 负载均衡
- 服务熔断
- 链路追踪
- API网关
- 关于停更的影响
-
- 服务注册与发现
- 服务调用（负载均衡）
- 服务调用
- 服务降级
- 服务网关
- 服务配置
- 服务总线
- 总结
了解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：服务网关