我们知道软件系统基本可以从两个维度进行分割，纵向上我们称之为开发维度，横向上我们可以称之为运维维度。开发是一个迭代的过程，在迭代的过程中产生不同的版本，但重要的版本是相互独立的。基本上我可以将其命名为dev、fat、uat、pro等。这些环境虽然相互独立，但基本上还是具有很多相同的配置，当然也有很多不同的配置。在横向上，系统可以单节点部署，也可以多节点部署，多节点部署的问题是：相同的配置同时存在于不同的节点上，同时还有可能不同的节点稍有差异。然而在数学上，这种情况是可以提取公因式的。而apollo就是专门管理系统在这两个维度上的关系的。

当然提取公因式也是有代价的，那就得承担相应的责任。为了避免因为apollo配置中心宕机而引起整个系统的不可用，apollo采用spring cloud分布式的方式，以服务提供者集群和服务消费者集群的模式来保障系统的高可用。这里简单介绍一下，服务提供者和服务消费者模式的基本体系。为了提升系统的并发处理能力，需要将系统进行并行化，然而cpu以进程和线程进行任务调度，所以在cpu上寻找强大的处理能力在一般的pc上还是不太可能。但是可以将运行相同程序的pc部署多个，在系统调用上，我们只需决定某一台pc处理这条信息即可。处理完毕之后，将其返回给调用者，最后返回给用户。当然这里的pc可以随时部署。当时如何调用调度和分配却成为问题。因为我们的这里的pc是动态扩展的。但这并不是没有办法，对一个社会人来说，他没必清楚的知道市政府大楼里每层每个房间都是做什么的。他只需要去市政府大楼的前台咨询一下就好了，这个方便。而分布式系统也是基于此。所以在分布式中也有一个前台，我们称之为“注册中心”，它的作用就是用来告诉服务消费者我们的服务提供者目前的地址以及它目前的状态。然后服务消费者可以根据自己对注册中心提供的信息进行决策，最后决定我应该将我的请求发送给谁。这就是典型的服务提供者-服务消费者模型。

apollo也是基于服务提供者和服务消费者模型的，只是稍微的区别是，服务消费者变成了apollo-client（apollo客户端）。具体的过程可以描述如下。当项目启动的时候，apollo-client会获取应用的配置证书（appid）

去apollo集群的配置中心获取配置服务（configService）的地址，并通过相关算法去该地址获取该应用的配置信息。获取配置信息之后，项目启动，将配置文件作用于相应的程序中，加载各种配置，完成系统的初始化。在多环境情况下，将不同的环境集群部署即可实现不同环境的高可用，但一般来说。我们只需将生产环境进行集群部署。

apollo配置管理，apollo提供了3个组件来实现配置的高可用，分别为configService（配置提供者服务+注册中心Eruka）、adminService（配置管理服务）、portalService（apollo图形界面管理）。其中configService+apollo-client是用于高可用。adminService仅仅用于转发portalService对configService的操作（增删改查等）。由于adminService在无需高可用，所以不需要和configService整合在一起。所以整体来看，apollo的体系架构为下图所示：

其中的portalDB存放的是portalService管理的相关信息，包括用户登录和环境等信息。

以上是对apollo配置中心的简单介绍，对apollo的使用，我将在近期的推文中进行说明。