我的天，你们公司的“微服务”简直就是反人类…(7)

可以看到早期的配置中心处理的东西还是比较简单，那个时候业务没有那么复杂，读取配置和更新配置没有那么多花样，持久化存储和本地缓存，长连接更新就可以。但是现在的配置中心随着技术的发展承担的作用可能更多。

Spring Cloud Config：作为 Spring 官方提供的配置中心可能比较符合外国人的习惯。

Spring Cloud Config 将不同环境的所有配置存放在 Git 仓库中，服务启动时通过接口拉取配置。

遵循 {ServiceID}-{profile}.properties 的结构，按照 Profile 拉取自己所需的配置。

当开发者修改了配置项之后，需要结合 Spring Config Bus 将配置通知到对应的服务，实现配置的动态更新。

可以看到，Spring Cloud Config 已经具备了一个配置中心的雏形，可以满足小型项目对配置的管理，但仍然有着很多局限性。

配置使用 Git 库进行管理，那么 Git 库的权限如何来判断?不同环境的安全性也得不到保障。

配置的添加和删除，配置项的汇总，也只能通过 Git 命令来实现，对运维人员也并不友好。

Apollo(阿波罗)：是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。

Apollo 支持四个维度管理 Key-Value 格式的配置：

Application(应用)：实际使用配置的应用，Apollo 客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置;每个应用都需要有唯一的身份标识 – appId，应用身份是跟着代码走的，所以需要在代码中配置。

Environment(环境)：配置对应的环境，Apollo 客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置。

Cluster(集群)：一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。

对不同的 Cluster，同一个配置可以有不一样的值，如 ZooKeeper 地址。

Namespace(命名空间)：一个应用下不同配置的分组，可以简单地把 Namespace 类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC 配置文件，应用自身的配置文件等。

应用可以直接读取到公共组件的配置 Namespace，如 DAL，RPC 等;应用也可以通过继承公共组件的配置 Namespace 来对公共组件的配置做调整，如 DAL 的初始数据库连接数。

Apollo 配置中心包括：

Config Service：提供配置获取接口、配置推送接口，服务于 Apollo 客户端。

Admin Service：提供配置管理接口、配置修改发布接口，服务于管理界面 Portal。

Portal：配置管理界面，通过 MetaServer 获取 Admin Service 的服务列表，并使用客户端软负载 SLB 方式调用 Admin Service。

上图简要描述了 Apollo 的总体设计，我们可以从下往上看：

Config Service 提供配置的读取、推送等功能，服务对象是 Apollo 客户端。

Admin Service 提供配置的修改、发布等功能，服务对象是 Apollo Portal(管理界面)。

Config Service 和 Admin Service 都是多实例、无状态部署，所以需要将自己注册到 Eureka 中并保持心跳。

在 Eureka 之上我们架了一层 Meta Server 用于封装 Eureka 的服务发现接口。

Client 通过域名访问 Meta Server 获取 Config Service 服务列表(IP+Port)，而后直接通过 IP+Port 访问服务，同时在 Client 侧会做 Load Balance、错误重试。

Portal 通过域名访问 Meta Server 获取 Admin Service 服务列表(IP+Port)，而后直接通过 IP+Port 访问服务，同时在 Portal 侧会做Load Balance、错误重试。

为了简化部署，我们实际上会把 Config Service、Eureka 和 Meta Server 三个逻辑角色部署在同一个 JVM 进程中。

客户端设计：

上图简要描述了 Apollo 客户端的实现原理：

客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。

客户端还会定时从 Apollo 配置中心服务端拉取应用的最新配置。这是一个 Fallback 机制，为了防止推送机制失效导致配置不更新。

客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回 304 - Not Modified。

定时频率默认为每 5 分钟拉取一次，客户端也可以通过在运行时指定 System Property: apollo.refreshInterval 来覆盖，单位为分钟。

客户端从 Apollo 配置中心服务端获取到应用的最新配置后，会保存在内存中。

客户端会把从服务端获取到的配置在本地文件系统缓存一份，在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置。

应用程序从 Apollo 客户端获取最新的配置、订阅配置更新通知。

配置更新：前面提到了 Apollo 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。

长连接实际上是通过 Http Long Polling 实现的，具体而言：

客户端发起一个 Http 请求到服务端。

服务端会保持住这个连接 60 秒，如果在 60 秒内有客户端关心的配置变化，被保持住的客户端请求会立即返回，并告知客户端有配置变化的 Namespace 信息，客户端会据此拉取对应 Namespace 的最新配置。

如果在 60 秒内没有客户端关心的配置变化，那么会返回 Http 状态码 304 给客户端。

客户端在收到服务端请求后会立即重新发起连接，回到第一步。

考虑到会有数万客户端向服务端发起长连，在服务端使用了 async servlet(Spring DeferredResult)来服务 Http Long Polling 请求。

⑤调用链路分析

服务调用链路分析在微服务中是幕后至关重要的使者，试想几百个服务掺杂在一起，你想捋出谁先调用了谁，谁被谁调用，如果没有一个可监控的路径，光凭脑子跟踪那得多累。

基于这种需求，各路大神们集中脑汁展开遐想弄出一套分布式链路追踪神器来。

在介绍调用链监控工具之前，我们首先需要知道在微服务架构系统中经常会遇到两个问题：

跨服务调用发生异常，要求快速定位当前这次调用出问题在哪一步。

跨服务的调用发生性能瓶颈，要求迅速定位出系统瓶颈应该如何做。

打个比方说我们有两个服务：订单中心，库存中心。用户下单，先去查询库存系统，那么调用链路分析系统对于一个下单查询服务应该记录什么呢?

我们造出如下一张调用链路请求记录表，表字段如下：

（编辑：ASP站长网）