7.1.3. 配置中心
配置中心一般用作系统的参数配置，它需要满足如下几个要求：高效获取、实时感知、分布式访
问。
7.1.3.1.
zookeeper 配置中心
实现的架构图如下所示，采取数据加载到内存方式解决高效获取的问题，借助 zookeeper 的节点
监听机制来实现实时感知。
7.1.4. 事件调度（kafka）
消息服务和事件的统一调度，常用用 kafka ，activemq 等。
7.1.5. 服务跟踪（starter-sleuth）
随着微服务数量不断增长，需要跟踪一个请求从一个微服务到下一个微服务的传播过程， Spring
Cloud Sleuth 正是解决这个问题，它在日志中引入唯一 ID，以保证微服务调用之间的一致性，这
样你就能跟踪某个请求是如何从一个微服务传递到下一个
1. 为了实现请求跟踪，当请求发送到分布式系统的入口端点时，只需要服务跟踪框架为该请求
创建一个唯一的跟踪标识，同时在分布式系统内部流转的时候，框架始终保持传递该唯一标
识，直到返回给请求方为止，这个唯一标识就是前文中提到的 Trace ID。通过 Trace ID 的记
录，我们就能将所有请求过程日志关联起来。
2. 为了统计各处理单元的时间延迟，当请求达到各个服务组件时，或是处理逻辑到达某个状态
时，也通过一个唯一标识来标记它的开始、具体过程以及结束，该标识就是我们前文中提到
的 Span ID，对于每个 Span 来说，它必须有开始和结束两个节点，通过记录开始 Span 和结
束 Span 的时间戳，就能统计出该 Span 的时间延迟，除了时间戳记录之外，它还可以包含一
些其他元数据，比如：事件名称、请求信息等。
3. 在快速入门示例中，我们轻松实现了日志级别的跟踪信息接入，这完全归功于spring-cloud
starter-sleuth 组件的实现。在 Spring Boot 应用中，通过在工程中引入 spring-cloud
starter-sleuth 依赖之后， 它会自动的为当前应用构建起各通信通道的跟踪机制，比如：
通过诸如 RabbitMQ、Kafka（或者其他任何 Spring Cloud Stream 绑定器实现的消息
中间件）传递的请求。
通过 Zuul 代理传递的请求。
通过 RestTemplate 发起的请求。
7.1.6. 服务熔断（Hystrix）
在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个
系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不
可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。
熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到
许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序
不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费 CPU
时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经
修正，应用程序会再次尝试调用操作。
7.1.6.1.
Hystrix 断路器机制
断路器很好理解, 当 Hystrix Command 请求后端服务失败数量超过一定比例(默认 50%), 断路器会
切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态
一段时间后(默认 5 秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况,
如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix 的断路器
就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效
请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力。
7.1.7. API 管理
SwaggerAPI 管理工具。
