刚入职没几天，新公司项目是微服务架构，用的是spring cloud那一套，不过配置中心确是换成了携程的开源框架apollo。
总的来说这几天看了一下资料，为基础做个笔记。
github:
https://github.com/ctripcorp/apollo
1.Apollo可以做什么。
apollo是携程框架组研发的一款配置中心管理框架，能够集中化管理不同应用，不同集群的配置。apollo从以下四个维度来进行配置管理。
1.application（应用）
我们一个实际应用实例，每一个应用在apollo中都有一个唯一标识符-appid。类似于eureka中的server-name。对比spring cloud config中相当于在git中配置文件名称的前置应用名。
2.environment（环境）
对应的dev，test之类的环境，对比spring cloud config相当于在git中配置文件名称的后置环境名称。所以环境默认是通过读取机器上的配置（server.properties中的env属性），也支持运行时通过System Property等指定。
配置对应的环境，
3.cluster（集群)
一个引用下按照集群进行分组配置，不同集群可以配置不用的值。集群默认读取机器上的配置（server.properties中的idc属性），也支持运行时通过System Property等指定。
4.namespace（命名空间）
一个应用下按照不同配置进行分组配置，不同类型的配置存放到不同的配置文件当中，比如数据库配置文件，应用自身的配置文件等等。配置与配置之间可以进行继承来对父配置进行属性覆盖。
2.Apollo架构设计
我们从下网上看。
1.ConfigDB,apollo配置中心依赖于mysql，所有的配置首先会被持久化到mysql当中。
2.Config Service提供配置的读取，推送等功能，服务对象是Apollo客户端，也就是我们自己开的实际应用。
3.Admin Service提供配置的修改，发布等功能，服务对象Portal，也就是我们的可视化终端。通常是web形式。
4.Config Service和Admin Service都是多实例，无部署状态，需要将自己注册到我们的eureka注册中心当中。
5.互相进行注册形成高可用的eureka服务治理。
5.Meta Server从eureka获取Admin Service和Config Service，Client，Portal和eureka之间架设了一层Meta Server层，该层属于逻辑上的角色层，目的是为Apollo客户端，和Portal获取到Config Service和AdminService服务列表封装eureka服务发现细节。也就是说，Apollo客户端和Portal直接向Meta Service请求一个Http接口来发现Config Service和Admin Service，而不是我们通常熟悉的自身在像eureka注册的同时，拉取eureka上的有效服务到本地。在部署时，Meta Service层和Config Service层部署在一个jvm中，因此IP，端口和Config Service相同。这边注意一下，client和portal还是会向eureka注册中心注册自己。
6.Portal，一个web配置管理界面，在Portal层作load balance、错误重试。
- 通过Meta Server获取Admin Service服务列表（IP+Port），通过IP+Port访问服务
7.Client，Apollo最终服务的对象，也就是我们自己的微服务。
- 通过Meta Server获取Config Service服务列表（IP+Port），通过IP+Port访问服务
3.配置发布后的实时推送全流程
1.用户在Portal控制台发布配置。
2.Portal调用Admin Service（http形式）的接口进行发布。
3.Admin Service发布配置后，发送ReleaseMessage（异步）给各个Config Service.
4.Config Service接收到消息后，通知Client客户端。
4.关于Admin Service和Config Service的异步通信
Apollo依赖于mysql，这里的异步通信也不例外，同时也是为了尽可能的既减少依赖。Admin Service在配置发布后，需要通知所有的Config Service，所有的Config Service会通知Client拉取最新配置。
流程如下
1.Admin Service在配置发布后会在ReleaseMessage表插入一条消息记录，消息内容就是配置发布的AppId+Cluster+Namespace。
2.Config Service有一个工作线程每一秒会扫描一遍ReleaseMessage表，查看是否有新纪录产生。
3.Config Service发现有新纪录的话就会通知Client注册在Config Service的消息监听器。如NotificationControllerV2
4.NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端。
5.关于Config Service通知Client的实现方式。
1.客户端发起请求Http请求到Config Service的NotificationControllerV2的notifications/v2接口。
2.该接口会把请求挂起，不会立刻返回。
3.如果60秒以内没有该客户端关心的配置发布，那么就会返回Http的304状态码给用户。
4.如果有该用户端关心的配置发布，NotificationControllerV2会调用DeferredResult的setResult方法，传入有配置变化的namespace信息，同时请求立刻返回。客户端从返回的结果中获取到配置变化的namespace后，会立即请求Config Service获取该namespace的最新值。
6.几个重要端口
portal：http://localhost:8070
config service：http://localhost:8080
admin service：http://localhost:8090
部署apollo时务必保证这几个端口未被占用。