本文内容总结分布式配置Apollo如何提高可用性
以下：
官方文档请看https://github.com/ctripcorp/apollo/wiki
前面已经提到Apollo如何将配置从代码中抽离，也结合Springboot项目进行了演示，但是这些还不够。前面提到的所有内容都是准对开发测试阶段进行的演示，众所周知一旦我们的应用正式上线则必须保证我们的服务是高可用的。在以前配置和代码还是耦合在一起的时候我们只需要保证运行代码的服务器、数据库是高可用的即可，但是现在又多了一项，那就是要保证我们的Apollo配置中心必须实现高可用。
首先Apollo已经实现了高可用，它本身就是支持分布式的，注册中心采用的是Eureka，项目使用了Spring Cloud和Spring Boot做开发，外部依赖少，同时代码开源，当遇到bug时可以快速的定位。
| 场景 | 影响 | 原因 | |
|---|---|---|---|
| 某台Config Service下线 | 无影响 | Config Service无状态，客户端重连其它Config Service | |
| 所有Config Service下线 | 客户端无法读取最新配置，Portal无影响 | 客户端重启时，可以读取本地缓存配置文件。如果是新扩容的机器，可以从其它机器上获取已缓存的配置文件 | |
| 某台Admin Service下线 | 无影响 | Admin Service无状态，Portal重连其它Admin Service | |
| 所有Admin Service下线 | 客户端无影响，Portal无法更新配置 | ||
| 某台Portal下线 | 无影响 | Portal域名通过SLB绑定多台服务器，重试后指向可用的服务器 | |
| 全部Portal下线 | 客户端无影响，Portal无法更新配置 | ||
| 某个数据中心下线 | 无影响 | 多数据中心部署，数据完全同步，Meta Server/Portal域名通过SLB自动切换到其它存活的数据中心 | |
| 数据库宕机 | 客户端无影响，Portal无法更新配置 | Config Service开启配置缓存后，对配置的读取不受数据库宕机影响 |
数据库高可用
这里有很多种方案，比如主从结构、异地备份、双主结构等等，我这里是选择直接购买Azure的Mysql数据库服务，让云服务厂商去保证数据库的高可用性，这样不仅比自己实现起来更可靠、更轻松，而且还方便管理等。
AdminService高可用
在Apollo中所有的Admin Service都会注册到Eureka里，所以我们只需要配置多几台AdminService，数据库采用同一套即可。
ConfigService和Eureka高可用
在Apollo的设计中每个ConfigService还是一个Euerka的注册中心，所以保证ConfigService高可用的前提是保证Eureka的高可用，Eureka的高可用实际上就是将自己作为服务向其他服务注册中心注册自己,这样就可以形成一组互相注册的服务注册中心,以实现服务清单的互相同步,达到高可用的效果。我这里是设置了一个负载均衡和三台机器，三台机器上运行ConfigService（同时又是Eureka），然后三台ConfigService分别向负载均衡的地址注册Eureka的服务，然后通过负载均衡向内部转发到可用的机器上面（通过Azure的运行状态探测功能实现判断后端机器是否可用）达到相互注册的目的。
已上是架构示意图，当其中一台ConfigService停止服务时，还有两台ConfigService可以对外提供服务。
需要修改的地方是
（1）数据库中Eureka的地址修改为负载均衡的地址
（2）Apollo-Portal中的配置文件apollo-env.properties里修改为负载均衡的地址
（3）Springboot程序中使用apollo.meta修改为负载均衡的地址
#####ApolloPortal高可用
和普通的服务高可用原理一样，建议多几台机器，同时对外有一个负载均衡，机器放到负载均衡后面即可，一般只需两台即可。
做完以上这些步骤便可以保证配置中心Apollo服务为高可用的，以上无论哪一台机器挂机都可以继续愉快的使用Apollo的功能，除非遇到所有机器挂机的情况，但是即使是这样，在我们的应用服务器中还有配置的本地缓存文件，所以，即使是Apollo全部的服务器都挂机，我们的程序也依然可以对外提供正常的服务，只是无法再更新配置了而已。个人感觉Apollo在高可用架构上考虑的十分周全，值得点赞！