首页  思维导图  详情

0703 - Spring Cloud

2021-04-18 10:10:11   4  举报





AI智能生成

架构师技术栈-微服务

java

架构设计

SpringCloud架构图

面试

企业架构

作者其他创作

大纲/内容

理论知识

SOA面向服务

是一种粗粒度、松耦合服务架构，各服务间均需要基于ESB(Enterprise Service Bus,企业服务总线)进行消息通信，它是SOA的细粒度体现，将单体架构系统按照业务进行垂直切成独立的服务，并独立部署、运行；各服务间通常是基于RESTful API（同步）和消息队列（MQ、异步）进行通信

Spring Cloud

分布式微服务架构的一站式解决方案，是多种微服务架构落地技术的集合体，俗称微服务全家桶

中文文档：https://www.bookstack.cn/read/spring-cloud-docs/docs-user-guide-eureka.md

RestTemplate

定义

RestTemplate提供了多种便捷访问远程Http服务的方法，是一种简单便捷的访问restful服务的模板类，是Spring提供的用于访问Rest服务的客户端模板工具集

最新API

https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/web/client/RestTemplate.html

使用

使用RestTemplate访问restful接口非常的简单粗暴无脑（url、requestMap、ResponseBean.class）这三个参数分别代表REST请求地址、请求参数、HTTP响应转换被转换成的对象类型

组成

HttpMessageConverter 对象转换器

ClientHttpRequestFactory 默认是JDK的HttpURLConnection

ResponseErrorHandler 异常处理

ClientHttpRequestInterceptor 请求拦截器

什么是服务治理

在传统的RPC远程调用框架中，管理每个服务与服务之间依赖关系比较复杂，管理比较复杂，所以需要使用服务治理，管理服务于服务之间依赖关系，可以实现服务调用、负载均衡、容错等，实现服务发现和注册。

微服务要解决的四大问题（高可用、高并发、高性能）：网络的不可靠性

1、客户端如何访问这么多的服务

API网关

2、服务与服务之间如何通信

同步通信

HTTP（Apache Http Client）

RPC（Dubbo只支持Java，Apache Thrif，gRPC）

异步通信

Kafka、RabbitMQ、RocketMQ

3、这么多服务、如何管理

服务治理

服务注册与发现

基于客户端的服务注册与发现

Apache Zookeeper

基于服务端的注册与发现

Netflix Eureka

4、服务挂了、怎么办

重试机制

服务熔断

服务降级

服务限流

服务注册发现

服务注册就是维护一个登记簿，它管理系统内所有的服务地址。当新的服务启动后，它会向登记簿交待自己的地址信息。服务的依赖方直接向登记簿要Service Provider 地址就行了。当下用于服务注册的工具非常多ZooKeeper，Consul，Etcd, 还有Netflix 家的eureka 等。服务注册有两种形式：客户端注册和第三方注册。

客户端注册

客户端注册是服务自身要负责注册与注销的工作。当服务启动后向注册中心注册自身，当服务下线时注销自己。期间还需要和注册中心保持心跳。心跳不一定要客户端来做，也可以由注册中心负责（这个过程叫探活）。这种方式的缺点是注册工作与服务耦合在一起，不同语言都要实现一套注册逻辑。

第三方注册

第三方注册由一个独立的服务Registrar 负责注册与注销。当服务启动后以某种方式通知Registrar，然后Registrar 负责向注册中心发起注册工作。同时注册中心要维护与服务之间的心跳，当服务不可用时，向注册中心注销服务。这种方式的缺点是Registrar 必须是一个高可用的系统，否则注册工作没法进展。

API网关

API Gateway 是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade 模式很像。API Gateway 封装内部系统的架构，并且提供API 给各个客户端。它还可能有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。下图展示了一个适应当前架构的API Gateway。

技术选型

Spring Cloud技术栈

服务注册中心

Eureka

Zookeeper

Consul

Nacos

Zookeeper、Consul和Ereka的区别

负载均衡

Ribbon

LoadBalancer

服务调用

Feign

OpenFeign

服务降级

Hystrix

resilience4j

sentienl

服务网关

Zuul

gateway

服务配置

config

Nacos

服务总线

Bus

Nacos

版本截止到2020.2.15

Spring Cloud

Hoxton.SR1

Spring Boot

2.2.2.RELEASE

Spring Cloud Alibaba

2.1.0.RELEASE

Java

Java8

Maven

3.5及以上

MySQL

5.7及以上

项目实战

如何实现热部署

第一步添加devtools依赖

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<scope>runtime</scope>
<optional>true</optional>
</dependency>

第二步添加插件到pom.xml中

<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<fork>true</fork>
<addResources>true</addResources>
</configuration>
</plugin>
</plugins>
</build>

第三步在IDEA中开启自动编译的权限

Settings->Build->Compiler

Automatically、Display、Build、Compile开头的选项勾选

第四步更新值配置

快捷键：ctrl+shift+alt+/ 选择 Registry

勾选compiler.automake.allow.when.app.running、actionSystem.assertFocusAccessFromEdt

第五步重启IDEA

pom.xml

dependencyManagement的作用

Spring Cloud NetFlix

注册中心：Eureka

工作原理

Eureka工作原理图

1、Eureka Server 启动成功，等待服务端注册。在启动过程中如果配置了集群，集群之间定时通过 Replicate 同步注册表，每个 Eureka Server 都存在独立完整的服务注册表信息
2、Eureka Client 启动时根据配置的 Eureka Server 地址去注册中心注册服务
3、Eureka Client 会每 30s 向 Eureka Server 发送一次心跳请求，证明客户端服务正常
4、当 Eureka Server 90s 内没有收到 Eureka Client 的心跳，注册中心则认为该节点失效，会注销该实例
5、单位时间内 Eureka Server 统计到有大量的 Eureka Client 没有上送心跳，则认为可能为网络异常，进入自我保护机制，不再剔除没有上送心跳的客户端
6、当 Eureka Client 心跳请求恢复正常之后，Eureka Server 自动退出自我保护模式
7、Eureka Client 定时全量或者增量从注册中心获取服务注册表，并且将获取到的信息缓存到本地
8、服务调用时，Eureka Client 会先从本地缓存找寻调取的服务。如果获取不到，先从注册中心刷新注册表，再同步到本地缓存
9、Eureka Client 获取到目标服务器信息，发起服务调用
10、Eureka Client 程序关闭时向 Eureka Server 发送取消请求，Eureka Server 将实例从注册表中删除

简介

Eureka是Netflix开发的，一个基于 REST 服务的，服务注册与发现的组件，它主要包括两个组件：Eureka Server 和 Eureka Client

两个组件

Eureka Server

服务注册

服务提供者启动时，会通过Eureka Client向Eureka Server注册信息，Eureka Server会存储该服务的信息，Eureka Server内部有二层缓存机制来维护整个注册表

提供注册表

服务消费者在调用服务时，如果 Eureka Client 没有缓存注册表的话，会从 Eureka Server 获取最新的注册表

同步状态

Eureka Client 通过注册、心跳机制和 Eureka Server 同步当前客户端的状态

Eureka Client

Eureka Client 是一个 Java 客户端，用于简化与 Eureka Server 的交互。Eureka Client 会拉取、更新和缓存 Eureka Server 中的信息。因此当所有的 Eureka Server 节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者，但是当服务有更改的时候会出现信息不一致。

概念解析

服务注册

服务的提供者，将自身注册到注册中心，服务提供者也是一个 Eureka Client。当 Eureka Client 向 Eureka Server 注册时，它提供自身的元数据，比如 IP 地址、端口，运行状况指示符 URL，主页等

服务续约

Eureka Client 会每隔 30 秒发送一次心跳来续约。通过续约来告知 Eureka Server 该 Eureka Client 运行正常，没有出现问题。默认情况下，如果 Eureka Server 在 90 秒内没有收到 Eureka Client 的续约，Server 端会将实例从其注册表中删除，此时间可配置，一般情况不建议更改。

服务续约的两个重要属性

服务续约任务的调用间隔时间，默认为30秒
eureka.instance.lease-renewal-interval-in-seconds=30

服务失效的时间，默认为90秒。
eureka.instance.lease-expiration-duration-in-seconds=90

Eviction 服务剔除

当 Eureka Client 和 Eureka Server 不再有心跳时，Eureka Server 会将该服务实例从服务注册列表中删除，即服务剔除

Cancel 服务下线

Eureka Client 在程序关闭时向 Eureka Server 发送取消请求。发送请求后，该客户端实例信息将从 Eureka Server 的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：
DiscoveryManager.getInstance().shutdownComponent()；

GetRegisty 获取注册列表信息

Eureka Client 从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与 Eureka Client 的缓存信息不同，Eureka Client 自动处理。

Remote Call 远程调用

当 Eureka Client 从注册中心获取到服务提供者信息后，就可以通过 Http 请求调用对应的服务；服务提供者有多个时，Eureka Client 客户端会通过 Ribbon 自动进行负载均衡。

自我保护机制（好死不如赖活着）

原因

在微服务架构下服务之间通常都是跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，网络分区故障，导致此实例被注销。

原理

Eureka 自我保护机制是为了防止误杀服务而提供的一个机制。当个别客户端出现心跳失联时，则认为是客户端的问题，剔除掉客户端；当 Eureka 捕获到大量的心跳失败时，则认为可能是网络问题，进入自我保护机制；当客户端心跳恢复时，Eureka 会自动退出自我保护机制。

Eureka Server 进入自我保护机制，会出现以下几种情况：
(1) Eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
(2) Eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
(3) 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

高可用

集群搭建搭建原理：互相注册、相互守望

负载均衡：Ribbon

概述

是什么

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

官网

https://github.com/Netflix/ribbon/wiki/Getting-Started

Ribbon目前已进入维护模式

未来替换方案-SpringCloud Loadbalance

能干什么

负载均衡

集中式负载均衡

即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件、软件)由该设施负责把访问请求通过某种策略转发至服务的提供方

进程内负载均衡

将LB逻辑集成到消费方，消费方从服务注册中心获知由哪些地址可用，然后自己再从这些地址种选择出一个合适的服务器

Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址

LB负载均衡是什么

简单的说就是将用户的请求分摊的分配到多个服务上，从而达到系统的HA(高可用)，最常见的负载均衡软件Nginx、LVS、硬件F5等

Ribbon本地负载均衡 VS Nginx服务端负载均衡

Nginx是服务器负载均衡，客户端所有请求都会交给nginx，然后由nginx实现转发请求，即负载均衡是由服务端实现的；
Ribbon本地负载均衡，在调用微服务接口的时候，会在注册中心上获取注册信息服务列表之后缓存到JVM本地，从而在本地实现RPC远程服务调用技术。

Ribbon负载均衡演示

负责均衡+RestTemplate

工作原理

第一步先选择EurekaServer，它优先选择在同一个区域内负载较少的server
第二步再根据用户指定的策略，在从server取到的服务注册列表种选择一个地址
其中Ribbon提供了多种策略：比如轮询、随机和根据响应时间加权等

Ribbon架构原理图

Ribbon核心组件IRule

描述

IRule：根据特定算法从服务列表中选取一个要访问的服务

七种负载策略

com.netflix.loadbalancer.RandomRule 随机

随机策略

com.netflix.loadbalancer.RoundRobinRule 轮询

轮询策略

com.netflix.loadbalancer.RetryRlue 先按照RoundRobinRule的策略获取服务，如果获取服务失败则在指定时间内进行重试

重试策略

com.netflix.loadbalancer.WeightedResponseTimeRule 根据响应时间加权，对RoundRobinRule的扩展，响应速度越快的实例选择权限越大，约容易被选择

响应时间加权策略

com.netflix.loadbalancer.BestAvailableRule 先过滤掉由于多次访问故障而处于断路跳闸状态的服务，然后选择一个并发量最小的服务

最小并发策略

com.netflix.loadbalancer.AvailabilityFilteringRule 先过滤掉故障实例，再选择并发较小的实例

最小并发策略

com.netflix.loadbalancer.ZoneAvoidanceRule 默认规则，复合判断server所在区域的性能和server的可用性选择服务器

IRule接口的实现类有以下几种

IRule接口

Ribbon负载均衡算法

LoadBalancerClient（RibbonLoadBalancerClient是实现类）在初始化的时候（execute方法），会通过ILoadBalance（BaseLoadBalancer是实现类）向Eureka注册中心获取服务注册列表，并且每10s一次向EurekaClient发送“ping”，来判断服务的可用性，如果服务的可用性发生了改变或者服务数量和之前的不一致，则从注册中心更新或者重新拉取。LoadBalancerClient有了这些服务注册列表，就可以根据具体的IRule来进行负载均衡。

Ribbon框架源码设计缺陷及优化

接口调用：Feign

已过时，OpenFeign代替

熔断降级：Hystrix

简介

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

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

功能

服务降级

服务熔断

大神论文

https://martinfowler.com/

服务限流

实现原理

命令模式

舱壁模式

货船为了进行防止漏水和火灾的扩散,会将货仓分隔为多个，当发生灾害时，将所在货仓进行隔离就可以降低整艘船的风险。

隔离策略

应用在复杂的分布式结构中，可能会依赖许多其他的服务，并且这些服务都不可避免地有失效的可能。如果一个应用没有与依赖服务的失效隔离开来，那么它将有可能因为依赖服务的失效而失效。
Hystrix将货仓模式运用到了服务调用者上。为每一个依赖服务维护一个线程池（或者信号量），当线程池占满，该依赖服务将会立即拒绝服务而不是排队等待。
每个依赖服务都被隔离开来，Hystrix 会严格控制其对资源的占用，并在任何失效发生时，执行失败回退逻辑。

观察者模式

Hystrix通过观察者模式对服务进行状态监听。
每个任务都包含有一个对应的Metrics，所有Metrics都由一个ConcurrentHashMap来进行维护，Key是CommandKey.name()
在任务的不同阶段会往Metrics中写入不同的信息，Metrics会对统计到的历史信息进行统计汇总，供熔断器以及Dashboard监控时使用。

熔断机制

熔断是参考电路而产生的一种保护性机制，即系统中如果存在某个服务失败率过高时，将开启熔断器，对于后续的调用，不在继续请求服务，而是进行Fallback操作。
熔断所依靠的数据即是Metrics中的HealthCount所统计的错误率。

服务网关：Zuul

概述

官方网站

是什么，能干什么

zuul是spring cloud的网关组件，可以构建动态路由、服务降级、负载均衡的服务网关，通过filter链式调用进行扩展，实现统一认证、调用监控、日志管理等等功能。

组件

ZuulFilter

这是zuul的核心，分为pre、route、post三种类型，分别对应服务调用之前、之中、之后的处理。

ZuulServlet

一个HttpServlet，执行所有ZuulFilter的入口。

Route

路由的一个节点，通常对应某个微服务。

RouteLocator

获取所有Route的接口，有SimpleRouteLocator和DiscoveryClientRouteLocator两种实现，后者继承自前者，前者通过配置文件配置获得，后者扩展了通过服务发现找到所有服务，并默认为所有服务生成path为/serviceId/**的Route。

ZuulController

需要路由的请求的统一处理器，继承自ServletWrappingController，把请求统一代理给ZuulServlet处理。

ZuulHandlerMapping

继承自spring mvc模块的AbstractUrlHandlerMapping，通过RouteLocator 获取到所有Route之后把route的fullPath和ZuulController注册到到HandlerMap中，把网关需要路由的路径统一映射到ZuulController。

Spring Cloud 自研发

消息驱动：Stream

概述

是什么

一句话：屏蔽底层消息中间件的差异，降低切换成本

声明式服务调用：OpenFeign

是什么

Feign是一个声明式WebService客户端，使用Feigh能让编写Web Service给客户端更加简单

能干什么

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

超时控制

日志打印

服务网关：GateWay

服务动态路由

服务统一限流熔断

服务统一缓存

服务统一授权认证

服务统一性能监控

服务统一灰度发布

配置中心：Config

概述

分布式系统面临的配置问题

是什么

能干嘛

解决方案

消息总线：Bus（Kafka、RabbitMQ）

概述

是什么

链路追踪：Sleuth

Spring Cloud 其它

分布式配置中心

Nacos、Apollo、Config区别

携程Apollo

概述

Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

官方文档

https://github.com/ctripcorp/apollo/wiki/Apollo%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83%E4%BB%8B%E7%BB%8D

背景

程序功能日益复杂，配置日益增多，各种功能的开关、参数的配置、服务器地址等等越来越难管理；因此针对程序配置的期望越来越高（配置修改后实时生效、灰度发布、分环境、分集群管理配置、完善的权限审核机制等等）在这样的大环境下传统的通过配置文件、数据库等方式越来越无法满足开发人员对配置管理的需求。

优点

统一管理不同环境、不同集群的配置

Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等
通过命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖

配置修改实时生效（热发布）

用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序

版本发布管理

所有的配置发布都有版本概念，从而可以方便地支持配置的回滚

灰度发布

支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例

权限管理、发布审核、操作审计

应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
所有的操作都有审计日志，可以方便地追踪问题

客户端配置信息监控

可以在界面上方便地看到配置在被哪些实例使用

提供Java和.Net原生客户端

提供了Java和.Net的原生客户端，方便应用集成
支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
同时提供了Http接口，非Java和.Net应用也可以方便地使用

提供开放平台API

Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验，如数据库用户名、密码，Redis服务地址等
对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制

部署简单

配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少
目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来
Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数

工作模型

1、用户在配置中心对配置进行修改并发布
2、配置中心通知Apollo客户端有配置更新
3、Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

Appolo工作模型

高级特性

application（应用）

这个很好理解，就是实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置
每个应用都需要有唯一的身份标识 -- appId

environment (环境)

配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置
我们认为环境和代码无关，同一份代码部署在不同的环境就应该能够获取到不同环境的配置
所以环境默认是通过读取机器上的配置（server.properties中的env属性）指定的，不过为了开发方便，我们也支持运行时通过System Property等指定

cluster (集群)

一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。
对不同的cluster，同一个配置可以有不一样的值，如zookeeper地址。
集群默认是通过读取机器上的配置（server.properties中的idc属性）指定的，不过也支持运行时通过System Property指定

namespace (命名空间)

一个应用下不同配置的分组，可以简单地把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等
应用可以直接读取到公共组件的配置namespace，如DAL，RPC等
应用也可以通过继承公共组件的配置namespace来对公共组件的配置做调整，如DAL的初始数据库连接数

总体设计

1、Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
2、Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
3、Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
4、在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口
5、Client通过域名访问Meta Server获取Config Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Client侧会做load balance、错误重试
6、Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重试
7、为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中

Appolo总体设计（官方）

Appolo总计设计

客户端实现

1、客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
2、客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
--这是一个fallback机制，为了防止推送机制失效导致配置不更新
--客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
--定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。
3、客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
4、客户端会把从服务端获取到的配置在本地文件系统缓存一份
--在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
5、应用程序从Apollo客户端获取最新的配置、订阅配置更新通知

Apollo客户端实现

部署

快速部署

https://github.com/ctripcorp/apollo/wiki/Quick-Start

分布式部署指南

https://github.com/ctripcorp/apollo/wiki/%E5%88%86%E5%B8%83%E5%BC%8F%E9%83%A8%E7%BD%B2%E6%8C%87%E5%8D%97

分布式注册中心

Consul

介绍

Consul是一套开源的分布式服务发现和配置管理系统，由HashiCorp公司用Go语言开发

功能

提供了微服务系统中的服务治理、配置中心、控制总线等功能，这些功能中的每一个都可以根据需要单独使用，也可以一起使用以构建全方位的服务网络，总之Consul提供了一种完整的服务网格解决方案。

服务发现

提供HTTP和DNS两种发现方式

健康监测

支持多种方式HTTP、TCP、Docker、Shell脚本定制化

KV存储

key、value的存储方式

多数据中心

Consul支持多数据中心

可视化Web界面

Spring Cloud Alibaba

注册配置中心：Nacos

服务注册与发现详解

服务心跳与下线详解

服务健康检测详解

Nacos集群架构实战

Nacos集群节点间服务数据同步详解

Nacos集群架构CAP原理详解

AP架构详解

CP架构详解

集群脑裂问题及解决方案

Nacos源码高并发设计精髓

防止读写并发冲突CopyOnWrite设计思路

异步任务及内部队列有效提升系统并发

异步批量同步集群节点数据有效提供系统性能

阿里云超大规模微服务注册中心设计架构详解

项目实战

Docker下安装nacos

安装镜像
[root@localhost ~]# docker pull nacos/nacos-server:1.1.4
-----------------------------------------------------------------------------------------------------------------------------
启动镜像
[root@localhost ~]# docker run --env MODE=standalone --name nacos -d -p 8848:8848 nacos/nacos-server:1.1.4

服务限流降级熔断：Sentinel

限流源码剖析

限流类型详解

QPS限流

线程数限流源码剖析

限流模式详解

限流效果详解

请求快速失败

请求预热

请求排队

限流算法详解

计数器限流