Apollo框架可行性分析
Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。本文意在测试apollo的高可用性与安全性。
一、测试目的
随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址……
对程序配置的期望值也越来越高：配置修改后实时生效，灰度发布，分环境、分集群管理配置，完善的权限、审核机制……
在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。
Apollo配置中心应运而生！
测试apollo的高可用性与安全性。
二、测试范围
本次测试包括以下几个方面：
针对配置文件的修改是否生效
模拟灾难发生（宕机或网络波动等）看是否切换备用Apollo正常工作
模拟大应用发布并发看是否Apollo能抗压正常工作
三、测试环境
3.1 逻辑拓扑
3.2 网络拓扑
3.3 软/硬件环境
环境
角色
IP地址
指向
Portal
MySQLApolloEureka
192.168.103.111
Apollo-portalApollo-configApollo-adminMySQLportalDB->111MySQLconfigDB->111Eureka->111，112
DEV
192.168.103.111192.168.103.112
Apollo-configApollo-adminMySQLportalDB->111MySQLconfigDB->111Eureka->111，112
PRO
192.168.103.113192.168.103.114
Apollo-configApollo-adminMySQLportalDB->111MySQLconfigDB->113Eureka->113，114
四、Apollo测试项对比
针对配置文件的修改是否生效
经测试生效
通过
模拟灾难发生（宕机或网络波动等）看是否切换备用Apollo正常工作
将其中一台服务器down机后，依然可发布
通过
模拟大应用发布并发看是否Apollo能抗压正常工作
经过测试，测试apollo得到如下压测数据
同时由于整体采用apollo框架，对整体项目的压测即对apollo整体框架的压测，给出的压测结论为：
系统经过一系列业务接口的压力测试，在响应与并发量上表现优秀，期间系统稳定可靠，服务器资源波动正常，全部业务场景千万次交互错误率为0%。
业务混合模式在长达8小时（1：2：1.5充值：查询：交易）的测试场景中，压测聚合报告数据表现优秀，720万次业务交互错误率为0%，95%连接响应时间均低于1000毫秒，TPS稳定在250/sec。
通过
五、应急措施
一旦框架出现问题，可能出现的情况：
1. 客户端无法接收到配置情况
2. 服务端无法更新配置发布
针对以上两点，需要仔细分析框架为何会出现此问题从而解决。再次之前应急方案为手动修改配置发布。（注：无论出现何种现象只影响自动化）
六、测试结论
经过Apollo性能测试，发现此框架稳定，能够承载大量信息处理，同时与spring集成最大程度兼容和方便了研发同学的使用与对接，实现了发布自动化，并且符合运维的分布式部署与集群理念，既为当一台服务器发生故障，不影响应用使用。再权限管控方面优异，实现了角色划分，方便管控。
以下为整体可用性分析：
场景
影响
降级
原因
某台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开启配置缓存后，对配置的读取不受数据库宕机影响
以上结论总结：此框架适合大型研发团体，随着团队发展壮大，使用成熟框架是势在必行，此框架符合公司需求，各个测试均通过，可以使用。