[JD] 四、配置中心分析

[JD] 四、配置中心分析

一、配置中心在分布式架构中的作用
二、开源配置中心产品选型
三、Apollo深入分析

一、配置中心在分布式架构中的作用
1.配置的作用
    可以在不重新编译代码的情况下，改变程序运行逻辑、调整整体边界，被调用模块路由信息等。方便维护，提高工作效率。
2.本地配置 一般重启生效，不容易维护，生效慢
3.配置中心 
    配置中心是分布式系统中集中化管理线上应用程序配置的管理中心。可以做到集中管控、批量操作和热发布。
    配置中心一般具备以下功能：
        1> 配置项管理：支持添加，发布，修改配置项以及配置项的分组；可以做到版本管理；支持热发布、灰度发布、环境隔离；提供api接口与可视化操作页面
        2> 权限控制：配置项访问控制，读权限和写权限
        3> 操作审计：支持记录用户的操作行为

二、开源配置中心产品选型
1.主流的配置中心对比

三、阿波罗深入剖析
1.Apollo的整体架构

从下往上看：
    Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
        4C8G的虚拟机实测- 可以支撑10000个连接。接口服务对象为Apollo客户端
    Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
        接口服务对象为Portal
    Config Service和Admin Service都是多实例、无状态部署，且需要将自己注册到Eureka中并保持心跳
    在Eureka之上，架了一层Meta Server用于封装Eureka的服务发现接口
    Client通过域名访问Meta Server获取Config Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Client侧会做load balance、错误重试
    Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重试
    为了简化部署，实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中
为什么使用Eureka？
    它提供了完整的Service Registry和Service Discovery实现
    与Spring Cloud无缝集成，项目本身就使用了Spring Cloud和Spring Boot，同时Spring Cloud还有一套非常完善的开源代码来整合Eureka，所以使用起来非常方便。
    Eureka还支持在应用自身的容器中启动，也就是说应用启动完之后，既充当了Eureka的角色，同时也是服务的提供者，提高了服务的可用性。
    提高配置中心的可用性和降低部署复杂度，尽可能地减少外部依赖。
    最后一点是开源，由于代码是开源的，所以非常便于我们了解它的实现原理和排查问题。

2.Apollo工作机制
    1> 用户在配置中心对配置进行修改并发布
    2> 配置中心通知Apollo客户端有配置更新
    3> Apollo 客户端从配置中心拉取最新的配置、更新本地配置并通知到应用
    Config Service通知客户端的实现方式
有配置发布后是如何通知到客户端的呢？
    实现方式如下：
        客户端会发起一个Http请求到Config Service的notifications/v2接口，也就是NotificationControllerV2，参见RemoteConfigLongPollService
        NotificationControllerV2不会立即返回结果，而是通过Spring DeferredResult把请求挂起
        如果在60秒内没有该客户端关心的配置发布，那么会返回Http状态码304给客户端
        如果有该客户端关心的配置发布，NotificationControllerV2会调用DeferredResult的setResult方法，传入有配置变化的namespace信息，同时该请求会立即返回。客户端从返回的结果中获取到配置变化的namespace后，会立即请求Config Service获取该namespace的最新配置。
Apollo客户端的实现原理：
    客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling实现）
    客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
    这是一个fallback机制，为了防止推送机制失效导致配置不更新
    客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
    定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。
    客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
    客户端会把从服务端获取到的配置在本地文件系统缓存一份
    在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
    应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知
3.和Spring集成的原理
    Spring从3.1版本开始增加了ConfigurableEnvironment和PropertySource：
        ConfigurableEnvironment
        Spring的ApplicationContext会包含一个Environment（实现ConfigurableEnvironment接口）
        ConfigurableEnvironment自身包含了很多个PropertySource
        PropertySource 可以理解为很多个Key - Value的属性配置，PropertySource之间是有优先级顺序的，如果有一个Key在多个property source中都存在，那么在前面的property source优先。在应用启动阶段，Apollo从远端获取配置，然后组装成PropertySource并运行时插入到第一个即可