京東微信手Q運維體系概覽

• 2019 年 11 月 20 日
• 筆記

Pax，中文名姜鵬先，現在在京東微信手Q部門，對數據存儲、應用運維、運維平台建設有著豐富的經驗。

京東微信手Q的後台運維體系架構和騰訊遊戲類似，也把具體的工作進行了分層的拆解。其中CMDB, 配置中心（包含agent控制），調度系統，發布系統和我們現有的運維體系有異曲同工之妙。此外在監控領域對小米開源框架open-falcon進行改進以後，結合業務開發形成了自己特有的監控體系。接下來我們詳細看看京東微信手Q的運維體系演進歷程吧~

背景

幾年前運維迎來業務上的一次融合，從而倒逼後端的IT能力進行整合。因為系統間的依賴關係，另外運行環境也有差別，導致系統遷移後無法使用，因此在不改變當前發布模式的情況下，需要重建依賴的運維平台體系並進行改造，需求由此而生並隨著業務發展向外擴展。本文將帶大家去了解平台從過去到現在，新的設計方案如何融合到現有體系中？重新設計後的平台又帶來了什麼樣的變化？在建設的過程中，團隊又獲得了什麼樣的心得和體驗？

當前現狀

融合時期保留了發布部署系統，業務調度，DB需求與執行平台和配置中心，這就帶來兩個問題：

1. 運行環境不同，所有系統需要修改重編保證在新平台的穩定運行

2. 發布部署系統等強依賴CMDB的設備與業務的關係，從而管控發布流程

因此為了保證業務能夠正常迭代，需要重建關鍵路徑，經過兩年的努力，目前體系組成大致框架如下所示，部分是融合之前電商的系統，部分是新搭建的平台：

1. CMDB

與其他互聯網公司類似，通過底層CMDB構建設備與業務、設備與人的關係，設備生命周期、生命狀態的記錄，進而以資源管理系統的角色提供資訊給其他所有系統調用。對於CMDB數據的維護，我們通過多種系統與其聯動反向保證數據準確性，比如與RPM包發布的聯動：

因為融合前系統依賴的CMDB為業務型CMDB，因此我們重建時也以業務CMDB為目標。

2. 配置中心

配置中心為留存下來的重要系統，管理訪問路由和DB路由資訊，負責負載均衡、業務容災、以及所有業務包的基礎配置、業務間調用、DB路由訪問與自動切換等配置資訊的版本管理和下發、以及設備角色的管理，通過配置agent完成配置中心到目標機器記憶體的下發。大致架構圖如下圖所示：

Configprocessor採用多執行緒模型，並行處理configagent和jsf的事務，用戶通過門戶輸入配置中心並提交至DB交由server讀取，agent與serer保持長連接，會定期發送本地共享記憶體的時間戳到server，server判斷時間戳是否過時，過時則發送新的配置文件內容到agent，agent將配置資訊更新至共享記憶體並刷新時間戳，另外server也會主動將配置資訊下發至agent，共享記憶體中維護互斥鎖，保證更新不衝突。此外配置中心還支援白名單功能，對配置進行灰度。

3. 調度系統

負責對設備的命令執行和文件下發，其他系統任何的文件或者命令下發動作，都集中通過調度系統去處理，這樣做的好處就是可追蹤，許可權可控且返回日誌統一。比如DB需求自動執行平台，需求者提出需求後，平台初審完畢交由DBA審批，審批完畢後需求平台將SQL打包為腳本，通過調度平台傳遞到目的端執行，並返回結果。

4. 應用持續部署

應用部署我們採用的是RPM的方案，目前也是業界少有的採用開源包管理方案，主要的考慮點是：

1. RPM作為開源界通用的方案已經非常成熟，開發可以自由在spec文件中安裝前，安裝後，卸載後等各階段的動作進行定義

2. 通過在spec文件中標註包所屬組的概念，可以很好地管控包發布許可權

3. 通過在spec中定義Requires，可以方便的管理依賴關係，平台不再維護複雜的包依賴。

目前研發通過JATS對C++包進行編譯，然後通過RPM將編譯成功的二進位文件進行RPM包的打包，通過包發布對設備角色（dev，gamma，idc） 和人員（開發，測試，運維）角色進行定義並做相應發布，管控發布流程。EOS則是運營人員對頁面片和CDN的發布和回滾，通過配置中心區分設備角色，再進行相應頁面片文件的下發。安全掃描包括CGI，域名的掃描，定時發起線上漏洞掃描，保證業務安全。

5. 品質監控平台

GMS基礎監控平台根據openfalcon開源修改，對實體機和docker進行基礎項、組件和自定義的監控告警，日誌監控目前自研平台，通過對日誌的採集過濾和統計，接入GMS基礎監控平台，對nginx日誌進行監控，紅綠燈系統監控為業務維度的監控，通過集團的可用率上報細化到業務的健康狀態管理，模調系統藉助配置中心的業務間調用關係完成調用鏈的梳理和調用環節的可用率統計。容量管理通過GMS基礎監控的數據，進行設備和業務維度的負載率計算和高低負載管理。

6. DB管理平台

深圳側DB層主要為mysql與redis，所以圍繞這兩個做了DB需求自動化執行，備份中心和自研redis集群的實例管理。

下面針對這些平台的搭建和改造歷程做下大致闡述：

融合方案

業務整合以後，業務需要快速迭代，效率為先，通過對系統的依賴梳理，我們確定了從下而上先填補再擴充的方案。即從最底層的CMDB開始向上，填補掉現有系統強依賴的關鍵路徑，再去建設缺少部分。第一階段我們決定重建一個小型的CMDB，用於解決大多數留存系統的關鍵依賴；第二階段為確保留存系統正常運轉，以保證業務快速迭代上線；第三階段我們著重品質上的提升，下面對三個階段做簡單介紹：

第一階段：重建小型CMDB

關於CMDB系統，用途上通常分為兩層，面向基礎設施的資源管理系統和面向業務的資源管理系統，對於京東深圳業務部門主要偏向業務層，因此系統建設主要偏向面向業務，基礎設施層則由集團進行管理。為了快速匹配現有系統實現核心需求，CMDB的業務標示沿用之前方式，利用模組樹進行管理，按照深圳業務三層模組進行標示。如圖所示：

作為面向業務的資源管理，數據變動頻繁，可維護性非常重要，在業務部門沒有機房自動發現，拓撲獲取許可權的情況下，主要通過資源共享來保證數據準確。通過對外提供API進行資源共享和維護，比如維護設備狀態，設備負責人數據用於監控系統的判定和推送；維護模組環境屬性用於RPM包系統的包發布判定測試與IDC環境，便於發布的管控，從而反向保證數CMDB據的準確性。

目前CMDB管理23個屬性，包括設備屬性（IP，配置資訊，機房），設備與業務關係（業務模組，所屬集群），設備與人的關係（運維負責人，所屬研發），設備生命狀態（維護，運營），生命周期（流轉記錄）等，基本標示了當前設備的畫像。當然這裡還需要與RPM包發布，配置中心結合起來，管理服務包與基礎包的資訊等。

第二階段：確保留存系統正常運轉

留存系統主要為配置中心和發布部署系統，篇幅所限這裡只介紹RPM系統，目前系統完成打包，包資訊登記，版本管理，發布與回滾，許可權控制等動作，目前管理包1200餘個，兩年時間中支援發布7w次， 很好地完成了日常包發布和緊急擴容等需求，簡單架構如下：

dashboard如下：

目前我們也在考慮對現存RPM系統的改造，如今已經大規模應用docker，如何將包發布與docker充分結合，發揮docker快速交付的優勢是需要優化的地方。

第三階段：品質優化與提升

業務系統可用後，我們開始進行擴充，首先考慮提升品質，主要是建立一套自下而上的立體化監控，運維主要負責最低兩層的搭建並向上提供API。

任何監控，數據為先，因此著重匯聚各種數據來源，並進行整合，主要為CMDB、採集agent、配置中心調用關係、集團UMP數據上報點等四者進行關聯。

基礎設施層和基礎組件監控系統

各種考察之後採用了小米開源的openfalcon並進行了改造。改造點如下：

1. agent同時適配實體機與docker

2. 打通CMDB並新建API方便未來容量系統進行數據共享，打通自研的告警網關（郵件、簡訊、微信）

3. 將系統改造成主要面嚮應用/模組的監控

4. 擴展服務組件監控的功能，對nginx，mysql，redis和其他自研組件做特別收集

5. 方便插件開發和使用

系統建設期間面臨的第一個問題就是京東當時正在大規模採用docker，這對於傳統的採集agent不再適用，為了避免不同類型設備割裂為不同系統的情況，對agent端進行了改造，採取相同彙報格式不同採集方式，鑒於對母機沒有許可權下放，與南京雲平台合作，實體機採取傳統採集，docker採用api數據並整合，對二者監控項進行了統一，從而表現形式上實現了統一。

目前監控上報設備基礎監控項，比如CPU，記憶體，丟包率，重傳率，文件節點，coredump等，另外對服務組件有特殊的上報內容，比如nginx的nginx.conn.active， nginx.conn.reading等。

為了保證告警有效性，我們通過不同應用的個性化監控策略，維持每日基礎告警數在20-50之間，從而保證運維對告警的敏感度。下圖為dashboard：

如下圖按照模組的綜合視圖，用戶在大批量的橫向對比中對數字的敏感度要高於圖線敏感度，因此我們將數字設為首屏，圖線作為第二入口提供趨勢的查看

下圖組件監控的部署流程，以nginx為例：

日誌分析目前正在完善，由於架構特殊性，需要對nginx日誌做二次處理，因此在收集端做了開發，消費者log-viewer採用多進程處理，便於錯誤日誌過多時消息隊列擁塞，目前架構圖如下：

日誌分析中的域名錯誤數監控：

應用層監控

通過紅綠燈系統來承擔，根據集團的UMP業務監控系統數據做了整合，直觀的按照紅黃綠三色做標示

介面層監控

介面層監控系統根據上文的配置中心，梳理出調用關係，再根據ump上報，計算出當前可用率

心得

隨著進入京東的體系之後，我們重新審視，如何用大電商平台化的思維來持續優化我們的平台，比如說精細化的管理和監控，持續交付Docker化。我們都知道目前京東是中國Docker使用最兇猛的公司，Docker作為一種新的IT對象，對原有的持續部署、CMDB、監控、數據分析等平台都提出了新的體系和要求。

其實世界上最痛苦的事情就是莫過於做遺留系統整合的事情了，我們用一年多時間來完成了這次的整合、遷移和新業務上線。其中涉及到底層伺服器數千台，業務模組300多個，應用100多個的能力遷移，有挑戰，更是慢慢的收穫與心得。

運維繫統的搭建過程是一個從運維到運營觀念轉變過程。

當通過標準化對具體的設備和抽象的業務進行規範，搭建起來基本的持續交付系統，採集到各項數據做監控之後，如何利用現有系統更進一步的提升效率，利用數據為業務提供更多的參考支援是更進一步需要思考的能力；比如如何利用RPM更進一步快速交付擴容讓開發滿意，如何更精細的收集日誌分析數據使研發對自己的CGI使用有更多的了解，這些都是運維需要考慮的問題。

CMDB的分層解耦很重要

一定要把CMDB區分出基礎資源管理型CMDB和業務型CMDB，面向上層應用的CMDB可以脫離底層基礎資源層的CMDB而存在，通過自己的一套數據自動化發現和運維變更體系來完善CMDB數據。強依賴是上層運維管理平台遷移的最大障礙。

自上而下的業務驅動產生需求和自下而上的系統建設分而治之

這一點在業務融合中非常明顯，當有一個相對成熟的中間系統時，如何才能保證系統穩定並以此為核心擴展，這一需求從上而下發生，並且需要建設者自下而上的建設。

每個系統都是一個資源池，通過系統關聯進行資源池共享才能盤活系統，保證系統高效準確的運轉，而不是淪落為一個工具平台

系統建立起來後維護非常重要，加強系統間依賴是減輕系統維護的一個重要方式，也是盤活平台的關鍵路徑，比如RPM系統如何與CMDB聯動，數據採集端的數據提供上來後，監控、容量管理、CMDB三者結合很容易為IT運營分析做支撐。

運維繫統的設計多諮詢研發和業務產品經理

這裡的諮詢不只包括技術上的，也是使用上的，業務研發和產品經理作為最靠近用戶的一端，對原型設計，系統使用上如何影響用戶比運維要專業，何況運維平台的用戶也來自研發，一個對用戶方便的系統比較容易推廣使用，也容易受到回饋，當然，記得任何系統都要把回饋入口放在顯眼位置：)

運維平台建設也是一個迭代和演進的過程

如果沒有業務變更，就沒有此次平台的迭代；如果沒有Docker快速的引入，就無需對RPM平台進行演進。因此運維平台本身也和業務技術架構一樣，隨著業務和技術的變化，本身也在強調適應性。