前言

前面两篇文章中描述了配置中心的基本架构与基本概念，本节将讲述如何实现配置存储与获取的高可用设计。

配置中心作为整个应用运维体系的基础组件，其重要性可见一斑。如果配置系统不具备高可用的特性，一旦发生配置中心服务不可用，那么影响到的将要成千上万的在线应用，由此带来的损失简直是无法估量。做到配置中心高可用架构可以从以下几个方面着手：

  • 存储高可用
  • API服务高可用
  • 客户端容灾

整体架构

Operator    -------->        Web主控台               ------->     MySQL Master
                                |                                     |
                             (notify)                               (sync)
                                |                                     |
                                ----------|                           |
                                          |                         ---------------------
SDK Client ---（Load Banlancer）----> API Server Cluster               |        |      |
     |                                    |                         slave1   slave2  slave3 ...
  (cache)                            (dump file)                      ^       ^       ^
     |                                    |                           |       |       |
 Local Cache                              |---->Slave Proxy(HaProxy) ------------------------

存储高可用

存储目前使用的是MySQL关系型服务器，采用一主多从的部署方式，主库只负责写入，不负责读取，所以以写为主。配置的读取和提供服务由API服务器承担，API服务器连接的是从库代理，保证只要有一台从库可用，整个服务不会出现问题。配置中心WEB主控台发生配置编辑后，同步写入MySQL主库，随后通知MySQL自身的数据同步，将发生改变的数据同步至多台从库中，这个MySQL之间的数据同步基本可控在毫秒范围。WEB主控台在发生配置编辑后同时会发送一个MQ消息通知API Server集群完成新配置的Dump。

API服务器高可用

API服务器是配置中心SDK与配置中心打交道的门户，它提供RESTFUL服务供客户端使用。API服务设计为无状态，可以水平扩展更多的服务器，以应对更多的应用并发获取配置的流量增长。

  • 每台API服务器会定时从MySQL从库中Dump完整的配置数据到本地磁盘上进行缓存，并在内存中更新该配置的指纹信息。

  • 同时API服务器会订阅WEB主控台发出的消息，对实时的配置修改进行实时的配置Dump。

API服务器提供给配置中心SDK配置拉取服务，它们之间会存在一个负载均衡器来分担流量。

客户端的容灾

客户端通过SDK与API服务器交互取得配置，并缓存获取到的配置写入本地缓存文件。

  • 当应用程序启动时，SDK会携带module/profile/version参数去拉取最新的配置。
  • 应用启动后，SDK会定时再去API服务拉取更新配置，这时携带的参数为module/profile/version/signature。多增加的一个signature是用于指纹对比，只有发生了指纹变化的配置才会被重新拉取

客户端SDK提供给用户三种不同的配置加载策略：

  • SERVER模式 这种模式要求每次启动都必须从API服务器拉取最新配置，如果拉取成功存入本地缓存，如果拉取过程失败，则程序启动失败
  • LOCAL模式 这种模式实际上是兼容以前的本地配置模式，这种模式下不会与配置中心进行任何交互，直接使用的是本地配置文件
  • AUTO模式 这种模式在启动时会尝试从API服务器拉取最新的配置，如果在有限的几次拉取重试失败后，改由本地的上次拉取成功的缓存文件加载引导程序启动

通过客户端的缓存，尽量避免了因为配置中心的故障导致的应用无法启动的问题，当然如果应用是在第一次启动，并且配置中心处于宕机，这个时候启动会失败 =(

总结

配置中心通过三个不同维度的存储与缓存，解决了在分布式环境下配置获取的高可用问题。

  • 配置数据存储高可用
  • API服务器高可用
  • 客户端容灾设计