1、 Apollo+ES源碼改造構(gòu)建民生銀行天眼ELK日志平臺(tái)配置管理中心 隨著中國(guó)民生銀行的IT業(yè)務(wù)系統(tǒng)的迅速發(fā)展，主機(jī)、設(shè)備、系統(tǒng)、應(yīng)用軟件數(shù)量不斷增多，業(yè)務(wù)資源訪問(wèn)、操作量不斷增加，對(duì)于應(yīng)用整體系統(tǒng)智能分析與處理的要求不斷提高，在解決分布式大數(shù)據(jù)搜索、日志挖掘和可視化的過(guò)程中，需要考慮實(shí)現(xiàn)一套完整并適用于民生銀行的日志文件智能分析與處理的解決方案?；诖颂煅蹖?shí)時(shí)智能日志管理分析平臺(tái)應(yīng)運(yùn)而生，通過(guò)日志的收集、傳輸、儲(chǔ)存，對(duì)海量系統(tǒng)日志進(jìn)行集中管理和實(shí)時(shí)搜索分析，幫助運(yùn)維人員進(jìn)行業(yè)務(wù)實(shí)時(shí)監(jiān)控、故障定位及排除、業(yè)務(wù)趨勢(shì)分析、安全與合規(guī)審計(jì)等工作，深度挖掘日志的大數(shù)據(jù)價(jià)值，提升了應(yīng)用整體系統(tǒng)智能分析

2、與處理效率，達(dá)到了匯總、檢索、展示應(yīng)用日志和串聯(lián)事件、快速定位問(wèn)題等全方位功能要求。目前日志平臺(tái)納管的服務(wù)器超過(guò)1000臺(tái)，覆蓋了民生銀行所有操作系統(tǒng)類型：SuSE Linux（11/12）、AIX（7）、HP_UX（11）和RedHat（5.5），除了應(yīng)用日志以外，系統(tǒng)軟件日志類型覆蓋DB2、Oracle、Mysql、Redis、Weblogic、Activemq、Kafka、Tomcat等等，同時(shí)采集存儲(chǔ)、操作系統(tǒng)、管理口相關(guān)指標(biāo)日志。每天接入日志量在10T到20T之間，平均日接入量在15T左右。在如此量級(jí)的日志接入下，對(duì)平臺(tái)本身吞吐量、端到端全鏈路的寫(xiě)入延遲、查詢響應(yīng)時(shí)間等都提出了比較高

3、的要求，因此對(duì)于ES集群本身的參數(shù)調(diào)優(yōu)成為了一項(xiàng)持續(xù)進(jìn)行的長(zhǎng)期性工作，這時(shí)ES物理節(jié)點(diǎn)過(guò)多導(dǎo)致的配置文件分散、角色參數(shù)差異、版本管理混亂、配置監(jiān)控缺失等問(wèn)題就集中暴露了出來(lái)。而使用腳本或者文件分發(fā)管理又不夠直觀和友好，出現(xiàn)問(wèn)題排查困難，易用性較差，也不具備分布式和高可用功能。為了能夠界面化、集中化管理ES集群不同角色、不同類型的配置并且在配置修改后能夠在ES中實(shí)時(shí)生效，所有配置信息的修改具備規(guī)范的權(quán)限、流程治理等特性，民生銀行天眼ELK日志平臺(tái)最終采用攜程開(kāi)源的Apollo（阿波羅）作為技術(shù)選型，本篇以民生銀行天眼日志平臺(tái)實(shí)際需求為中心，逐步展開(kāi)介紹我們是如何通過(guò)Apollo+ES源碼改造構(gòu)建

4、民生銀行天眼ELK日志平臺(tái)配置管理中心。一、Apollo功能介紹Apollo目前在github的Star數(shù)量超過(guò)10000，社區(qū)活躍度和版本更新效率都比較高，首先簡(jiǎn)單介紹一下Apollo本身的功能點(diǎn)和其在天眼ELK日志平臺(tái)配置管理中心中的實(shí)際運(yùn)用。Apollo是攜程的開(kāi)源配置管理中心，可以從應(yīng)用、環(huán)境、集群、命名空間4個(gè)維度集中的管理配置，并能夠夠?qū)嵤┑耐扑椭量蛻舳耍瑑?yōu)點(diǎn)如下：1、統(tǒng)一管理不同環(huán)境、不同集群的配置Apollo提供了一個(gè)統(tǒng)一界面集中式管理不同環(huán)境（environment）、不同集群（cluster）、不同命名空間（namespace）的配置。同一份代碼部署在不同的集群，可以有不同

5、的配置，通過(guò)命名空間（namespace）可以很方便地支持多個(gè)不同應(yīng)用共享同一份配置，同時(shí)還允許應(yīng)用對(duì)共享的配置進(jìn)行覆蓋。由于民生銀行開(kāi)發(fā)、測(cè)試、生產(chǎn)環(huán)境均是網(wǎng)絡(luò)隔離的，所以在進(jìn)行Apollo部署時(shí)我們?nèi)サ袅?個(gè)環(huán)境標(biāo)識(shí)DEV、FAT、UAT、PRO中的后面3個(gè)，只保留了DEV環(huán)境，測(cè)試和生產(chǎn)均完整的部署一套Apollo環(huán)境。另外運(yùn)用集群（cluster）實(shí)現(xiàn)了ES角色配置文件分離，運(yùn)用namespace實(shí)現(xiàn)了ES不同種類配置文件分析，這些在后面Apollo+ES設(shè)計(jì)中會(huì)詳細(xì)講到。2、配置修改實(shí)時(shí)生效（熱發(fā)布）用戶在Apollo修改完配置并發(fā)布后，客戶端能實(shí)時(shí)（1秒）接收到最新的配置，并通知到

6、應(yīng)用程序。這個(gè)功能比較誘人，我們?cè)谄渌?xiàng)目中也使用到了熱發(fā)布，但是在ES中沒(méi)有配置，一方面是由于ES讀取的很多配置的模式都是讀且僅讀一次，熱配置無(wú)法生效。另一方面ES代碼較復(fù)雜，其在讀取配置文件前后都需要初始化很多參數(shù)，很多配置參數(shù)是擴(kuò)散到整個(gè)項(xiàng)目代碼中的，核心代碼、插件代碼可能都會(huì)有涉及，一些如監(jiān)聽(tīng)端口配置修改需要重起相關(guān)線程模塊，實(shí)現(xiàn)熱配置風(fēng)險(xiǎn)太高，最后熱配置在ES源碼改造過(guò)程中我們只是用于配置參數(shù)變化的日志輸出打印，完成配置生效還是需要重起節(jié)點(diǎn)進(jìn)程。3、版本發(fā)布管理所有的配置發(fā)布都有版本概念，從而可以方便地支持配置的回滾。這個(gè)是配置中心基本功能，在日志平臺(tái)進(jìn)行ES參數(shù)優(yōu)化我們依賴Apol

7、lo進(jìn)行版本管理，使用起來(lái)比較方便。4、灰度發(fā)布支持配置的灰度發(fā)布，比如點(diǎn)了發(fā)布后，只對(duì)部分應(yīng)用實(shí)例生效，等觀察一段時(shí)間沒(méi)問(wèn)題后再推給所有應(yīng)用實(shí)例在日志平臺(tái)實(shí)際應(yīng)用中我們經(jīng)常使用灰度發(fā)布的功能去驗(yàn)證某些通用參數(shù)是否可以配置在角色節(jié)點(diǎn)或者數(shù)據(jù)節(jié)點(diǎn)可以單獨(dú)生效，在default集群參數(shù)中讓某些參數(shù)的發(fā)布推送到特定的master節(jié)點(diǎn)或者data節(jié)點(diǎn)，不過(guò)最后根據(jù)默認(rèn)參數(shù)全部配置一致原則會(huì)將default中修改過(guò)的參數(shù)配置推送到全部的ES節(jié)點(diǎn)當(dāng)中。5、權(quán)限管理、發(fā)布審核、操作審計(jì)應(yīng)用和配置的管理都有完善的權(quán)限管理機(jī)制，對(duì)配置的管理還分為了編輯和發(fā)布兩個(gè)環(huán)節(jié)，從而減少人為的錯(cuò)誤。所有的操作都有審計(jì)日志，

8、可以方便地追蹤問(wèn)題。在權(quán)限控制上生產(chǎn)環(huán)境要求必須日志平臺(tái)A崗負(fù)責(zé)人有最終的發(fā)布權(quán)限，ES參數(shù)修改對(duì)集群整個(gè)的穩(wěn)定性影響比較大，必須將風(fēng)險(xiǎn)降到最低。另外目前日志平臺(tái)配置管理中心也承擔(dān)著一些項(xiàng)目組自己開(kāi)發(fā)的工具的配置管理工作，所以單獨(dú)也進(jìn)行了權(quán)限的劃分和處理。6、客戶端配置信息監(jiān)控可以在界面上方便地看到配置在被哪些實(shí)例使用。這個(gè)功能在日志平臺(tái)中某種程度上也起到了實(shí)例心跳檢測(cè)的功能，同時(shí)根據(jù)角色的劃分可以清楚地看到這個(gè)ES的邏輯節(jié)點(diǎn)配置位置，比如default參數(shù)肯定是所有節(jié)點(diǎn)都會(huì)讀取，而單獨(dú)的master、hot、warm、client節(jié)點(diǎn)只有相關(guān)的角色節(jié)點(diǎn)才會(huì)讀取其配置。值得一提的是由于有緩存的

9、功能，可以看到ES相關(guān)節(jié)點(diǎn)讀取配置的時(shí)間實(shí)際上是參數(shù)改變后節(jié)點(diǎn)第一次讀取配置的時(shí)間，如果ES節(jié)點(diǎn)單獨(dú)重起但是相關(guān)參數(shù)沒(méi)有發(fā)生變化和發(fā)布，那么界面上看到的配置參數(shù)讀取時(shí)間是不會(huì)發(fā)生改變的。7、提供Java和.Net原生客戶端提供了Java和.Net的原生客戶端，方便應(yīng)用集成，同時(shí)提供了Http接口，非Java和.Net應(yīng)用也可以方便地使用。ES本身就是通過(guò)Java語(yǔ)言編寫(xiě)的，所以通過(guò)修改ES源碼可以比較方便地將Apollo客戶端集成到ES中去。后續(xù)我們打算將Logstash處理的配置文件也通過(guò)Apollo納管，由于Logstash是用ruby語(yǔ)言，所以可能就會(huì)用到其提供的Http接口。8、提供開(kāi)

10、放平臺(tái)APIApollo自身提供了比較完善的統(tǒng)一配置管理界面，支持多環(huán)境、多數(shù)據(jù)中心配置管理、權(quán)限、流程治理等特性。不過(guò)Apollo出于通用性考慮，不會(huì)對(duì)配置的修改做過(guò)多限制，只要符合基本的格式就能保存，不會(huì)針對(duì)不同的配置值進(jìn)行針對(duì)性的校驗(yàn)，如數(shù)據(jù)庫(kù)用戶名、密碼，Redis服務(wù)地址等。對(duì)于這類應(yīng)用配置，Apollo支持應(yīng)用方通過(guò)開(kāi)放平臺(tái)API在Apollo進(jìn)行配置的修改和發(fā)布，并且具備完善的授權(quán)和權(quán)限控制。目前天眼ELK日志平臺(tái)主要是還是使用Apollo本身提供的配置管理界面進(jìn)行管理，不過(guò)后續(xù)可以考慮通過(guò)其API將部分功能在大數(shù)據(jù)集中的管控平臺(tái)上去實(shí)現(xiàn)。9、部署簡(jiǎn)單配置中心作為基礎(chǔ)服務(wù)，可用性

11、要求非常高，這就要求Apollo對(duì)外部依賴盡可能地少，目前唯一的外部依賴是MySQL，所以部署非常簡(jiǎn)單，只要安裝好Java和MySQL就可以讓Apollo跑起來(lái)。Apollo還提供了打包腳本，一鍵就可以生成所有需要的安裝包，并且支持自定義運(yùn)行時(shí)參數(shù)。日志平臺(tái)基本按照官方文檔進(jìn)行標(biāo)準(zhǔn)部署，稍微有一點(diǎn)改動(dòng)的地方是Apollo本身的日志路徑存放地址是以進(jìn)程號(hào)為目錄層級(jí)的，不太直觀，通過(guò)修改源碼將其增加adminservice、configservice和portal目錄，使得不同模塊的日志路徑比較清晰易區(qū)分。二、Apollo架構(gòu)解析在日志平臺(tái)生產(chǎn)實(shí)際使用Apollo之前，必須對(duì)其架構(gòu)進(jìn)行深入了解和剖

12、析，在架構(gòu)設(shè)計(jì)的過(guò)程中有一個(gè)基本點(diǎn)必須明確，那就是Apollo的某個(gè)服務(wù)異常不應(yīng)該影響整個(gè)配置管理中心的服務(wù)，Apollo所有模塊的異常不應(yīng)該影響ES集群的正常運(yùn)行。Apollo的基礎(chǔ)模型如下：6hxjfozbajw如上圖所示，用戶在配置中心配置/修改并發(fā)布配置，然后Apollo通知客戶端有配置更新，最后客戶端向Apollo配置中心請(qǐng)求最新配置。總體設(shè)計(jì)如下圖所示：7lx04jeu7vf其中Apollo各模塊的功能簡(jiǎn)單介紹如下：（1）config Service：提供配置獲取接口，提供配置更新推送接口，接口服務(wù)對(duì)象為Apollo客戶端；（2）Admin Service：提供配置管理接口，提供配

13、置修改、發(fā)布等接口，接口服務(wù)對(duì)象為Portal；（3）Meta Server：Portal通過(guò)訪問(wèn)Meta Server獲取Admin Service服務(wù)列表（IP+Port），Client通過(guò)訪問(wèn)Meta Server獲取Config Service服務(wù)列表（IP+Port），Meta Server從Eureka獲取Config Service和Admin Service的服務(wù)信息，相當(dāng)于是一個(gè)Eureka Client，增設(shè)一個(gè)Meta Server的角色主要是為了封裝服務(wù)發(fā)現(xiàn)的細(xì)節(jié)，對(duì)Portal和Client而言，永遠(yuǎn)通過(guò)一個(gè)Http接口獲取Admin Service和Config S

14、ervice的服務(wù)信息，而不需要關(guān)心背后實(shí)際的服務(wù)注冊(cè)和發(fā)現(xiàn)組件，Meta Server只是一個(gè)邏輯角色，在部署時(shí)和Config Service是在一個(gè)JVM進(jìn)程中的；（4）Eureka：基于Eureka和Spring Cloud Netflix提供服務(wù)注冊(cè)和發(fā)現(xiàn)，Config Service和Admin Service會(huì)向Eureka注冊(cè)服務(wù)，并保持心跳，為了簡(jiǎn)單起見(jiàn)，目前Eureka在部署時(shí)和Config Service是在一個(gè)JVM進(jìn)程中的；（5）Portal：提供Web界面供用戶管理配置，通過(guò)Meta Server獲取Admin Service服務(wù)列表（IP+Port），通過(guò)IP+Po

15、rt訪問(wèn)服務(wù)，在Portal側(cè)做load balance、錯(cuò)誤重試；（6）Client：Apollo提供的客戶端程序，為應(yīng)用提供配置獲取、實(shí)時(shí)更新等功能，通過(guò)Meta Server獲取Config Service服務(wù)列表（IP+Port），通過(guò)IP+Port訪問(wèn)服務(wù)，在Client側(cè)做load balance、錯(cuò)誤重試。關(guān)于Apollo各個(gè)組件的相關(guān)作用和實(shí)現(xiàn)原理不是本文的重點(diǎn)，我就不在這里過(guò)多贅述了，感興趣的同學(xué)可以去Apollo的github進(jìn)行詳細(xì)了解。在實(shí)際部署中我們是將Apollo部署在三臺(tái)服務(wù)器上做高可用和負(fù)載均衡，每臺(tái)服務(wù)器上都會(huì)啟動(dòng)獨(dú)立的config Service、Admin

16、 Service和Portal三個(gè)模塊進(jìn)程，后端連接統(tǒng)一的mysql數(shù)據(jù)庫(kù)，通過(guò)修改數(shù)據(jù)庫(kù)中serverconfig字段使得Eureka注冊(cè)服務(wù)構(gòu)成三節(jié)點(diǎn)的集群，client端和portal統(tǒng)一配置3臺(tái)服務(wù)ip地址進(jìn)行連接。下面就開(kāi)始介紹我們構(gòu)建天眼ELK日志管理平臺(tái)的兩塊核心工作：Apollo ES架構(gòu)設(shè)計(jì)和ES源碼改造。三、Apollo ES架構(gòu)設(shè)計(jì)在Apollo ES架構(gòu)設(shè)計(jì)這塊其實(shí)包含了兩部分工作，一部分工作是通過(guò)Apollo的集群分離功能將通過(guò)ES中的角色將配置進(jìn)行拆分，方面統(tǒng)一管理；另一部分工作是根據(jù)實(shí)際需求將elasticsearch需要頻繁修改的配置文件進(jìn)行分類并分別實(shí)現(xiàn)客戶端

17、開(kāi)發(fā)。這兩部分工作都包含了一個(gè)共有的工作內(nèi)容頁(yè)面配置設(shè)計(jì)實(shí)現(xiàn)以增加功能使用體驗(yàn)。1、 ES角色配置拆分日志平臺(tái)目前在生產(chǎn)環(huán)境使用的ELK版本是5.5的，在進(jìn)行ES集群設(shè)計(jì)部署時(shí)data節(jié)點(diǎn)采用了冷熱數(shù)據(jù)分離技術(shù)，引入了SSD來(lái)提升ES的讀寫(xiě)性能。單臺(tái)ES存儲(chǔ)有2塊SD盤(pán)和若干SATA盤(pán)，所以每臺(tái)ES server都啟動(dòng)了3個(gè)ES節(jié)點(diǎn)，2個(gè)hot節(jié)點(diǎn)和1個(gè)warm節(jié)點(diǎn)。Indexer中指配置了hot節(jié)點(diǎn)的端口，通過(guò)ES中的模板定義保證實(shí)時(shí)數(shù)據(jù)只寫(xiě)入hot節(jié)點(diǎn)。通過(guò)ES官方推薦的curator工具定時(shí)將數(shù)據(jù)從hot節(jié)點(diǎn)搬遷到warm節(jié)點(diǎn)，SSD數(shù)據(jù)保留周期為一周。同時(shí)本身ES集群我們啟動(dòng)了3個(gè)ma

18、ster節(jié)點(diǎn)和3個(gè)client節(jié)點(diǎn)，那么實(shí)際上ES集群中一共是4種：master，client，hot和warm，節(jié)點(diǎn)類型都是通過(guò)配置文件elasticsearch.yml的參數(shù)進(jìn)行區(qū)分的。我們知道ES主要的配置參數(shù)都是在elasticsearch.yml中進(jìn)行定義的，最開(kāi)始設(shè)計(jì)時(shí)我們計(jì)劃是通過(guò)主機(jī)名的方式進(jìn)行配置文件區(qū)分，Apollo本身也提供了通過(guò)hostname定義不同的namespace的內(nèi)置方法，但是最后達(dá)到的效果非常不理想。日志平臺(tái)生產(chǎn)集群物理節(jié)點(diǎn)目前是28個(gè)，總節(jié)點(diǎn)數(shù)為90個(gè)，當(dāng)需要修改參數(shù)時(shí)需要每個(gè)節(jié)點(diǎn)的namespace配置都在界面上進(jìn)行修改并發(fā)布，重復(fù)工作太大；另外name

19、space過(guò)多也導(dǎo)致管理頁(yè)面特別冗長(zhǎng)，下拉很久也拖不到頁(yè)面底部，用戶體驗(yàn)很差，當(dāng)時(shí)就想這樣還不如直接腳本分發(fā)修改配置文件來(lái)的快些，失去了日志平臺(tái)配置管理中心建設(shè)的初衷。于是就想能不能通過(guò)角色進(jìn)行配置拆分，相同的角色的配置是否可以放到一個(gè)namespace中去處理。Apollo本身在DEV的生產(chǎn)模式下提供創(chuàng)建多集群的配置方式，由于在日志平臺(tái)中不存在多集群的情況，于是我們就將集群模式的功能來(lái)區(qū)分ES中的節(jié)點(diǎn)角色。最終在角色中實(shí)際上創(chuàng)建了5種角色參數(shù)分類：default、hot、warm、master和client。hftnqc138j9在ES的官方文檔中，沒(méi)有詳細(xì)且特意的介紹elasticsear

20、ch.yml中哪些參數(shù)需要配置在master節(jié)點(diǎn)，哪些需要配置在data節(jié)點(diǎn)。我大概翻了一下，其中Local Gateway參數(shù)明確提到需要配置在master節(jié)點(diǎn)，F(xiàn)ielddata和Node Query Cache、Indexing Buffer類參數(shù)是需要每個(gè)datanode節(jié)點(diǎn)都部署的。實(shí)際上我個(gè)人認(rèn)為ES也是努力使越來(lái)越多的參數(shù)可以動(dòng)態(tài)修改，所以從5.x以后將很多參數(shù)都提供了API可以在模板中進(jìn)行配置，配置文件中的參數(shù)越來(lái)越少。也簡(jiǎn)單翻了一下源碼，基本上沒(méi)有特意區(qū)分節(jié)點(diǎn)角色參數(shù)的邏輯處理。這就說(shuō)明了基本上ES的elasticsearch,yml參數(shù)配置最好是所有節(jié)點(diǎn)全部配置，不管是什么

21、角色，除非是真正區(qū)分角色的配置。這就正好適配了配置中心的意義，通過(guò)一次修改而使得全部節(jié)點(diǎn)配置統(tǒng)一生效。最初就是按照ES集角色群設(shè)計(jì)了4個(gè)集群，但是我發(fā)現(xiàn)其實(shí)每種角色節(jié)點(diǎn)有很多參數(shù)配置也是重復(fù)的，參數(shù)變更修改要操作4次，所以最后抽象出來(lái)了一個(gè)default集群，default中配置的都是通用的參數(shù)，只有具有角色特征的參數(shù)才會(huì)存放在各自不同namespace中。那么問(wèn)題來(lái)了，集群做參數(shù)優(yōu)化的時(shí)候修改那個(gè)角色集群的參數(shù)呢？沒(méi)錯(cuò)，只需要修改default中的即可，所有和優(yōu)化相關(guān)配置參數(shù)都是在default集群中的。wsd6275bjp在hot、warm、master、client中的配置實(shí)際上均是一些

22、特有配置，如角色定義、日志路徑、端口號(hào)等等，那么這里就有一個(gè)問(wèn)題，如果在hot集群中和default集群中配置有沖突怎么辦。實(shí)際上在這塊設(shè)計(jì)中我們?cè)O(shè)置了優(yōu)先級(jí)，也就是說(shuō)hot集群中的配置優(yōu)先級(jí)是大于default集群中的優(yōu)先級(jí)的，當(dāng)發(fā)生沖突時(shí)默認(rèn)選擇以角色集群中配置的參數(shù)為準(zhǔn)。另外對(duì)于一些具有節(jié)點(diǎn)特征的參數(shù)，如節(jié)點(diǎn)名稱、節(jié)點(diǎn)綁定ip、網(wǎng)卡等等，那么這類參數(shù)就保留在配置文件當(dāng)中，不在Apollo中進(jìn)行配置。所以最后配置的讀取優(yōu)先級(jí)是：角色配置default配置配置文件，這種設(shè)計(jì)一方面保證了有用的配置集中管理，層次劃分清晰，另一方面可以使得配置遷移的安全性和健壯性，避免配置中心漏掉某些配置導(dǎo)致ES

23、集群出現(xiàn)問(wèn)題。luub0kf0bkq2、參數(shù)文件拆分除了elasticsearch.yml配置文件以外，ES每個(gè)節(jié)點(diǎn)的jvm.options文件我們也經(jīng)常需要修改，最基本的就是通過(guò)-Xms和-Xmx來(lái)調(diào)整ES節(jié)點(diǎn)分配的堆內(nèi)存大小。根據(jù)冷熱分離需求和節(jié)點(diǎn)角色的特性，hot、warm、master、client分配的內(nèi)存都是不一樣的，所以很自然的-Xms和-Xmx就單獨(dú)放到了每個(gè)角色的專有屬性當(dāng)中，其他的配置參數(shù)都放到default集群中。0vyxfz4qdhln在Apollo頁(yè)面配置設(shè)計(jì)上角色集群中我們沒(méi)有在application中去加入配置參數(shù)，而是通過(guò)配置集群中的namespace名稱作了一

24、次鏈接操作。在每個(gè)角色的application中統(tǒng)一都配置4個(gè)key值來(lái)分別指向不同的namespace，public的key值都是default集群中的namespace名稱，private都指向該角色集群下的namespace名稱。default中為了保持統(tǒng)一和方便管理，在application中也配置了本地的namespace名稱，也就是兩個(gè)public的配置項(xiàng)，實(shí)際上這兩個(gè)配置項(xiàng)是用不到的。這樣設(shè)計(jì)的好處是當(dāng)namespace名稱需要改變時(shí)不需要更改ES中Apollo的代碼而達(dá)到解耦的目的。t03x1yd1nef3ii1qcjdqg9在實(shí)際運(yùn)行的過(guò)程中，可以實(shí)時(shí)監(jiān)測(cè)那些運(yùn)行的ES節(jié)點(diǎn)讀

25、取到了當(dāng)前配置，通過(guò)上圖可以看到在default集群中實(shí)際上所有的節(jié)點(diǎn)都會(huì)進(jìn)行讀取其中的參數(shù)，但是和application中的配置無(wú)關(guān)，這個(gè)是用來(lái)保持統(tǒng)一方便管理的。而角色集群中的配置只有ES中的角色節(jié)點(diǎn)才會(huì)進(jìn)行讀取。這里需要注意的是Apollo管理頁(yè)面顯示的配置讀取時(shí)間并不一定是ES節(jié)點(diǎn)最后一次重啟的時(shí)間，因?yàn)锳pollo客戶端本身是由緩存機(jī)制的，其在本地會(huì)創(chuàng)建一個(gè)cache目錄保留從Apollo中讀取的配置，如果配置沒(méi)有修改并發(fā)布過(guò)的話，那么就算ES節(jié)點(diǎn)重啟它還是會(huì)顯示的是你最后一次發(fā)布配置的時(shí)間。最后值得一提的是Apollo本身提供了properties、xml、json、yml和yam

26、l五種配置文件錄入方式，需要在創(chuàng)建對(duì)應(yīng)namespace時(shí)指定，雖然elasticsearch.yml本身是yml格式配置文件，但yml方式并沒(méi)有帶來(lái)客戶端程序開(kāi)發(fā)的優(yōu)勢(shì)，同時(shí)也不如properties在頁(yè)面上看起來(lái)美觀，最后我們還是進(jìn)行了一下轉(zhuǎn)換，統(tǒng)一使用properties格式進(jìn)行錄入，如下圖所示Apollo支持文本方式進(jìn)行批量導(dǎo)入。另外所有的namepace我們都設(shè)置為私有的，因?yàn)槟壳皶簳r(shí)沒(méi)有和其他項(xiàng)目共享參數(shù)的需求。7r7hk7hw86g四、ES源碼改造Apollo ES架構(gòu)設(shè)計(jì)結(jié)束之后就可以進(jìn)行ES源碼改造這塊的工作了，實(shí)際上在我們?cè)贓S源碼改造這塊的所花費(fèi)的時(shí)間遠(yuǎn)遠(yuǎn)沒(méi)有設(shè)計(jì)的時(shí)候多

27、，一旦設(shè)計(jì)定型源碼改造就比較容易。結(jié)合Apollo客戶端進(jìn)行ES源碼改造主要分為兩部分工作：elasticsearch配置源碼改造和jvm配置功能開(kāi)發(fā)。1、 elasticsearch配置源碼改造u7kx2hf6rue上圖簡(jiǎn)要描述了Apollo客戶端的實(shí)現(xiàn)原理：（1）客戶端和服務(wù)端保持了一個(gè)長(zhǎng)連接，從而能第一時(shí)間獲得配置更新的推送。（通過(guò)Http Long Polling實(shí)現(xiàn)）；（2）客戶端還會(huì)定時(shí)從Apollo配置中心服務(wù)端拉取應(yīng)用的最新配置；這是一個(gè)fallback機(jī)制，為了防止推送機(jī)制失效導(dǎo)致配置不更新客戶端定時(shí)拉取會(huì)上報(bào)本地版本，所以一般情況下，對(duì)于定時(shí)拉取的操作，服務(wù)端都會(huì)返回304

28、 - Not Modified定時(shí)頻率默認(rèn)為每5分鐘拉取一次，客戶端也可以通過(guò)在運(yùn)行時(shí)指定System Property: Apollo.refreshInterval來(lái)覆蓋，單位為分鐘（3）客戶端從Apollo配置中心服務(wù)端獲取到應(yīng)用的最新配置后，會(huì)保存在內(nèi)存中；（4）客戶端會(huì)把從服務(wù)端獲取到的配置在本地文件系統(tǒng)緩存一份；在遇到服務(wù)不可用，或網(wǎng)絡(luò)不通的時(shí)候，依然能從本地恢復(fù)配置（5）應(yīng)用程序可以從Apollo客戶端獲取最新的配置、訂閱配置更新通知。ES的主要核心包在core包里，通過(guò)Bootstrap類去啟動(dòng)實(shí)例化的node節(jié)點(diǎn)，在node的構(gòu)造參數(shù)中，可以找到配置文件的加載，我們就是通過(guò)修

29、改InternalSettingsPreparer這個(gè)類來(lái)實(shí)現(xiàn)ES通過(guò)Apollo客戶端讀取elasticsearch.yml的相關(guān)配置。0h4z343erzy在InternalSettingsPreparer中PrepareEnvironment方法構(gòu)建了一個(gè)Settings實(shí)例來(lái)加載給定或某認(rèn)路經(jīng)下的elasticsearch.yml文件，加載的配置都存放到output中，所以按照設(shè)計(jì)只要讀取Apollo替換output中的值即可，output底層實(shí)現(xiàn)的原理就是map。代碼很簡(jiǎn)單，就是首先讀取elasticsearch.yml配置文件中的值，然后讀取Apollo中default集群中的值，

30、相同的key值進(jìn)行覆蓋，最后讀取Apollo每個(gè)角色配置值，相同的key值覆蓋就可以了。如下就是增加的代碼塊：yx66uxe81注意ES中discovery.zen.ping.unicast.hosts這種參數(shù)的值是中括號(hào)形式括起來(lái)的，底層實(shí)際上是一個(gè)數(shù)組，ES在處理時(shí)會(huì)以參數(shù)+.數(shù)字的方式進(jìn)行標(biāo)識(shí)，所以需要特殊處理一下，最后要加上邏輯判斷防止default中數(shù)組參數(shù)元素個(gè)數(shù)大于角色集群而造成的配置參賽個(gè)數(shù)溢出。另外ES參數(shù)中有些參數(shù)在elasticsearch.yml配置時(shí)需要加上雙引號(hào)，這個(gè)雙引號(hào)在ES真正加載時(shí)不會(huì)讀取，所以在Apollo中配置時(shí)不要帶雙引號(hào)。我在配置http.cors.

31、allow-origin曾經(jīng)直接將雙引號(hào)粘貼過(guò)去，結(jié)果導(dǎo)致了elasticsearch-head插件不可用。修改源碼集成了Apollo客戶端的ES啟動(dòng)日志如下圖所示，在新的日志中打印了讀取配置的信息。從日志中可以清晰地看到首先ES會(huì)讀取本地的配置文件，所有從本地配置文件讀取的配置參數(shù)都記錄為old參數(shù)，然后再?gòu)腁pollo中讀取配置，如果有同名參數(shù)則選擇Apollo參數(shù)直接覆蓋掉。t9yi2grz67zbji4ex93ga這里需要提醒的是在Apollo客戶端集成到ES的過(guò)程中，客戶端所依賴jar包有可能和ES的某些插件的包有沖突，如果有沖突需要提前將這些包替換掉保留一份即可。高可用也是我們特別

32、關(guān)注的功能點(diǎn)，必須保證哪怕Apollo所有服務(wù)都掛掉也不影響ES的正常啟動(dòng)和運(yùn)行。Apollo客戶端在啟動(dòng)后會(huì)在啟動(dòng)用戶的根目錄下創(chuàng)建一個(gè)config-cache緩存目錄，目錄中會(huì)存放所有Apollo的namespace配置文件，文件內(nèi)容就是配置的key-value鍵值對(duì)，保證ES在遇到Apollo服務(wù)不可用，或者網(wǎng)絡(luò)不通的時(shí)候依然能從本地恢復(fù)配置。3frshkp1i4j下表是Apollo官方提供的高可用說(shuō)明，我們?cè)趯?shí)踐中完全按照官方推薦的架構(gòu)搭建了3節(jié)點(diǎn)的Apollo集群，后端使用的MySQL數(shù)據(jù)庫(kù)是主備模式，同時(shí)額外通過(guò)優(yōu)先級(jí)讀取策略在最壞的情況也下會(huì)讀取本地的配置文件實(shí)現(xiàn)了雙保險(xiǎn)（本地緩

33、存文件失效也不影響ES）。g27b1tbllln2、 jvm配置功能開(kāi)發(fā)ES讀取jvm.options配置文件是在啟動(dòng)腳本中直接實(shí)現(xiàn)的，所以無(wú)法通過(guò)直接修改ES源碼來(lái)進(jìn)行Apollo客戶端開(kāi)發(fā)。如果直接修改elasticsearch啟動(dòng)腳本來(lái)讀取jvm配置比較復(fù)雜，而且這樣修改對(duì)原來(lái)的啟動(dòng)腳本改造較大，不是我們所想要的。但jvm參數(shù)本身對(duì)于ES來(lái)講還是具有一定的調(diào)優(yōu)價(jià)值，尤其是內(nèi)存分配上，在單臺(tái)物理機(jī)上啟動(dòng)多個(gè)不同角色節(jié)點(diǎn)可能需要頻繁的調(diào)整。最后我們?cè)趯?shí)現(xiàn)上采用了單獨(dú)開(kāi)發(fā)一個(gè)jar包在elasticsearch啟動(dòng)腳本之前執(zhí)行，讀取Apollo配置如果有key值不同在文件中進(jìn)行替換。Apoll

34、o客戶端上的處理邏輯與elasticsearch.yml完全一樣，優(yōu)先級(jí)都是角色配置default配置配置文件，區(qū)別就是配置文件不一致就直接替換，最終落地還是以配置文件中的參數(shù)配置為準(zhǔn)。代碼就不粘了，啟動(dòng)命令如下：java -jar /logger/Apollo/Apollo-jvm.jar -DApollo.cluster=$APOLLO /logger/elasticsearch/config$APOLLO_PATH/jvm.options這里有幾點(diǎn)需要特殊說(shuō)明一下，首先jvm參數(shù)在jvm.options配置文件中是有兩種格式的，一種就是傳統(tǒng)的以冒號(hào)分隔的key-value鍵值對(duì)，這種在A

35、pollo中直接properties方式處理就好，還有一種參數(shù)既是key值也是value值，如-Xms2g，這種類型參數(shù)我們想了好幾種解決方案，如把key值設(shè)置成和value值一樣、對(duì)數(shù)字進(jìn)行特殊處理、對(duì)特殊參數(shù)單獨(dú)命名等等，但是最后一旦多次修改就會(huì)產(chǎn)生一些邏輯bug，最終我們采取了一種折中的方式，首先如果是key-value鍵值對(duì)類型那么正常處理，如果是單一鍵值的話那么采用前綴字符串匹配的方式實(shí)現(xiàn)，也就是說(shuō)比如-Xms2g這種參數(shù)實(shí)際上在Apollo配置的是-Xms：-Xms2g，當(dāng)Apollo客戶端進(jìn)行文件掃描時(shí)如果是非key-value且符合字符串前綴的就進(jìn)行參數(shù)值覆蓋，這就要求這種配置

36、參數(shù)在進(jìn)行Apollo jvm錄入時(shí)保證是唯一的，這種方案的優(yōu)勢(shì)是一方面jvm參數(shù)一般value值直接做key值或者前綴到數(shù)字之前就可以保證唯一性，另一方面這種方式避免了自己命名參數(shù)導(dǎo)致含義不清，前綴+注釋的方式在頁(yè)面上顯示清晰，有較好的用戶體驗(yàn)。其次因?yàn)槲覀冊(cè)谝慌_(tái)服務(wù)器上實(shí)際上是啟動(dòng)了多個(gè)ES實(shí)例的，所以在Apollo啟動(dòng)命令中是通過(guò)環(huán)境變量來(lái)區(qū)分角色集群和jvm配置文件路徑的，環(huán)境變量通過(guò)進(jìn)程管理工具supervisord來(lái)進(jìn)行傳遞的。最后需要提到的就是在jvm的啟動(dòng)實(shí)例列表中經(jīng)常顯示為0，原因是我們單獨(dú)開(kāi)發(fā)的一個(gè)jar包在ES啟動(dòng)腳本前執(zhí)行，執(zhí)行后這個(gè)客戶端就退出了，前面提過(guò)Apollo

37、的客戶端和服務(wù)端回保持一個(gè)長(zhǎng)連接，這個(gè)長(zhǎng)連接可以保證服務(wù)端獲取客戶端的心跳信息，一旦客戶端退出了Apollo默認(rèn)只展示最近一天訪問(wèn)過(guò)Apollo的實(shí)例，那么一天之后數(shù)據(jù)庫(kù)就會(huì)清空對(duì)應(yīng)字段，jvm啟動(dòng)實(shí)例列表就會(huì)顯示為0。ymdt1jh8593、Supervisord工具結(jié)合進(jìn)行ES Apollo客戶端改造后我們發(fā)現(xiàn)了一個(gè)問(wèn)題：在源碼中按照ES的方式輸出的日志無(wú)法打印到ES的系統(tǒng)日志中。這個(gè)問(wèn)題困擾了我們很久也找不到原因，只能一點(diǎn)點(diǎn)去梳理源碼。通過(guò)ES入口方法類找到了讀取配置文件的EnvironmentAwareCommand中的執(zhí)行方法，該方法是一個(gè)抽象方法，其對(duì)應(yīng)的實(shí)現(xiàn)方法如下圖：3yqrw

38、ywgqqp由上圖可以看到，該execute方法需要先執(zhí)行createEnv方法，即需要執(zhí)行InternalSettingsPreparer.prepareEnvironment(Settings.EMPTY, terminal, settings); （即紅色箭頭指向的1）該方法，而該方法就是Apollo的主要代碼修改與存放區(qū)域。在該方法內(nèi)部，會(huì)進(jìn)行對(duì)環(huán)境的初始化，即對(duì)yml配置文件參數(shù)的加載。但該方法區(qū)并沒(méi)有對(duì)perties配置文件進(jìn)行加載和其他處理。然后其執(zhí)行一個(gè)新的execute方法（即紅色箭頭所標(biāo)識(shí)的2）。該抽象方法所對(duì)應(yīng)的實(shí)現(xiàn)方法如下：33lvgvi0kfv由上圖可以看出，在執(zhí)行e

39、xecute的過(guò)程中，elasticsearch開(kāi)始對(duì)BootStrap這個(gè)類進(jìn)行初始化。8k1ttrhm34w從上圖可以看出，因?yàn)槲覀冃薷牡腅S源碼是在InternalSettingsPreparer類中，prepareEnvironment(Settings input, Terminal terminal, Map properties)方法加載配置yml文件的時(shí)候，此時(shí)perties中的配置還沒(méi)有進(jìn)行加載，在ES對(duì)yml文件加載完成后，才開(kāi)始對(duì)日志的配置文件進(jìn)行的加載。故而出現(xiàn)了在InternalSettingsPreparer類中修改prepareEnvironment方法，添加的日志提示信息沒(méi)有打印在elasticsearch的logs目錄下的日志文件中的現(xiàn)象。如果想將我們手動(dòng)添加的日志打印信息打印在elasticsearch的logs目錄下的日志文件中，只能在BootStrap加載之后的文件中添加才可以實(shí)現(xiàn)，所以ES本身的日志在BootStrap加載之前是沒(méi)有任何日志記錄的。找到了問(wèn)題原因之后，基本可以確定在ES的Apollo客戶端中如果需要打印日志需要引入第三方工具，同時(shí)邏輯上配置參數(shù)的讀取是有優(yōu)先級(jí)的，所以在日志中打印相關(guān)信息確定最終讀取配置值這個(gè)需求是客觀存在的?；诖宋覀?cè)趯?shí)際生產(chǎn)中