基于Spring Cloud的微服务架构分析
共 7267字，需浏览 15分钟
· 2021-11-14
作者：Alex 来源：blog.caogo.cn/2021/06/20/基于Spring-Cloud的微服务架构分析/
Spring Cloud是一个相对比较新的微服务框架，2016年才推出1.0的release版本. 虽然Spring Cloud时间最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。
Spring Cloud 的核心组件
1. Eureka（注册中心）
Eureka 是 Spring Cloud 微服务架构中的注册中心，专门负责服务的注册与发现,里面有一个注册表,保存了各个服务器的 机器和端口。
Eureka Server 的高可用实际上就是将自己作为服务向其他注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用效果。
2. Zuul（服务网关）
Zuul网关负责转发请求给对应的服务，这个组件是负责网络路由的。
Spring Cloud Zuul通过与Spring Cloud Eureka进行整合，将自身注册为Eureka服务治理下的应用，同时从Eureka中获得了所有其他微服务的实例信息
对于路由规则的维护，Zuul默认会将通过以服务名作为ContextPath的方式来创建路由映射。搜索公众号互联网架构师回复“2T”，送你一份惊喜礼包。
Zuul提供了一套过滤器机制，可以支持在API网关无附上进行统一调用来对微服务接口做前置过滤，已实现对微服务接口的拦截和校验
3. Ribbon（负载均衡）
ribbonServerList服务端列表去轮询访问以达到服务均衡的作用。RibbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务端列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来去定服务端是否已经启动通过Spring Cloud Ribbon的封装，我们在微服务架构中使用客户端负载均衡调用只需要如下两步：
4. Hystrix（熔断保护器）
提供线程池不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务器雪崩的问题。
5. Feign（REST转换器）
首先Ribbon会从Eureka Client里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口 然后Ribbon就可以使用默认的Round Robin算法，从中选择一台机器 Feign就会针对这台机器，构造并发起请求
6. Config（分布式配置）
注册中心与API网关的分析
微服务网关更多是在前后端分离，或者说涉及到独立的类似手机APP等前端应用的时候使用的最多，即把内部各个微服务组件模块的API接口能力统一注册和接入到网关，对于APP也只需要访问网关暴露的接口即可，同时通过网关还可以进一步的实现安全隔离。
也就是说在这种场景下，网关更多的是实现了接口服务的代理和路由转发能力，更多的是向外的一种能力发布。
Eureka 的竞品分析：Nacos、ZooKeeper、Etcd
搜索公众号互联网架构师回复“2T”，送你一份惊喜礼包。
Eureka
Spring Cloud Eureka所选择的是AP，采用的是去中心化结构，放弃了强一致性。也就是说Eureka集群中的各个结点都是平等的，没有主从的概念。通过互相注册的方式来进行消息同步和保证高可用。并且一个Eureka Server结点挂掉了，还有其他同等的结点来提供服务，并不会引发服务的中断 Eureka只能当注册中心，想搞配置中心的话，还得搭配Spring Cloud Config+Spring Cloud Bus。其中后者支持Rabbiimq和Kafka两种模式。 使用Java语言来开发的，并且也是Spring Cloud的子项目，所以可以直接通过引入jar包的方式来集成Eureka，这点非常方便
1. ZooKeeper
这是一款经典的服务注册中心产品（虽然它最初的定位并不在于此），在很长一段时间里，它是国人在提起RPC服务注册中心时心里想到的唯一选择，这很大程度上与Dubbo在中国的普及程度有关。
Apache Zookeeper所选择的是CP，也就是放弃了高可用性。Zookeeper集群在进行消息同步的时候，必须有一半以上结点完成了同步才会返回；而当Master结点挂了或者集群中有过半的结点不能工作了，此时就会触发故障恢复，重新进行Master选举。在这个过程中，整个Zookeeper集群无法对外提供服务，从而实去了A（可用性） 为了达到C，Zookeeper采用的是自己的ZAB协议。
2. Nacos
值得一提的是，Nacos作为配置中心的持久化机制可以依赖于 Mysql来完成（默认依赖于内置数据库）。只需要将Nacos目录下的sql脚本放到mysql中执行（会生成11个表），然后在nacos配置文件里面配一下mysql的账号密码即可。这样使用mysql作为数据源的方式相比于nacos内置数据库来说更容易管理
3. Consul
Consul是HashiCorp公司推出的一个开源工具。
Consul是用Go语言编写的，所以无法像Eureka那样直接引入jar包就能集成，它还需要去服务器中进行额外的安装。 除了注册中心的功能之外，Consul还能起到配置中心的作用。
Consul它保证的是CP，使用raft协议，要求必须有过半的结点都写入成功才算是注册成功了，并且它也有Master和Follower的概念，在Master挂掉后，也需要自己内部进行
4. Etcd（待续）
对比SpringCloud，Kubernetes也提供完整的分布式微服务管理框架，几乎所有组件都有对应的产品，其中Etcd也可以提供类似Eureka的注册中心。
在 Go 生态中，还可以选择基于 Etcd 作为注册中心，Etcd 是由 CoreOS 团队维护的、高可用分布式键值存储数据库，可用于为集群提供配置和服务发现功能，Google 开源的容器管理工具 Kuberbetes 就是基于 Etcd 的。
和 Consul 一样，Etcd 也是基于 Raft 协议作为分布式一致性算法来解决领导者选举和日志复制问题，同样也是基于 Go 语言编写。
在目前最新版本的 Etcd v3中，通过网关模式（gateway）取代了 V2 版本中的代理模式（proxy）。
从服务发现的实现原理上来说，Consul 和 Etcd 的基本设计思路是一致的，Etcd 更简单，Consul 则更像一个全栈的解决方案，功能比 Etcd 要更丰富，比如支持可视化的 Web UI 管理界面、支持多数据库中心、安全层面除了 HTTPS 外还支持 ACL、更加全面的健康检查功能、内置 DNS Server 等，这些都是 Etcd 所不具备的，但是更全面的功能往往意味着更高的复杂性，针对微服务的服务注册和发现场景，Etcd 完全够用了。
Spring Cloud 全家桶的简介
Spring Cloud Config：配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git 以及 Subversion。
Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。
Zuul：Zuul 是在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。Archaius：配置管理 API，包含一系列配置管理 API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
Spring Cloud for Cloud Foundry：通过 Oauth2 协议绑定服务到 CloudFoundry，CloudFoundry 是 VMware 推出的开源 PaaS 云平台。
Spring Cloud Data Flow：大数据操作工具，作为 Spring XD 的替代产品，它是一个混合计算模型，结合了流数据与批量数据的处理方式。
Spring Cloud Security：基于 Spring Security 的安全工具包，为你的应用程序添加安全控制。
Spring Cloud Zookeeper：操作 Zookeeper 的工具包，用于使用 Zookeeper 方式的服务发现和配置管理。
Spring Cloud Stream：数据流操作开发包，封装了与 Redis、Rabbit、Kafka 等发送接收消息。
Turbine：Turbine 是聚合服务器发送事件流数据的一个工具，用来监控集群下 Hystrix 的 Metrics 情况。
Spring Cloud Connectors：便于云端应用程序在各种 PaaS 平台连接到后端，如：数据库和消息代理服务。
Spring Cloud Cluster：提供 Leadership 选举，如：Zookeeper，Redis，Hazelcast，Consul 等常见状态模式的抽象和实现。
Spring Cloud Starters：Spring Boot 式的启动项目，为 Spring Cloud 提供开箱即用的依赖管理。