apollo 配置中心_配置中心——Apollo小记
一、什么是配置
配置是程序運行時，動態調整行為的能力。
配置有以下屬性：
- 配置是獨立于程序的只讀變量
- 同一份程序在不同的配置下才會有不同的行為，而且配置對于程序來說是只讀的，所以程序可以通過讀取配置來改變自己的行為，但是不能自己改動配置文件。
- 配置伴隨應用的整個生命周期
- 應用在啟動的時候通過讀取配置來初始化，在運行時根據配置改變自己的行為。
- 配置有多中加載方式
- 程序內部hard code，這種做法是反模式，十分不建議。
- 配置文件。
- 環境變量，配置可以預置在操作系統的環境變量里，程序運行時讀取。
- 啟動參數，可以在程序啟動時一次性提供參數。
- 基于數據庫，將易變配置放在數據庫中，這樣可以在運行期靈活調整配置。
- 配置需要治理
- 權限控制：對配置的修改需要有比較完善的權限控制，否則不正確的配置會引起災難。
- 不同環境、集群配置管理：同一份程序在不同環境（開發、測試、生產）、不同的集群（如不同的數據中心）經常需要有不同的配置，所以需要完善的環境、集群配置管理。
- 框架類組件配置管理：如CAT客戶端的配置。
二、為什么需要配置中心
在沒有引入配置中心之前，一般研發的時候會有以下痛點：
- 配置格式散亂不規范
- 有的用properties格式，有的用yml格式，有的用xml格式，還有存DB的，做法五花八門。
- 主要采用本地靜態配置，配置修改麻煩
- 在分布式微服務環境下，當服務實例很多的時候，配置修改費時費力。
- 易引發生產事故
- 如將測試環境的配置帶到生產環境上。
- 配置缺乏安全審計和版本控制功能
- 無法查看到修改配置的人，修改了什么內容，以及修改的時間，除了問題也無法及時回滾。
三、配置中心的核心需求
傳統做法應用在打包部署的時候，會為不同環境打出不同配置的包，每個包里頭包含環境特定配置。而現在推薦采用如容器鏡像方式打包和交付微服務，應用鏡像一般只打一份，可以部署到不同環境，所以這要求交付件和配置進行分離，交付件只制作一份，并且是不可變的，可以部署到任意環境。但是所有環境的配置都可以在配置中心集中配置，運行期應用可以根據自身環境到配置中心動態拉取相應的配置。
配置中心應該封裝屏蔽配置管理的細節和配置的不同格式，方便用戶進行自主式配置管理，一般用戶只需要關注兩個抽象和標準化的接口即可：
- 配置管理界面UI，方便應用開發人員管理和發布配置。
- 封裝好的客戶端API，方便應用集成和獲取配置。
微服務應用大多采用多環境部署，一般標準的環境有開發/測試/生產等，有的應用還需要多集群部署，如支持跨機房或多版本部署。配置中心需要支持對多環境和多集群應用配置的集中式管理。高可用
配置中心不能掛，否則會大面積影響微服務。實時性
配置更新需要盡快通知到客戶端，有些配置的實時性要求很高，像是主備切換配置或者藍綠部署配置，這些需要秒級切換配置的能力。治理
配置需要治理，具體包括：
- 配置審計，需要記錄修改人，修改內容和修改事件，方便出現問題時能后追溯。
- 配置版本控制，每次變更需要版本化，出現問題可以及時回滾到上一版本。
- 配置權限控制，配置變更發布需要認證授權。
- 灰度發布，配置發布時可以先讓少數實例生效，確定沒有問題就可以擴大應用范圍。
四、什么是Apollo
Apollo是攜程框架部門研發的開源配置管理中心，能夠集中化管理應用不同環境、不同集群的配置，配置修改后能夠實時推送到應用端，并且具備規范的權限、流程治理等特性。
Apollo的特性如下：
- 統一管理不同環境、不同集群的配置。
- Apollo提供了一個統一界面集中式管理不同環境、不同集群、不同命名(namespace)空間的配置，而且同一份代碼部署在不同集群，可以有不同的配置。
- 配置修改實時生效（熱發布）
- 版本發布管理
- 灰度發布
- 客戶端配置信息監控
- 可以在界面上方便地看到配置在被哪些實例使用。
- 提供Java和.Net原生客戶端
- 提供開放平臺API
- 部署簡單
可以看到，Apollo的特性幾乎符合上文配置中心的核心需求。
五、Apollo的基本模型
六、Apollo客戶端設計
1、Apollo客戶端實現原理
2、配置更新推送實現
上文提到Apollo客戶端和服務端保持了一個長連接，從而可以第一時間獲得配置更新的推送，實際上長連接是通過Http Long Polling實現的：
- 客戶端發起Http請求給服務端
- 服務端保持60s連接
- 如果在60s中有客戶端關心的配置變化，則請求會立即返回，并告知客戶端有配置變化的namespace信息，客戶端會據此拉取該namespace的最新配置。
- 如果60s內沒有客戶端關心的配置變化，則返回http狀態碼304給客戶端。
在服務端，是用async servlet(Spring DeferredResult)來服務Http Long Polling請求。
七、Apollo總體設計
在捋清思路之前，先對其中的模塊進行了解：
主要模塊：
- ConfigService
- 提供配置獲取接口
- 提供配置推送接口
- 服務于Apollo客戶端
- AdminService
- 提供配置管理接口
- 提供配置修改發布接口
- 服務于管理界面Portal
- Client
- 為應用獲取配置，支持實時更新
- 通過MetaServer獲取ConfigService的服務列表
- 使用客戶端軟負載SLB方式調用ConfigService
- Portal
- 配置管理頁面
- 通過MetaServer獲取AdminService的服務列表
- 使用客戶端軟負載SLB方式調用AdminService
輔助模塊：
- Eureka
- 用于服務發現和注冊
- Config/AdminService注冊實例并定期報心跳
- 和ConfigService一起部署
- MetaServer
- Portal通過域名訪問MetaServer獲取AdminService的地址列表
- Client通過域名訪問MetaServer獲取ConfigService的地址列表
- 相當于Eureka Proxy
- 和ConfigService一起部署
- NginxLB
- 和域名系統配合，協助Portal訪問MetaServer獲取AdminService的地址列表
- 和域名系統配合，協助Client訪問MetaServer獲取ConfigService的地址列表
- 和域名系統配置，協助用戶訪問Portal進行配置管理。
1、簡化架構A
假設沒有分布式微服務的服務發現，那么：
2、簡化架構B
因為Client要找ConfigService需要地址列表，Portal找到AdminService也需要地址列表，這時候就需要服務發現了。
3、簡化結構C
因為攜程需要跟自家的.Net的系統兼容，所以引入了MetaServer服務，這相當于是代理Proxy，將Eureka的服務發現接口以更簡單明確的HTTP接口的形式暴露出來。
但是MetaServer本身也是無狀態以集群方式部署的，那么Client/Protal該如何發現MetaServer呢？傳統的方式是借助硬件（可以在其中指定MetaServer的位置）或者是軟件負載均衡器。
4、簡化結構4
使用NginxLB（也稱Software Load Balancer），由運維為MetaServer集群配置一個域名，指向NginxLB集群，NginxLB再對MetaServer進行負載均衡和流量轉發。Client/Portal通過域名+NginxLB間接訪問MetaServer集群。
-----------------------------------------------------------------------------------------------
這里踩個坑，因為一套Portal就可以集中管理多套環境（DEV/FAT/UAT/PRO）中的配置，所以當切換環境的時候，需要注意到.properties(.yml)等配置文件中（SpringBoot）是否有明確標記處需要取出哪些namespace的配置，否則Client將會拉取不了配置中心的配置到本地。
參考：
微服務架構 為什么需要配置中心攜程 Apollo 配置中心架構深度剖析Apollo配置中心介紹
總結
以上是生活随笔為你收集整理的apollo 配置中心_配置中心——Apollo小记的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： android怎样判断插入数据是否成功_
- 下一篇： 局域网共享工具_局域网文件共享