一、服务注册中心

        服务注册中心是一个不进行任何业务处理，单独部署出来提供给其它服务进行服务注册以及服务发现，对服务的健康状态进行检测以及管理的。常见的服务注册中心包括Eureka、Zookeeper、Consul、Nacos等。

CAP定理：CAP定理又称CAP原则，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） 分区容忍性（P），就是高可用性，一个节点崩了，并不影响其它的节点

1.1 Eureka

        Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。Eureka集群是去中心化方式的集群，集群中保证了只要有一个服务存活，就可以提供服务，这种方式无法保证数据的一致性。（文章后续会给出分布式系统中的CAP原理的解释）

        它主要由两个部分组成：

        服务端：主要是提供服务注册中心，可集群部署。

        客户端：向服务注册中心注册自身服务，进行心跳交互，从服务端获取注册列表，从而消费注册列表中的存活服务。

 Eureka通过启动多个服务端并进行互相注册来实现集群部署

1.2 Zookeeper

        与dubbo一样，spring cloud也可以使用zookeeper作为服务注册中心，与Eureka不同的是，zookeeper是一种一主多从的集群方式，leader节点接收到数据的时候，同步数据到follower节点，只有超过一半以上的follower节点同步完成它才会返回写成功，这样的机制使得zk保证了CAP理论的C一致性原则。与Eureka不同，zk的leader节点宕机，会启动选举方式从follower节点中选取一个作为leader，这期间zk无法对外提供服务，无法保证CAP中的A可用性原则。

 1.3 Consul

        Consul是使用GO语言编写的注册中心，基于Raft算法，与Zk类似，Consul提供强一致性的注册中心服务，也是主从同步的方式提供注册服务。

1.4 Nacos

       Nacos 是阿里的开源项目，nacos主要功能是服务发现和微服务的配置集中管理。根据官网的解释如下。

        

        Nacos和Zookeeper都可以作为配置中心，做一些可以实时变化的配置数据存储，然后实时更新线上数据。   作为注册中心，nacos支持两种方式的注册中心，持久化和非持久化存储服务信息，可以支持CP或是AP原则，当节点数据发生变化时，与ZK类似会主动发布给所有的服务节点，Eureka则需要服务节点主动去拉去，如果不主动拉去是不会进行推送的，这里拉取了网上大神对于几个注册中心的总结。

 （如图片侵权，联系删除） 

二、负载均衡

2.1 什么是负载均衡

        负载均衡（load balancing）简称LB，在微服务架构体系一般称为进程内LB，是一种计算机技术，应用于多个计算机集群组中的网络、CPU、内存、磁盘或其它资源的一种分配策略，以达到最优的资源分配使用方式，提高资源使用效率，最大吞吐量，最小响应时间。

2.2 为什么要用负载均衡

        Spring cloud作为一个微服务架构，同一个服务会有多个服务提供者，在消费者进行消费的时候，就需要根据当前集群中的资源（cpu、内存等）来进行分配调用方案，或者遵循某一个负载策略来进行调用以规避某一个服务提供方因为调用过多导致服务器压力过大的情况。

2.3 常见的负载均衡组件

        Spring cloud最常见的负载均衡组件，Ribbon、Feign、OpenFeign。

Ribbon是Netflix实现的一种客户端均衡工具，主要功能是提供客户端的软件负载均衡算法和服务调用。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面所有的服务提供者，Ribbon会自动的基于某种负载策略（如轮询，随机等）去访问这些服务提供方。我们很容易使用Ribbon实现自定义的负载均衡算法。

Feign是Netflix开发的一代负载均衡客户端，内置的Ribbon，是对Ribbon的一种封装解决方案，Feign本身不支持Spring MVC的注解，使用Feign的注解定义接口，调用这个接口，就可以调用服务注册中心的服务。Feign在2019年之后就不再进行更新。

OpenFeign是Spring cloud自己研发的二代负载均衡客户端，与feign一样都内置了Ribbon，在Feign的基础上支持了Spring MVC的注解，如@RequesMapping等等，OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。

三、熔断降级

        作为一个优秀的开发者，当用户在访问我们的网站的时候，因为网络波动、功能bug、瞬间的高并发压力等导致了网页访问请求异常，我们不应将后端的异常结果展示到用户的眼前，应当提供一个友好界面或友好提示来提示用户当前服务暂不可用。Spring cloud作为一个优秀的微服务架构，就提供了服务熔断以及服务降级来为我们进行保驾护航。

3.1 什么是熔断？

        服务熔断类似于电路的保险丝，为了防止电压过高引起火灾，断开电路，过后重启后可继续使用。当服务的调用出现大量的超时或异常，这时就会断开服务的调用，返回一个友好提示，缓解服务的压力，待到一段时间之后进行尝试放行，如果这时服务无法使用将继续断开，服务可用时可将链路释放正常使用。

3.2 什么是降级？

        服务降级是当某个时间段的服务器因为并发过大等原因导致服务器压力剧增，根据业务情况以及流量针对一些服务或页面进行有策略的降级，以此来释放服务器资源，留给核心服务使用，保障核心任务的执行。服务降级可分为接口拒绝或限流等方式。

3.3 常见的熔断降级组件

        对于Spring cloud来讲，最常见的组件分别是Hystrix、Sentinel、resilience4j，其中Hystrix属于Netflix开发的组件，Sentinel属于阿里的开源项目，resilience4j在国外比较受欢迎，国内更多的开发者更喜欢使用Hystrix及Sentinel，近年来阿里体系的Sentinel会更受国内开发者青睐。

这里推荐一个博主对于Hystrix及Sentinel的一些比对文章，个人觉得写的很详细（Sentinel 对比 Hystrix（选型与简介）_MayMatrix的博客-CSDN博客_sentinel和hystrix）

四、路由网关

4.1 网关介绍

        Spring cloud作为一个微服务架构，如果没有一个统一的网关入口，那么所有的服务都需要对外暴露接口，安全上就得不到保障，其次对于身份验证、安全、过滤等都需要全部服务来实现，工作量巨大不讲，后续迭代更新更是繁杂，所以我们需要一个统一网关作为所有api的入口，进行统一化的过滤、身份验证等。

网关是为微服务框架提供一种简单而有效的统一的 API 路由管理方式，统一访问接口。

        Spring cloud的网关发展史可以说是一部爱恨情仇的肥皂剧了，感兴趣的朋友可以自行前去了解一下，这里就大概介绍一下，最开始Netflix推出第一代网关zuul1，后面随着Spring cloud的出现，开始引入Netflix的开源组件，其中就包含了上面讲的Hystrix、Eureka以及zuul1，后面使用过程中发现饿了zuul1存在性能问题，Netflix宣布对其进行优化，结果后面Netflix因为各种各样的原因跳票了，导致了后面Spring与Netflix之间后续分手了，所以Spring cloud推出了自己的网关gateway，虽然后面Netflix也推出了zuul2，可是Spring cloud还是主推自己的网关（毕竟亲儿子）。

        讲了这么多，就大概介绍一下zuul1、zuul2及gateway之间的区别吧。zuul1是BIO方式，zuul2与gateway是NIO。zuul2及gateway二者底层都是reactor模式，性能上比zuul1时代提高很多，所以zuul1不考虑。至于选择哪一个，可从自身架构的角度进行，gateway社区更加成熟，很多功能已经开发完善，直接配置就可以使用，zuul2则需要更多的开发才能完整实现一些特性功能，会更加灵活，且gateway支持nacos而zuul2不支持，对于国内开发者来讲gateway是更优的选择。

五、配置中心

5.1 配置中心

        微服务架构将业务分成一个个的子服务，每一个子服务的运行都离不开配置的支撑，在开发、测试、生产等环境下各个服务的配置都可能不一样，比如数据库、注册中心等。当子服务增多到一定量的时候，对配置文件的修改就变得越来越复杂，于是就出现了统一配置中心，可以通过配置中心，运行期间可以动态调整。例如根据各个微服务的负载状况，动态调整数据源连接池大小或者熔断阀值，并且调整时不停止微服务（配置修改后可以自动更新）

• Spring cloud config

        Spring cloud自带的配置中心，与spring无缝衔接，支持git，但是无可视化操作界面，且配置生效非实时，需要重启或手动刷新。

• Nacos Config

        Nacos Config是阿里技术栈里的一个组件，前面我们已经讲过它可以作为服务注册中心。其实它也集成了服务配置的功能，我们可以直接使用它作为服务配置中心，它提供了可视化界面进行操作，且实现可动态更新。