关于测试项目从disconfig配置文件，接入Apollo配置中心的记录和心得

一.Apollo介绍和特点

1.Apollo介绍

Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。

Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。

.Net客户端不依赖任何框架，能够运行于所有.Net运行时环境。

2.Apollo特性

背景：

随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址……

对程序配置的期望值也越来越高：配置修改后实时生效，灰度发布，分环境、分集群管理配置，完善的权限、审核机制……

在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。

Apollo配置中心应运而生！

对比之前代码内部取配置文件disconfig，有如下优点：

1.统一管理不同环境、不同集群的配置

Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。

同一份代码部署在不同的集群，可以有不同的配置，比如zk的地址等

通过命名空间（namespace）可以很方便的支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖

2.配置修改实时生效（热发布）

用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序。

3.版本发布管理

所有的配置发布都有版本概念，从而可以方便的支持配置的回滚。

4.灰度发布

支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例。

5.权限管理、发布审核、操作审计

应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。

所有的操作都有审计日志，可以方便的追踪问题。

6.客户端配置信息监控

可以方便的看到配置在被哪些实例使用

7.提供Java和.Net原生客户端

提供了Java和.Net的原生客户端，方便应用集成

支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）

同时提供了Http接口，非Java和.Net应用也可以方便的使用

8.提供开放平台API

Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。

不过Apollo出于通用性考虑，对配置的修改不会做过多限制，只要符合基本的格式就能够保存。

在我们的调研中发现，对于有些使用方，它们的配置可能会有比较复杂的格式，如xml, json，需要对格式做校验。

还有一些使用方如DAL，不仅有特定的格式，而且对输入的值也需要进行校验后方可保存，如检查数据库、用户名和密码是否匹配。

对于这类应用，Apollo支持应用方通过开放接口在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制

9.部署简单

配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少

目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来

Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数

3.工作原理

1. 基础模型

如下即是Apollo的基础模型：

用户在配置中心对配置进行修改并发布

配置中心通知Apollo客户端有配置更新

Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

2.总体架构：

用户在Portal操作配置发布

Portal调用Admin Service的接口操作发布

Admin Service发布配置后，发送ReleaseMessage给各个Config Service

Config Service收到ReleaseMessage后，通知对应的客户端

3.客户端：

上图简要描述了Apollo客户端的实现原理：客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。这是一个fallback机制，为了防止推送机制失效导致配置不更新客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中客户端会把从服务端获取到的配置在本地文件系统缓存一份在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置应用程序从Apollo客户端获取最新的配置、订阅配置更新通知

二.Apollo配置步骤。

1.Apollo界面

2 完整配置一个

一般是开发已添加，测试人员只需测试就OK。下面简单介绍下怎么添加和配置。

2.1新建项目

2.2新建集群Cluster（环境）

2.3新建Namespace

2.4 配置文件写入或者修改。

比较简单我就不赘述了。

2.5 发布。

修改后点击发布就发布成功。注意，此处书写的格式有要求，自己可以多多琢磨。

以上就是整个创建和发布的过程。

二.测试过程需要测试的点和注意的点

以下是各人测试心得：

1.接入到Apollo，服务启动是否正常。

进入项目管理里，每个工程下查看启动日志，或者 ps -ef |grep '工程'，查看是否又启动失败或者异常。

shell脚本更方便：（自己可以修改）

#!/bin/bash

dirs=(pay-parent-pom pay-soa-base pay-spi pay-soa-spi pay-soa-framework soa-proxy-client pay-soa-gateway pay-soa-channel pay-soa-wallet basic-soa-pay pay-notify-web pay-notify-router pay-soa-risk pay-job pay-cron-job pay-risk-job pay-kms-spi pay-kms-client pay-soa-card)

for i in "${dirs[@]}";

do

while：

do

echo ‘服务$i启动状态’

echo -n "输入1继续，输入2下一个服务，输入其他结束"

read line

echo "$line"

if [ $line = "1" ];then

echo ‘服务$i启动状态如下：’

ps -ef |grep $i

elif [ $line = "2" ];then

break

else

exit 0

fi

done

done

2.看Apollo文件内和Jenkins内存是否一致。（原理看上面介绍）

3.每个工程下面修改配置项，相应的功能可以生效。

个人建议一个工程挑选2处测试，功能相应生效就可以。

Apollo发布动作，工程日志也有相应的提示，修改前后者修改后，如没有，个人建议让开发加上，第一，好测试，直观，第二，报错修改日志，避免后面生产历史数据，各方扯皮。

4.Apollo机制，各个功能会拎出来。

拎出来的地方，重点测试下，比如公共项（一般修改主其他其他同时生效），日志配置是否功能正常。等等

5.其他测试注意点。

1.主配置里加了一个启动项：main.class = com.globalegrow.pay.job.PayJobApp 

2.工程的启动脚本因接入Apollo有变化（重点测试），不止看启动的过程状态，要看启动文件里，启动什么东西，比如静态文件，动态等

3.兼容测试，同步生产配置到Apollo，新的测试环境部署，跑接口自动化和UI自动化，看是否有异常。

4.稳定性测试，性能是否受到影响。重启时过程是否被影响到，先关端口号，在关闭程序等。

5.  ...........