解決IT運維人員之痛：京東云自動化運維體系構建實踐

作者：鄭永寬 2018-04-10 09:49:17

京東云作為京東集團能力對外輸出的窗口，實現京東能力+云平臺賦能客戶。其產品覆蓋IaaS層，PaaS層和基于此構建的電商、物流、金融和保險等領域的服務和解決方案。本文主要從保障這些服務穩定性和效率的角度，講解京東云自動化運維體系構建以及實施之路。

【51CTO.com原創稿件】京東云作為京東集團能力對外輸出的窗口，實現京東能力+云平臺賦能客戶。其產品覆蓋IaaS層，PaaS層和基于此構建的電商、物流、金融和保險等領域的服務和解決方案。本文主要從保障這些服務穩定性和效率的角度，講解京東云自動化運維體系構建以及實施之路。

[[225421]]

2017 年 12 月 1 日-2 日，由 51CTO 主辦的 WOTD 全球軟件開發技術峰會在深圳中州萬豪酒店隆重舉行。

京東云資深架構師在主會場與來賓分享了"京東云自動化運維體系構建"的主題演講，以下是演講實錄。

說到京東云，我們最看重運維，需要自動化運維平臺。對此有幾個關鍵問題，主要是圍繞安全、部署變更、網絡管理、監控管理......利用自動化運維來提高平臺架構穩定性和人員的開發效率。

在京東云的整體環境中，除了有我們技術團隊所管理和維護的云自身應用之外，還啟用并提供著各種 SaaS 服務。

如何保持客戶在云端業務的穩定性？我們對此進行了深入的研究和探索，下面分四個部分為大家講解：

京東云自動化運維基礎組件
京東云自動化運維部署介紹
京東云自動化運維監控系統
總結與展望

京東云自動化運維基礎組件

針對上述問題，我們從四個方面進行入手：

服務與資源管理
任務調度管理
監控平臺
客戶端

如上圖所示，京東云運維平臺大致的搭建路線圖為：基礎組件→客戶端體系 →部署系統（包括：各種發布系統、任務調度系統、以及監控系統），最終對運維平臺進行完善，從而更好地服務于我們的客戶。

服務與資源管理

首先我們來看第一個基礎組件：對于服務組織資源的管理，即運用 CMDB 來實現所謂的配置管理。

通過 CMDB 的“服務樹”概念，我們可以掌握如下三個方面：

找到各個服務項之間的依賴關系，進而獲知它們在哪里被用到、由誰在使用、以及其本身所具備的用處。
機器狀態。對于京東這樣體量的大公司而言，機器的數量多達十萬左右，我們需要掌握其中每一臺機器的當前狀態、具體的機型、坐落在哪個機房、以及它們是如何被使用的。
角色管理與基于角色的權限控制，我們需要掌握到具體是誰、能夠在什么時候、進行什么樣的操作、實現什么功能。

所以說，“服務樹”主要涉及到服務在系統中的實時信息，包括：哪個服務處于哪臺機器之上，有哪些實例，屬于哪個 App，具有哪些內部邏輯過程，如何對外部申請所需的權限，以及我們如何實現對它的監控等。這些都需要能從服務器上獲取到。

其次是 Naming service，它能夠解決服務之間的解耦關系，也就是服務和實例間的關聯關系、以及服務向外所提供的窗口。

上圖右側展示了“服務樹”與名字服務的示意圖，最下方展示了一個從應用到實例關系的解耦，往上則是客戶端的 back off（解耦合）。

任務調度管理

第二個基礎組件是任務調度管理。在實際場景中，不管我們是要協同做某個操作、還是進行發布上線、或是對文件進行部署與分發。

這些都需要系統去調度目標機器，以完成相應的任務，也就是我們必須要求指定的機器能夠按照指定的策略，進行指定的命令。由于該過程具有實時性、批量性和共生性，因此對于系統的支撐能力極具挑戰性。

同時，我們需要通過策略來定義不同類型的并發度，比如要對一百臺機器進行發布上線，那么我們不會將它們予以同時部署，而是分批次地進行并發。

因此我們需要規定每次并發的具體任務，判定成功與否的邏輯關系，以及檢驗具體的完成程度，并且還要找出那些超時的狀態。由于這些都是通過底層架構來構建出的各種業務，所以它們的調度邏輯實際上都是一樣的。

另外，所有的執行操作都需要是可追溯的，包括能夠知曉什么人、在什么時間、進行了什么操作，可見安全性和規范性是非常重要的。

而如果出現了故障，我們需要及時地截獲輸出，進而定位問題。這些都是任務調度系統需要基于服務樹和 Naming Service 來實現的基礎邏輯。

監控平臺

第三個基礎組件就是監控平臺。監控無非是從數據采集、到數據匯聚、再到存儲處理的過程。

不同于平時常見的數據監控，我們構建的是時序性數據存儲（TSDB）。由于需要查詢的數據點非常多，因此我們將每次查詢和收集到的監控點信息按照順序存儲起來。

另外，我們的系統具有“讀少寫多”的特點，即：“寫”（寫入數據）相對比較均衡；而“讀”（讀取數據）則具有突發性。

比如說：查看一個監控的狀態，是屬于隨時做的操作。一般此類寫操作是以 1 秒、10 秒、或 1 分鐘作為采集間隔，是一個比較頻發的過程。而讀操作則發生得比較突兀，所以我們需要做到讀寫分離。

因此，我們基于 ES（elasticsearch）實現了 TSPD，其中涉及到兩種封裝：

對于熱點數據的封裝，我們將較為重要的數據，以及那些實時的數據存放在 Redis 中。
同樣，我們對歷史數據也會進行 ES，然后再封裝，從而實現了讀寫的分離。這種數據的雙寫過程，合理地保證了數據的高可用。

監控數據的另一個特點是自動抽樣，有時候一些頻發的查詢會牽扯到較大的時間跨度。

例如：一個月甚至是一年。由于我們的采集數據間隔是 1 秒、10 秒、或 1 分鐘，那么如果直接去查詢所有數據點，需要產生龐大的數據量，當然也就很難實現。

因此，我們對寫操作進行了自動抽樣。當查詢 15 天以上的數據時，我們會把這些數據以每分鐘、或每小時進行聚合，然后放在庫中，進而查詢一個月的數據。

通過自適應路由的方式，我們就可以查到有限量的一小時數據，同時我們的數據庫、以及業務系統速度也能具有較快的水平。

另外，對于那些實時的數據處理，我們主要采用的是多地部署和基于JNS的多調度過程，從而實現了多維度的實時計算。

客戶端

第四個基礎組件就是客戶端，由于所有的業務都需要客戶端，因此對于京東這樣體量的公司而言，會細分為部署類（如 JNS）、監控類、初始化等客戶端類型。

設想一下，如果我們需要對十萬臺機器進行加載部署或是上線升級，其工作量是可想而知的。

就算我們只是維護十幾萬機器的 Agent，由于環境復雜，且存在著多個IP，如果只是按照單一維度去處理諸如“什么時候、出現什么了問題”的話，既耗時又耗力。

所以在此我們引入了 Agent 的資源超限這一重要概念。比如說：對 Agent 的監控，由于占有了部分計算資源，則有可能將當前的服務宕機，那么這種本身處于服務之外的監控就影響到了服務本身的穩定性。

可見對于 Agent 客戶端需要做到如下方面：

管理所有 Agent 的部署和升級。
維護各個 Agent 的存活性。即在發現哪臺機器上的 Agent 宕機的時候，我們需要知道如何將其重新激活上線。
資源超限守護。
分級發布。

在具體實現上，我們運用 ifrit 進行管控。即當一臺機器在引入某個服務時，負責管理的 Agent 會在我們的 ifrit 服務器上進行注冊，以告知其當前所處的分機房和使用的 Agent 的版本。

那么它對應的客戶端就可以相應地將這些信息包下載下來，從而掌握 Agent 的最新版本等信息。這就形成了一個簡單的客戶端體系結構。

京東云自動化運維部署介紹

有了上述客戶端與組件體系的構建基礎，我們進一步構建部署和發布任務就相對比較容易了。

我們先看看應用的部署系統。它除了實現應用部署之外，還管理著各種服務的維護和資源、以及接入的過程。

如上圖所示：我們除了“往前”進行了編譯構建，還“往后”實現了流量接入。

如上圖所示，該 Agent 在此處有著一個核心的要求：實現跨平臺。由于京東整體平臺的環境較為復雜，我們有不同的虛擬機、Docker、物理機，它們需要把前面所提到的多種操作融合起來。

因此我們需要做到如下容錯功能：

不允許出現由于單臺宕機而引發服務故障。
出現了服務故障，系統可以實現自我發現。
面對雙十一和 618 之類的重要促銷場景。系統能夠快速擴容，以應對此類流量的驟增。

針對上述功能的實現，我們在部署中分為兩種類型：

基于 Docker 的鏡像輸出。
基于傳統物理機或虛擬機的包輸出。

一般的流程是：編譯構建自身產品庫（其中包含代碼包和代碼項）→通過部署服務和上述調度系統的部署服務進行發布（在物理機和容器上都可實現）→部署完成開始運行→對運行予以維護（尤其對鏡像日志進行收集）→通過日志服務，進一步做分析。

同時我們在前端做好了流量的接入，中間部分也提供了一個 LB（負載均衡）的網絡。通過上述兩種部署方式，我們可以根據服務的實際需要進行按需升級。

另外，我們此處采用的是基于 NS 的服務自動化與資源管理。它并不需要關心當前服務的具體過程是如何被實現的，而只注重：當前的容量、需要什么資源、以及能夠獲得的資源。

京東云自動化運維監控系統

除了上述提到的部署，我們對監控系統也十分重視。監控最重要的作用就是在出現問題時能夠及時恢復。

要實現這一點就必須做到如下方面：

能在第一時間發現問題，這是恢復的基礎。
快速定位問題，及時判斷問題出在哪里，是虛擬機上還是硬件上。
能夠自動運用既定的算法，通過自動調度預案或人工響應予以快速處理和恢復。

因此，面對既有虛擬機又有 Docker 的復雜環境，為了保證服務器不停止運行，我們在上線過程中采用的是部署聯動式的分級發布。

它可以監控到某個服務是處于機器層、服務層，還是在對外流量接入層、甚至是在網絡層。這些都是監控所需要解決的問題。

上圖是監控的整體架構，這里展示了從底層的數據抽象、到數據的采集，然后經過數據處理，以及離線處理的全過程。

其中數據的采集模式包括：采集 Agent、外部探測和 API 推送。

同時在處理邏輯上包括了：如何去判斷異常類型，以及針對異常所做出的報警類型和采取的是運維通訊還是研發通訊等方式。我們對這些步驟都事先進行了較好的規劃。

當然，這些故障本身又屬于事件類型。因此我們需要考慮如何將事件存儲起來，以方便查詢和進一步做出相應的決策。

由于先前的事件可能會影響到后續事件，因此如果您擁有一個很好的事件庫，那么就能夠讓系統的下游獲取到上游究竟是何時何地出現了何種故障，這些對于下游的排障都是極有幫助的。

與此同時，我們也會對監控的數據進行一些離線處理，通過各種高效的算法，反饋到計算相應的報警之中。最終各種數據都是以趨勢圖或 Dashboard 的方式來展示各種事件和報警。

有了前面的基礎，我們所構建的京東云監控體系就由如下四種監控類型組成：

基礎監控，針對的是機器層面，不需要用戶去配置，自動采集的是 CPU、內存、硬盤、網絡等簡單的信息。
存活監控，針對的是服務監控，包括監控進程、端口和語義等方面。
性能監控，針對的是服務層的對外表現狀況。我們通過四大核心指標，來解決服務性能上是否存在異常。同時我們運用日志監控來收集pv、錯誤和容量，并確定所謂的異常邊界的問題。
業務監控，類似于黑盒子，從用戶的角度來觀察服務，發現問題。例如：所有服務指標狀態都顯示 OK，但是服務對外表現不佳，網站無法被訪問。

這個問題實際上對于京東來說會非常地嚴重，因為它會直接影響到用戶流量乃至用戶訂單的損失，所以我們要從用戶的層面上做好黑盒檢測。

基礎監控