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

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 请求。

⑤调用链路分析

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

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

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

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

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

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

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

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!