微服务组件

微服务组件

作者：知否派。

文章所涉及的资料来自互联网整理和个人总结，意在于个人学习和经验汇总，如有什么地方侵权，请联系本人删除，谢谢！

服务描述

负载均衡：轮循、随机、

服务治理： Spring Cloud Eureka(Netflix)

客户端负载均衡： Spring Cloud Ribbon

声明式服务调用： Spring Cloud Feign

服务容错保护： Spring Cloud Hystrix

API网关服务：Spring Cloud Zuul

分布式配置中心： Spring Cloud Config

1.Dubbo SpringCloud K8s 三大体系

• Dubbo 体系

• Spring Cloud 体系

• K8s 体系

优缺点

Dubbo，亮点是由国内公司阿里巴巴背书，且实际业务中脱产，成熟稳定，RPC高性能支持流量治理，不足之处为耦合度高，更新迭代慢，国外社区小，仅支持JVM运行

SpringCloud，由Netflix 背书，国外社区活跃，程度高，不足之处，JVM运行，耗资源

K8s，由谷歌技术团队背书，技术稳定，省去了很多的技术实现，但是运维门槛高，学习成本大，问题解决复杂

2.微服务使用技术说明

3.SpringCloud总结

1.注册中心:Eureka

1.Eureka

基础描述

SpringCloud框架生态中最原生的深度结合组件，Eureka是Netflix开发的服务发现框架，基于REST的服务，主要用于服务注册，管理，负载均衡和服务故障转移。但是官方声明在Eureka2.0版本停止维护，不建议使用。

组件特点

Eureka包含两个组件：EurekaServer和EurekaClient。

EurekaServer提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。Eureka允许在注册服务的时候，自定义实现检查自身状态的是否健康的方法，这在服务实例能够保持心跳上报的场景下，是一种比较好的体验。

EurekaClient是一个java客户端，用于简化与EurekaServer的交互，客户端同时也就是一个内置的、使用轮询(round-robin)负载算法的负载均衡器。

举个栗子

将consumer 消费者和provide生产者注册到eureka，然后消费者远程调用服务提供者 根据注册中心获取到的服务明细。

2.Zookeeper

Zookeeper组件

1.1基础描述

ZooKeeper是非常经典的服务注册中心中间件，在国内环境下，由于受到Dubbo框架的影响，大部分情况下认为Zookeeper是RPC服务框架下注册中心最好选择，随着Dubbo框架的不断开发优化，和各种注册中心组件的诞生，即使是RPC框架，现在的注册中心也逐步放弃了ZooKeeper。在常用的开发集群环境中，ZooKeeper依然起到十分重要的作用，Java体系中，大部分的集群环境都是依赖ZooKeeper管理服务的各个节点。

1.2组件特点

从Zookeeper的数据结构特点看，并不是基于服务注册而设计的，ZooKeeper提供的命名空间与文件系统的名称空间非常相似，在数据结构上高度抽象为K-V格式，十分通用，说到这里不得不提一下Redis，也可以作为注册中心使用，只是用的不多。

ZooKeeper组件支持节点短暂存在，只要创建znode的会话处于活动状态，这些znode就会存在，会话结束时，将删除znode。Dubbo框架正是基于这个特点，服务启动往Zookeeper注册的就是临时节点，需要定时发心跳到Zookeeper来续约节点，并允许服务下线时，将Zookeeper上相应的节点删除，同时Zookeeper使用ZAB协议虽然保证了数据的强一致性。

3.Consul组件

3.1 基础描述

Consul是用于服务发现和配置的工具。Consul是分布式的，高度可用的，并且具有极高的可伸缩性，而且开发使用都很简便。它提供了一个功能齐全的控制面板，主要特点是：服务发现、健康检查、键值存储、安全服务通信、多数据中心、ServiceMesh。Consul在设计上把很多分布式服务治理上要用到的功能都包含在内了。

3.2组件特点

Consul提供多个数据中心的支持，基于Fabio做负载均衡，每个数据中心内，都有客户端和服务端的混合构成。预计有三到五台服务端。可以在失败和性能的可用性之间取得良好的平衡。数据中心中的所有节点都参与八卦协议。这意味着有一个八卦池，其中包含给定数据中心的所有节点。这有几个目的：首先，不需要为客户端配置服务器的地址;发现是自动完成的。其次，检测节点故障的工作不是放在服务器上，而是分布式的。这使得故障检测比天真的心跳方案更具可扩展性。第三，它被用作消息传递层，用于在诸如领导者选举等重要事件发生时进行通知。

4.Nacos组件

4.1基础描述

Nacos致力于发现、配置和管理微服务。Nacos提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。Nacos更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。Nacos支持作为RPC注册中心，例如：支持Dubbo框架；也具备微服务注册中心的能力，例如：SpringCloud框架。

4.2组件特点

Nacos在经过多年生产经验后提炼出的数据模型，则是一种服务-集群-实例的三层模型。如上文所说，这样基本可以满足服务在所有场景下的数据存储和管理,数据模型虽然相对复杂，但是并不强制使用数据结构的风格，大多数应用场景下，和Eureka数据模型是类似的。

Nacos提供数据逻辑隔离模型，用户账号可以新建多个命名空间，每个命名空间对应一个客户端实例，这个命名空间对应的注册中心物理集群是可以根据规则进行路由的，这样可以让注册中心内部的升级和迁移对用户是无感知的。

5.组件选择

综合上述几种注册中心对比，再从现在SpringCloud框架流行趋势看，个人推荐后续微服务架构体系选择Nacos组件，大致原因如下，社区活跃，经过大规模业务验证，不但可以作为微服务注册中心，也支持作RPC框架Dubbo的注册中心，且有完善的中文文档，总结下来就一句话：通用中间件，省时；文档详细，省心。

6.Zookeeper和Eureka的区别

回顾CAP原则:

RDBMS（Mysql、oracle,sqlserver）=>ACID

Nosql(redis,mongdb)=>CAP

ACID 是什么?

• A 原子性
• C 一致性
• I 隔离性
• D 持久性

CAP 是什么？

• C 强一致性
• A 可用性
• P 分区容错性

CAP 的三进二 ：CA,AP,CP

CAP理论的核心：

• 一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性的三个需求

• 根据CAP原理，将NOsql 数据库分成了满足CA原则，满足CP原则 和满足AP 原则三大类：

  • CA:单点集群，满足一致性 可用性的系统 通常可扩展性较差
  • CP:满足一致性，分区容错的系统 ，通常性能不是很高
  • AP:满足可用性，分区容错的系统 ，通常可能对一致性要求低一些

Eureka比Zookeeper好在哪里?

著名的CAP理论指出，-个分布式系统不可能同时满足C (- 致性)、A (可用性)、P (容错性)。

由于分区容错性P在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡。

• Zookeeper保证的是CP;
• Eureka保证的是AP;

Zookeeper保证的是CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接

down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。 但是zk会出现这样一种情况，当master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长,30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zk集群失去master节点是较大概率会发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证的是AP

响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在， 就能保住注册服务的可用性，只不过查到的发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在， 就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有一 种自我保护机制， 如果在1 5分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况:

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪

2.负载均衡

1.Ribbon

Ribbon是什么?

• Spring Cloud Ribbon是基于Netflix Ribbon实现的一-套客户端负载均衡的工具。

• 简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法,将NetFlix的中间层服务连接在一起。Ribbon的客户端组件提供一系列完整的配置项如: 连接超时、重试等等。简单的说，就是在配置文件中列出LoadBalancer (简称LB: 负载均衡)后面所有的机器，Ribbon会 自动的帮助你基于某种规则(如简单轮询，随机连接等等)去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。

Ribbon能干嘛?

• LB,即负载均衡(Load Balance) ，在微服务或分布式集群中经常用的一种应用。

• 负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA (高可用)。

• 常见的负载均衡软件有Nginx, Lvs 等等

• dubbo、 SpringCloud中均给我们提供了 负载均衡，SpringCloud的负载均衡算法可以自定义

• 负载均衡简单分类:

  • 集中式LB
    • 即在服务的消费方和提供方之间使用独立的LB设施，如Nginx, 由该设施负责把访问请求通过某种策略转发至服务的提供方。
  • 进程式LB
    • 将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出一个合适的服务器
    • Ribbon就属于进程内LB，它只是一个类库, 集成于消费方进程，消费方通过它来获取到服务提供方。

2.负载均衡:Feign

feign是声明式的web service客户端，它让微服务之间的调用变得更简单了，类似controller调用service。 SpringCloud集成了Ribbon和Eureka,可在使用Feign时提供负载均衡的http客户端。只需要创建一个接口， 然后添加注解即可!

feign，主要是社区,大家都习惯面向接口编程。这个是很多开发人员的规范。调用微服务访问两种方法

1.微服务名字[ribbon]

2.接口和注解[feign ]

Feign能干什么?

• Feign旨在使编写Java Http客户端变得更容易
• 前面在使用Ribbon + RestTemplate时，利用RestTemplate对Http请求的封装处理， 形成了-套模板化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处,往往-个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。 所以, Feign在此基础上做了进一步封装，由他来帮助我们定义和实现依赖服务接口的定义，在Feign的实现下，我们只需要创建一个接口并使用注解的方式来配置它(类似于以前Dao接口上标注Mapper注解，现在是一个微服务接口上面标注一个Feign注解.

Ribbon的性能优于Feign,Feign默认继承了Ribbon

Feign和Ribbon的区别

1.是一个基于 HTTP 和 TCP 客户端的负载均衡器 它可以在客户端配置 ribbonServerList（服务端列表），然后轮询请求以实现均衡负载。

2.Spring Cloud Netflix 的微服务都是以 HTTP 接口的形式暴露的，所以可以用 Apache 的 HttpClient 或 Spring 的 RestTemplate 去调用，而 Feign 是一个使用起来更加方便的 HTTP 客戶端，使用起来就像是调用自身工程的方法，而感觉不到是调用远程方法。

3.启动类使用的注解不同，Ribbon 用的是@RibbonClient，Feign 用的是@EnableFeignClient

4.服务的指定位置不同，Ribbon 是在@RibbonClient 注解上声明，Feign 则是在定义抽象方法的接口中使用@FeignClient 声明。

5.调用方式不同，Ribbon 需要自己构建 http 请求，模拟 http 请求然后使用 RestTemplate 发送给其他服务，步骤相当繁琐。

6.Ribbon可配置负载均衡机制

4.服务熔断降级限流

分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免的失败!所谓熔断器机制，即类似电流的保险器，当然电压过高会自动跳闸，从而保护电路系统。微服务架构中服务保护也是这个策略，当服务被判断异常，会从服务列表断开，等待恢复在重新连接。服务熔断降级的策略实现有如下几个常用的组件。

Hystrix

什么是Hystrix

Hystrix是一个用于处理分布式系统的延迟和容错的开源库, 在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix能够保证在一 个依赖出问题的情况下，不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。

“断路器”本身是一种开关装置， 当某个服务单元发生故障之后，通过断路器的故障监控(类似熔断保险丝)，向调用方返回-个服务预期的，可处理的备选响应(FallBack) ，而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

Hystrix能干嘛

• 服务降级
• 服务熔断
• 服务限流
• 接近实时监控.

服务雪崩

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其他的微服务，这就是所谓的"扇出”、如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应"。

对于高流量的应用来说，单- -的后端依赖可能会导致所有服务器上的所有资源都在几秒中内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障,这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。

我们需要.弃车保帅。

熔断器策略

服务器高并发下，压力剧增的时候,根据当业务情况以及流量，对一些服务和页面有策略的降级(可以理解为关闭不必要的服务)，以此缓解服务器资源的压力以保障核心任务的正常运行。熔断生效后，会在指定的时间后调用请求来测试依赖是否恢复，依赖的应用恢复后关闭熔断。

基本流程：

首先判断服务熔断器开关状态，服务如果未熔断则放行请求；如果服务处于熔断中则直接返回。

每次调用都执行两个函数markSuccess(duration)和markFailure(duration) 来统计在一定的时间段内的调用是成功和失败次数。

基于上述的成功和失败次数的计算策略，来判断是否应该打开熔断器，如果错误率高于一定的阈值，就会触发熔断机制。

熔断器有一个生命周期，周期过后熔断器器进入半开状态，允许放行一个试探请求；否则，不允许放行。

Sentinel

基础简介

基于微服务的模式，服务和服务之间的稳定性变得越来越重要。Sentinel以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

Sentinel可以针对不同的调用关系，以不同的运行指标（如QPS、并发调用数、系统负载等）为基准，收集资源的路径，并将这些资源的调用路径以树状结构存储起来，用于根据调用路径对资源进行流量控制。

流量整形策略

直接拒绝模式是默认的流量控制方式，即请求超出任意规则的阈值后，新的请求就会被立即拒绝。

启动预热模式：当流量激增的时候，控制流量通过的速率，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。

匀速排队方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。

熔断策略

Sentinel本质上是基于熔断器模式，支持基于异常比率的熔断降级，在调用达到一定量级并且失败比率达到设定的阈值时自动进行熔断，此时所有对该资源的调用都会被阻塞，直到过了指定的时间窗口后才启发性地恢复。

Hystrix、Sentinel 对比

限流组件

Nginx代理组件

Nginx反向代理实际运行方式是指以代理服务器来接收客户端连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给客户端，此时代理服务器对外就表现为一个服务器。

流量限制是Nginx作为代理服务中一个非常实用的功能，通过配置方式来限制用户在给定时间内HTTP请求的数量，两个主要的配置指令limit_req_zone和limit_req，以此保护高并发下系统的稳定。

流量控制

基本概念

流量控制的核心作用是限制流出某一网络的某一连接的流量与突发，使这类报文以比较均匀的速度流动发送，达到保护系统相对稳定的目的。通常是将请求放入缓冲区或队列内，然后基于特定策略处理请求，匀速或者批量处理，该过程也称流量整形。

流量控制的核心算法有以下两种：漏桶算法和令牌桶算法

漏桶算法

基础描述

漏桶算法是流量整形或速率限制时经常使用的一种算法，它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。

漏桶算法基本思路：请求（水流）先进入到容器（漏桶）里，漏桶以一定的速度出水，这里就是指流量流出的策略，当流量流入速度过大容器无法承接就会直接溢出，通过该过程限制数据的传输速率。

核心要素

通过上述流程，不难发现漏桶算法涉及下面几个要素：

容器容量
1

容器的大小直接决定能承接流量的多少，容器一但接近饱和，要么溢出，要么加快流速；

流出速度
1

流量流出的速度取决于服务的请求处理能力，接口支撑的并发越高，流速就可以越大；

时间控制
1

基于时间记录，判断流量流出速度，控制匀速模式，

注意：需要一个基本的判定策略，漏桶算法在系统能承接当前并发流量时，不需要启用。

令牌桶算法

基础描述

令牌桶可自行以恒定的速率源源不断地产生令牌。如果令牌不被消耗，或者被消耗的速度小于产生的速度，令牌就会不断地增多，直到把桶填满。后面再产生的令牌就会从桶中溢出。

令牌桶算法虽然根本目的也是控制流量速度，但是当令牌桶内的令牌足够多时，则允许流量阶段性的并发。传送到令牌桶的数据包需要消耗令牌。不同大小的数据包，消耗的令牌数量不一样。

核心要素

令牌桶
1

存放按照特定的速率生成的令牌，以此控制流量速度。

匹配规则
1

这里的匹配规则更多是服务于分布式系统，例如服务A是系统的核心交易，当出现并发时，基于令牌桶最匹配规则，只允许交易请求通过，例如：常见双十一期间，各大电商平台提示，为保证核心交易，边缘服务的数据延迟或暂停等。

注意：令牌桶算法和漏桶算法的目的虽然相同，但是实现策略是相反的，不过都存在一个问题，为保证大部分请求流量成功，会牺牲小部分请求。

5.网关

**服务发现：**网关应该有服务发现功能，通过统一注册中心，获取服务列表，这样才能执行统一代理服务和路由转发功能。

**路由请求:**植入网关层服务之后，客户端不知道自己请求的是哪个具体的服务，只需要把请求转发给网关，网关放行之后会把请求路由到指定业务服务上。

**负载均衡:**网关连接的服务实例可能是集群模式存在，所以网关还可以对各个服务实例上执行负载均衡策略，常见的策略就是服务轮询或者按权重路由。

**定制开发例如：**权限校验，日志集成，接口限流，等相关功能，需要和数据库交互，可以做成独立服务，在服务中实现具体的处理逻辑，网关层直接调用即可。

Zuul

Zuul网关主要提供动态路由，监控，弹性，安全管控等功能。在分布式的微服务系统中，系统被拆为了多个微服务模块，通过zuul网关对用户的请求进行路由，转发到具体的后微服务模块中，Netflix开源的一个基于JVM路由和服务端的负载均衡器。

GetWay

Spring cloud gateway是spring官方基于Spring 5.0、Spring Boot2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供简单、有效和统一的API路由管理方式，Spring Cloud Gateway作为Spring Cloud生态系统中的网关，目标是替代Netflix Zuul，其不仅提供统一的路由方式，并且还基于Filer链的方式提供了网关基本的功能，例如：安全、监控/埋点、限流等。

GetWay详解 https://www.cnblogs.com/konglxblog/p/15170636.html

Kong

Kong是一款基于Nginx+Lua编写的高可用，可扩展的开源网关项目，由Mashape公司开放。核心是实现数据库抽象，路由和插件管理，插件可以存在于单独的代码库中，并且可以在几行代码中注入到请求生命周期的任何位置。提供易于使用的RESTfulAPI来操作和配置API管理，并且可以水平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发到各个Server，来应对高并发的网络请求。

Tyk组件

Tyk是一个开源的、轻量级的、快速可伸缩的API网关，支持配额和速度限制，支持认证和数据分析，支持多用户多组织。基于go语言编写，在Java架构系统中使用很少。

Zuul和GetWay区别

Spring Cloud Gateway基于Spring 5、Project Reactor、Spring Boot 2，

使用非阻塞式的API，内置限流过滤器，支持长连接（比如 websockets）

在高并发和后端服务响应慢的场景下比Zuul1的表现要好。

Zuul基于Servlet2.x构建，使用阻塞的API，没有内置限流过滤器，不支持长连接。

Spring Cloud Gateway，使用起来比 Zuul 更简单，配置更方便

两者都能与Sentinel（是阿里开源的一款高性能的限流框架）集成。

6.微服务配置中心

SpringCloud Config

Spring Cloud Config包含config-server、Git和Spring Cloud Bus三大组件：

• config-server提供给客户端获取配置;
• Git用于存储和修改配置;
• Spring Cloud Bus通知客户端配置变更;

本地测试模式下，Spring Cloud Bus和config-server需要部署一个节点，Git使用GitHub就可以。在生产环境中，Spring Cloud Config，config-server需要部署至少两个节点。Spring Cloud Bus如果使用RabbitMQ，普通集群模式至少需要两个节点。

Git服务如果使用GitHub就不用考虑高可用问题，如果考虑到安全性要自建Git私有仓库，整体的成本比较高。Web服务可以部署多节点支持高可用，由于Git有数据的一致性问题，可以通过以下的方式来支持高可用：

• Git+Keepalived冷备模式，当主Git挂了可以马上切到备Git;
• Git多节点部署，存储使用网络文件系统或者通过DRBD实现多个Git节点的数据同步;

性能够用

config: 单独服务,是从git仓库拉取配置信息,然后服务端从config服务里面拉取配置信息缓存到本地仓库，

这里配置的变更比较麻烦,他需要结合bus组件,同时约束了只能用rabbitmq和kafka来进行通知服务端进行配置变更。

但是保证了数据的一致性,因为他的配置信息在git仓库上,git仓库只有一个,就会数据一致

nacos

Nacos部署需要Nacos Service和MySQL：

• Nacos对外提供服务，支持配置管理和服务发现;
• MySQL提供Nacos的数据持久化存储;

单机模式下，Nacos可以使用嵌入式数据库部署一个节点，就能启动。如果对MySQL比较熟悉，想要了解整体数据流向，可以安装MySQL提供给Nacos数据持久化服务。生产环境使用Nacos，Nacos服务需要至少部署三个节点，再加上MySQL主备。

性能最好

他同时支持AP和CP模式,他根据服务注册选择临时和永久来决定走AP模式还是CP模式,

他这里支持CP模式对于我的理解来说,应该是为了配置中心集群,因为nacos可以同时作为注册中心和配置中心,

因为他的配置中心信息是保存在nacos里面的,假如因为nacos其中一台挂掉后,还没有同步配置信息,就可能发生配置不一致的情况.,

配置中心的配置变更是服务端有监听器,配置中心发生配置变化,然后服务端会监听到配置发生变化,从而做出改变

Apollo

Apollo分为MySQL，Config Service，Admin Service，Portal四个模块：

• MySQL存储Apollo元数据和用户配置数据;
• Config Service提供配置的读取、推送等功能，客户端请求都是落到Config Service上;
• Admin Service提供配置的修改、发布等功能，Portal操作的服务就是Admin Service;
• Portal提供给用户配置管理界面;

本地测试Config Service，Admin Service，Portal三个模块可以合并一起部署，MySQL单独安装并创建需要的表结构。在生产环境使用Apollo，Portal可以两个节点单独部署，稳定性要求没那么高的话，Config Service和Admin Service可以部署在一起，数据库支持主备容灾。

Nacos、Apollo、SpringCloud Config微服务配置中心对比

参考资料

1.常见注册中心组件，对比分析 https://www.cnblogs.com/hanease/p/16426102.html

2.Nacos、Apollo、SpringCloud Config 配置中心对比 https://blog.csdn.net/weixin_38405253/article/details/120051899?utm_medium=distribute.pc_relevant.none-task-blog-2_defaultbaidujs_title~default-0-120051899-blog-116648228.pc_relevant_sortByAnswer&spm=1001.2101.3001.4242.1&utm_relevant_index=3

3.SpringCloud与Eureka，Feign，Ribbon，Hystrix，Zuul核心组件间的关系 https://www.jianshu.com/p/31dfb595170c

4.GetWay详解 https://www.cnblogs.com/konglxblog/p/15170636.html