1. 簡(jiǎn)介

apollo是攜程框架研發(fā)部開(kāi)源的一款分布式配置管理中心，可以集中管理應(yīng)用不同環(huán)境、不同集群的配置，配置修改后能夠?qū)崟r(shí)推送到應(yīng)用端，具備權(quán)限校驗(yàn)等特性。

框架是基于springboot和springcloud開(kāi)發(fā)。

2. 基本功能

1. 統(tǒng)一管理不同環(huán)境、不同集群的配置：支持在同一界面管理不同環(huán)境、集群和命名空間的配置；
2. 界面功能豐富：支持配置發(fā)版、配置回滾、灰度發(fā)布等功能；
3. 配置修改實(shí)時(shí)生效（熱發(fā)布）
4. 權(quán)限管理和審計(jì)：應(yīng)用配置有完善的權(quán)限管理機(jī)制，按配置分為編輯和發(fā)布兩個(gè)環(huán)節(jié)，支持查看配置改動(dòng)歷史。

Apollo實(shí)現(xiàn)高可用依賴于Eureka，至于為什么使用Eureka官方給出的理由為：

1. 項(xiàng)目本身就使用了Spring Cloud和Spring Boot，同時(shí)Spring Cloud還有一套非常完善的開(kāi)源代碼來(lái)整合Eureka，使用起來(lái)非常方便；
2. Eureka還支持在我們應(yīng)用自身的容器中啟動(dòng)，也就是說(shuō)我們的應(yīng)用啟動(dòng)完之后，既充當(dāng)了Eureka的角色，同時(shí)也是服務(wù)的提供者。這樣就極大的提高了服務(wù)的可用性；
3. 為了提高配置中心的可用性和降低部署復(fù)雜度，我們需要盡可能地減少外部依賴。

3. Apollo關(guān)鍵功能實(shí)現(xiàn)原理

3.1 框架整體原理

3.1.1 Apollo角色

Apollo框架分為五種角色：

1. Client：運(yùn)行在開(kāi)發(fā)者業(yè)務(wù)等系統(tǒng)的SDK，負(fù)責(zé)從Meta Server拉取Config Service服務(wù)的地址并拉取監(jiān)聽(tīng)配置數(shù)據(jù)；
2. Portal：配置發(fā)布者操作的配置頁(yè)面，負(fù)責(zé)從Meta Server拉取Admin Service服務(wù)的地址并發(fā)布配置修改請(qǐng)求；
3. Meta Server：Eureka集群的消費(fèi)者，負(fù)責(zé)從Eureka集群拉取Admin和Config Service并緩存在本地，為Client和Portal提供統(tǒng)一封裝后的HTTP接口；
4. Admin Service：Eureka集群的服務(wù)提供者，會(huì)將自身注冊(cè)在Eureka集群中，同時(shí)接收Portal管理端的修改數(shù)據(jù)請(qǐng)求；
5. Config Service：Eureka集群的服務(wù)提供者，會(huì)將自身注冊(cè)在Eureka集群中，同時(shí)接收Client的拉取監(jiān)聽(tīng)數(shù)據(jù)請(qǐng)求；
6. PortalDB：存儲(chǔ)一些環(huán)境變量，及配置環(huán)境等信息的數(shù)據(jù)庫(kù)，注意該庫(kù)不存儲(chǔ)配置信息，不管是單機(jī)還是多機(jī)只需要一個(gè)portalDB；
7. ConfigDB：存儲(chǔ)Apollo的配置信息。

3.1.2 框架執(zhí)行原理

框架整體執(zhí)行原理：

1. 啟動(dòng)Eureka集群，以便Apollo機(jī)器完成注冊(cè)發(fā)現(xiàn)；
2. 啟動(dòng)Admin Service，將自身注冊(cè)到Eureka集群中，并保持心跳；
3. 啟動(dòng)Config Service，將自身注冊(cè)到Eureka集群中，并保持心跳；
4. 啟動(dòng)Meta Server，從Eureka集群中發(fā)現(xiàn)拉去Admin Service和Config Service的機(jī)器信息；
5. Client端的SDK啟動(dòng)，通過(guò)SLB或nginx的負(fù)載均衡請(qǐng)求Meta Server，拉取Config Service的機(jī)器信息；
6. Client向Config Service拉取數(shù)據(jù)并使用長(zhǎng)輪詢監(jiān)聽(tīng)配置改動(dòng)；
7. 配置管理員在Portal上修改文件數(shù)據(jù)，Portal向Admin Service發(fā)起配置修改請(qǐng)求；
8. Admin Service接收到修改請(qǐng)求后，發(fā)送ReleaseMessage給Config Service；
9. Config Service接收到ReleaseMessage后通過(guò)長(zhǎng)輪詢回調(diào)給Client；
10. Client接收到新的配置修改信息，刷新本地緩存。

3.1.3 整體組成

Apollo個(gè)人傾向于將其分為三個(gè)部分：

1. Portal+Admin Service管理端部分：Apollo的配置提供者，主要負(fù)責(zé)修改管理配置，發(fā)生配置修改后發(fā)布配置改動(dòng)事件；
2. Meta Server+Eureka+Config Service核心部分：這部分會(huì)完成集群內(nèi)部的服務(wù)發(fā)現(xiàn)注冊(cè)，并向外提供對(duì)應(yīng)的API接口；
3. Client部分：Apollo的配置消費(fèi)者，向Apollo拉取服務(wù)信息并發(fā)起長(zhǎng)輪詢拉取監(jiān)聽(tīng)數(shù)據(jù)。

從Apollo官方推薦的部署方式可以看出來(lái)他們也傾向于這樣劃分，多機(jī)部署架構(gòu)圖如下：

MetaServer、Eureka和Config Service可以簡(jiǎn)化為Config Service。如果要高可用則在此基礎(chǔ)上多新增幾臺(tái)Admin Service或Config Serivce，如果要多環(huán)境則在此基礎(chǔ)上新增不同的Linux Server1集群。

這樣劃分最核心的原因是：MetaServer、Eureka和Config Service這三個(gè)角色在同一個(gè)JVM進(jìn)程中，也就是一定在同一臺(tái)機(jī)器上。而Admin Service在一個(gè)JVM中，Portal在一個(gè)JVM中。

3.2 細(xì)節(jié)實(shí)現(xiàn)

3.2.1 Eureka和不同角色機(jī)器的關(guān)系

和Eureka有直接關(guān)系的是Meta Server、Config Service和Admin Service，Apollo中其它的組件或角色都和Eureka沒(méi)有關(guān)系。

對(duì)Eureka來(lái)說(shuō)，Config Service和Admin Service是服務(wù)提供者，會(huì)主動(dòng)將自己的信息注冊(cè)到Eureka中，而Meta Server則作為服務(wù)消費(fèi)者從Eureka上拉取所有服務(wù)提供者的信息。

由于Apollo自己在框架內(nèi)集成了Eureka，所以在部署Apollo時(shí)無(wú)需額外再創(chuàng)建一個(gè)Eureka集群，如果想要Apollo接入現(xiàn)存的Eureka集群，可使用如下方法：

1. 使用1.5.0之后的版本；
2. 配置apollo.eureka.server.enabled=false；
3. 把serverconfig表的eureka.service.url字段改成自己的eureka路徑。

3.2.2 Meta Server的作用

Meta server在整個(gè)體系中為Eureka Client，負(fù)責(zé)從Eureka中發(fā)現(xiàn)服務(wù)，Meta Server的作用便是封裝接口數(shù)據(jù)，從Eureka中拉取數(shù)據(jù)后向client和portal開(kāi)放不同的接口，讓client和portal只用關(guān)注自身的一個(gè)http接口，而無(wú)需關(guān)心Eureka的數(shù)據(jù)格式及如何過(guò)濾configService或adminService。

3.2.3 ReleaseMessage消息實(shí)現(xiàn)原理

當(dāng)Admin Service收到了修改數(shù)據(jù)的請(qǐng)求，并完成了數(shù)據(jù)修改落庫(kù)后，需要向其它的Config Service發(fā)布修改事件，這個(gè)使用場(chǎng)景很容易想到消息隊(duì)列。Apollo使用了數(shù)據(jù)庫(kù)表來(lái)模擬消息隊(duì)列，其實(shí)現(xiàn)為：

1. Admin Service往ReleaseMessage表中寫(xiě)入一條改動(dòng)配置記錄；
2. 所有的Config Service每秒定時(shí)輪詢ReleaseMessage表，這就是為什么Apollo說(shuō)是秒級(jí)的熱發(fā)布性能；
3. 當(dāng)發(fā)現(xiàn)配置表有新的記錄寫(xiě)入時(shí)，則說(shuō)明配置發(fā)生了改動(dòng)，此時(shí)會(huì)通過(guò)長(zhǎng)輪詢返回給Client。

3.2.4 Client的通信方式

Client請(qǐng)求Meta Server使用普通的HTTP方式調(diào)用來(lái)拉取Config Service服務(wù)的ip+port。

cLIENT向Config Service發(fā)起http long polling，超時(shí)時(shí)間為60s，沒(méi)獲取到配置則返回304，有數(shù)據(jù)則異步通知客戶端請(qǐng)求，客戶端接收到數(shù)據(jù)返回更新本地緩存。除了http長(zhǎng)輪詢，客戶端默認(rèn)會(huì)每隔5min向configService拉取一次數(shù)據(jù)，一般而言是304?？赏ㄟ^(guò)System Property: apollo.refreshInterval覆蓋。拉取下來(lái)的數(shù)據(jù)會(huì)在本地生成文件，以防止遠(yuǎn)程服務(wù)異常無(wú)法啟動(dòng)。

負(fù)載均衡和錯(cuò)誤重試都是在client端完成的，負(fù)載均衡方式：

1. 優(yōu)先訪問(wèn)通知配置變更的configService，以便更快的正常訪問(wèn)；
2. 若訪問(wèn)加載速度過(guò)快被限流，則sleep 5s；
3. 訪問(wèn)失敗會(huì)計(jì)算重試時(shí)間間隔，單位s。