【51CTO.com原創(chuàng)稿件】京東云作為京東集團(tuán)能力對(duì)外輸出的窗口，實(shí)現(xiàn)京東能力+云平臺(tái)賦能客戶。其產(chǎn)品覆蓋IaaS層，PaaS層和基于此構(gòu)建的電商、物流、金融和保險(xiǎn)等領(lǐng)域的服務(wù)和解決方案。本文主要從保障這些服務(wù)穩(wěn)定性和效率的角度，講解京東云自動(dòng)化運(yùn)維體系構(gòu)建以及實(shí)施之路。

[[225421]]

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

京東云資深架構(gòu)師在主會(huì)場(chǎng)與來賓分享了"京東云自動(dòng)化運(yùn)維體系構(gòu)建"的主題演講，以下是演講實(shí)錄。

說到京東云，我們最看重運(yùn)維，需要自動(dòng)化運(yùn)維平臺(tái)。對(duì)此有幾個(gè)關(guān)鍵問題，主要是圍繞安全、部署變更、網(wǎng)絡(luò)管理、監(jiān)控管理......利用自動(dòng)化運(yùn)維來提高平臺(tái)架構(gòu)穩(wěn)定性和人員的開發(fā)效率。

在京東云的整體環(huán)境中，除了有我們技術(shù)團(tuán)隊(duì)所管理和維護(hù)的云自身應(yīng)用之外，還啟用并提供著各種 SaaS 服務(wù)。

如何保持客戶在云端業(yè)務(wù)的穩(wěn)定性？我們對(duì)此進(jìn)行了深入的研究和探索，下面分四個(gè)部分為大家講解：

• 京東云自動(dòng)化運(yùn)維基礎(chǔ)組件
• 京東云自動(dòng)化運(yùn)維部署介紹
• 京東云自動(dòng)化運(yùn)維監(jiān)控系統(tǒng)
• 總結(jié)與展望

京東云自動(dòng)化運(yùn)維基礎(chǔ)組件

針對(duì)上述問題，我們從四個(gè)方面進(jìn)行入手：

• 服務(wù)與資源管理
• 任務(wù)調(diào)度管理
• 監(jiān)控平臺(tái)
• 客戶端

如上圖所示，京東云運(yùn)維平臺(tái)大致的搭建路線圖為：基礎(chǔ)組件→客戶端體系 →部署系統(tǒng)（包括：各種發(fā)布系統(tǒng)、任務(wù)調(diào)度系統(tǒng)、以及監(jiān)控系統(tǒng)），最終對(duì)運(yùn)維平臺(tái)進(jìn)行完善，從而更好地服務(wù)于我們的客戶。

服務(wù)與資源管理

首先我們來看第一個(gè)基礎(chǔ)組件：對(duì)于服務(wù)組織資源的管理，即運(yùn)用 CMDB 來實(shí)現(xiàn)所謂的配置管理。

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

• 找到各個(gè)服務(wù)項(xiàng)之間的依賴關(guān)系，進(jìn)而獲知它們?cè)谀睦锉挥玫?、由誰在使用、以及其本身所具備的用處。
• 機(jī)器狀態(tài)。對(duì)于京東這樣體量的大公司而言，機(jī)器的數(shù)量多達(dá)十萬左右，我們需要掌握其中每一臺(tái)機(jī)器的當(dāng)前狀態(tài)、具體的機(jī)型、坐落在哪個(gè)機(jī)房、以及它們是如何被使用的。
• 角色管理與基于角色的權(quán)限控制，我們需要掌握到具體是誰、能夠在什么時(shí)候、進(jìn)行什么樣的操作、實(shí)現(xiàn)什么功能。

所以說，“服務(wù)樹”主要涉及到服務(wù)在系統(tǒng)中的實(shí)時(shí)信息，包括：哪個(gè)服務(wù)處于哪臺(tái)機(jī)器之上，有哪些實(shí)例，屬于哪個(gè) App，具有哪些內(nèi)部邏輯過程，如何對(duì)外部申請(qǐng)所需的權(quán)限，以及我們?nèi)绾螌?shí)現(xiàn)對(duì)它的監(jiān)控等。這些都需要能從服務(wù)器上獲取到。

其次是 Naming service，它能夠解決服務(wù)之間的解耦關(guān)系，也就是服務(wù)和實(shí)例間的關(guān)聯(lián)關(guān)系、以及服務(wù)向外所提供的窗口。

上圖右側(cè)展示了“服務(wù)樹”與名字服務(wù)的示意圖，最下方展示了一個(gè)從應(yīng)用到實(shí)例關(guān)系的解耦，往上則是客戶端的 back off（解耦合）。

任務(wù)調(diào)度管理

第二個(gè)基礎(chǔ)組件是任務(wù)調(diào)度管理。在實(shí)際場(chǎng)景中，不管我們是要協(xié)同做某個(gè)操作、還是進(jìn)行發(fā)布上線、或是對(duì)文件進(jìn)行部署與分發(fā)。

這些都需要系統(tǒng)去調(diào)度目標(biāo)機(jī)器，以完成相應(yīng)的任務(wù)，也就是我們必須要求指定的機(jī)器能夠按照指定的策略，進(jìn)行指定的命令。由于該過程具有實(shí)時(shí)性、批量性和共生性，因此對(duì)于系統(tǒng)的支撐能力極具挑戰(zhàn)性。

同時(shí)，我們需要通過策略來定義不同類型的并發(fā)度，比如要對(duì)一百臺(tái)機(jī)器進(jìn)行發(fā)布上線，那么我們不會(huì)將它們予以同時(shí)部署，而是分批次地進(jìn)行并發(fā)。

因此我們需要規(guī)定每次并發(fā)的具體任務(wù)，判定成功與否的邏輯關(guān)系，以及檢驗(yàn)具體的完成程度，并且還要找出那些超時(shí)的狀態(tài)。由于這些都是通過底層架構(gòu)來構(gòu)建出的各種業(yè)務(wù)，所以它們的調(diào)度邏輯實(shí)際上都是一樣的。

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

而如果出現(xiàn)了故障，我們需要及時(shí)地截獲輸出，進(jìn)而定位問題。這些都是任務(wù)調(diào)度系統(tǒng)需要基于服務(wù)樹和 Naming Service 來實(shí)現(xiàn)的基礎(chǔ)邏輯。

監(jiān)控平臺(tái)

第三個(gè)基礎(chǔ)組件就是監(jiān)控平臺(tái)。監(jiān)控?zé)o非是從數(shù)據(jù)采集、到數(shù)據(jù)匯聚、再到存儲(chǔ)處理的過程。

不同于平時(shí)常見的數(shù)據(jù)監(jiān)控，我們構(gòu)建的是時(shí)序性數(shù)據(jù)存儲(chǔ)（TSDB）。由于需要查詢的數(shù)據(jù)點(diǎn)非常多，因此我們將每次查詢和收集到的監(jiān)控點(diǎn)信息按照順序存儲(chǔ)起來。

另外，我們的系統(tǒng)具有“讀少寫多”的特點(diǎn)，即：“寫”（寫入數(shù)據(jù)）相對(duì)比較均衡；而“讀”（讀取數(shù)據(jù)）則具有突發(fā)性。

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

因此，我們基于 ES（elasticsearch）實(shí)現(xiàn)了 TSPD，其中涉及到兩種封裝：

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

監(jiān)控?cái)?shù)據(jù)的另一個(gè)特點(diǎn)是自動(dòng)抽樣，有時(shí)候一些頻發(fā)的查詢會(huì)牽扯到較大的時(shí)間跨度。

例如：一個(gè)月甚至是一年。由于我們的采集數(shù)據(jù)間隔是 1 秒、10 秒、或 1 分鐘，那么如果直接去查詢所有數(shù)據(jù)點(diǎn)，需要產(chǎn)生龐大的數(shù)據(jù)量，當(dāng)然也就很難實(shí)現(xiàn)。

因此，我們對(duì)寫操作進(jìn)行了自動(dòng)抽樣。當(dāng)查詢 15 天以上的數(shù)據(jù)時(shí)，我們會(huì)把這些數(shù)據(jù)以每分鐘、或每小時(shí)進(jìn)行聚合，然后放在庫(kù)中，進(jìn)而查詢一個(gè)月的數(shù)據(jù)。

通過自適應(yīng)路由的方式，我們就可以查到有限量的一小時(shí)數(shù)據(jù)，同時(shí)我們的數(shù)據(jù)庫(kù)、以及業(yè)務(wù)系統(tǒng)速度也能具有較快的水平。

另外，對(duì)于那些實(shí)時(shí)的數(shù)據(jù)處理，我們主要采用的是多地部署和基于JNS的多調(diào)度過程，從而實(shí)現(xiàn)了多維度的實(shí)時(shí)計(jì)算。  

客戶端

第四個(gè)基礎(chǔ)組件就是客戶端，由于所有的業(yè)務(wù)都需要客戶端，因此對(duì)于京東這樣體量的公司而言，會(huì)細(xì)分為部署類（如 JNS）、監(jiān)控類、初始化等客戶端類型。

設(shè)想一下，如果我們需要對(duì)十萬臺(tái)機(jī)器進(jìn)行加載部署或是上線升級(jí)，其工作量是可想而知的。

就算我們只是維護(hù)十幾萬機(jī)器的 Agent，由于環(huán)境復(fù)雜，且存在著多個(gè)IP，如果只是按照單一維度去處理諸如“什么時(shí)候、出現(xiàn)什么了問題”的話，既耗時(shí)又耗力。

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

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

• 管理所有 Agent 的部署和升級(jí)。
• 維護(hù)各個(gè) Agent 的存活性。即在發(fā)現(xiàn)哪臺(tái)機(jī)器上的 Agent 宕機(jī)的時(shí)候，我們需要知道如何將其重新激活上線。
• 資源超限守護(hù)。
• 分級(jí)發(fā)布。

在具體實(shí)現(xiàn)上，我們運(yùn)用 ifrit 進(jìn)行管控。即當(dāng)一臺(tái)機(jī)器在引入某個(gè)服務(wù)時(shí)，負(fù)責(zé)管理的 Agent 會(huì)在我們的 ifrit 服務(wù)器上進(jìn)行注冊(cè)，以告知其當(dāng)前所處的分機(jī)房和使用的 Agent 的版本。

那么它對(duì)應(yīng)的客戶端就可以相應(yīng)地將這些信息包下載下來，從而掌握 Agent 的最新版本等信息。這就形成了一個(gè)簡(jiǎn)單的客戶端體系結(jié)構(gòu)。

京東云自動(dòng)化運(yùn)維部署介紹

有了上述客戶端與組件體系的構(gòu)建基礎(chǔ)，我們進(jìn)一步構(gòu)建部署和發(fā)布任務(wù)就相對(duì)比較容易了。

我們先看看應(yīng)用的部署系統(tǒng)。它除了實(shí)現(xiàn)應(yīng)用部署之外，還管理著各種服務(wù)的維護(hù)和資源、以及接入的過程。

如上圖所示：我們除了“往前”進(jìn)行了編譯構(gòu)建，還“往后”實(shí)現(xiàn)了流量接入。

如上圖所示，該 Agent 在此處有著一個(gè)核心的要求：實(shí)現(xiàn)跨平臺(tái)。由于京東整體平臺(tái)的環(huán)境較為復(fù)雜，我們有不同的虛擬機(jī)、Docker、物理機(jī)，它們需要把前面所提到的多種操作融合起來。

因此我們需要做到如下容錯(cuò)功能：

• 不允許出現(xiàn)由于單臺(tái)宕機(jī)而引發(fā)服務(wù)故障。
• 出現(xiàn)了服務(wù)故障，系統(tǒng)可以實(shí)現(xiàn)自我發(fā)現(xiàn)。
• 面對(duì)雙十一和 618 之類的重要促銷場(chǎng)景。系統(tǒng)能夠快速擴(kuò)容，以應(yīng)對(duì)此類流量的驟增。

針對(duì)上述功能的實(shí)現(xiàn)，我們?cè)诓渴鹬蟹譃閮煞N類型：

• 基于 Docker 的鏡像輸出。
• 基于傳統(tǒng)物理機(jī)或虛擬機(jī)的包輸出。

一般的流程是：編譯構(gòu)建自身產(chǎn)品庫(kù)（其中包含代碼包和代碼項(xiàng)）→通過部署服務(wù)和上述調(diào)度系統(tǒng)的部署服務(wù)進(jìn)行發(fā)布（在物理機(jī)和容器上都可實(shí)現(xiàn)）→部署完成開始運(yùn)行→對(duì)運(yùn)行予以維護(hù)（尤其對(duì)鏡像日志進(jìn)行收集）→通過日志服務(wù)，進(jìn)一步做分析。

同時(shí)我們?cè)谇岸俗龊昧肆髁康慕尤?，中間部分也提供了一個(gè) LB（負(fù)載均衡）的網(wǎng)絡(luò)。通過上述兩種部署方式，我們可以根據(jù)服務(wù)的實(shí)際需要進(jìn)行按需升級(jí)。

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

京東云自動(dòng)化運(yùn)維監(jiān)控系統(tǒng)

除了上述提到的部署，我們對(duì)監(jiān)控系統(tǒng)也十分重視。監(jiān)控最重要的作用就是在出現(xiàn)問題時(shí)能夠及時(shí)恢復(fù)。

要實(shí)現(xiàn)這一點(diǎn)就必須做到如下方面：

• 能在第一時(shí)間發(fā)現(xiàn)問題，這是恢復(fù)的基礎(chǔ)。
• 快速定位問題，及時(shí)判斷問題出在哪里，是虛擬機(jī)上還是硬件上。
• 能夠自動(dòng)運(yùn)用既定的算法，通過自動(dòng)調(diào)度預(yù)案或人工響應(yīng)予以快速處理和恢復(fù)。

因此，面對(duì)既有虛擬機(jī)又有 Docker 的復(fù)雜環(huán)境，為了保證服務(wù)器不停止運(yùn)行，我們?cè)谏暇€過程中采用的是部署聯(lián)動(dòng)式的分級(jí)發(fā)布。

它可以監(jiān)控到某個(gè)服務(wù)是處于機(jī)器層、服務(wù)層，還是在對(duì)外流量接入層、甚至是在網(wǎng)絡(luò)層。這些都是監(jiān)控所需要解決的問題。

上圖是監(jiān)控的整體架構(gòu)，這里展示了從底層的數(shù)據(jù)抽象、到數(shù)據(jù)的采集，然后經(jīng)過數(shù)據(jù)處理，以及離線處理的全過程。

其中數(shù)據(jù)的采集模式包括：采集 Agent、外部探測(cè)和 API 推送。

同時(shí)在處理邏輯上包括了：如何去判斷異常類型，以及針對(duì)異常所做出的報(bào)警類型和采取的是運(yùn)維通訊還是研發(fā)通訊等方式。我們對(duì)這些步驟都事先進(jìn)行了較好的規(guī)劃。

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

由于先前的事件可能會(huì)影響到后續(xù)事件，因此如果您擁有一個(gè)很好的事件庫(kù)，那么就能夠讓系統(tǒng)的下游獲取到上游究竟是何時(shí)何地出現(xiàn)了何種故障，這些對(duì)于下游的排障都是極有幫助的。

與此同時(shí)，我們也會(huì)對(duì)監(jiān)控的數(shù)據(jù)進(jìn)行一些離線處理，通過各種高效的算法，反饋到計(jì)算相應(yīng)的報(bào)警之中。最終各種數(shù)據(jù)都是以趨勢(shì)圖或 Dashboard 的方式來展示各種事件和報(bào)警。

有了前面的基礎(chǔ)，我們所構(gòu)建的京東云監(jiān)控體系就由如下四種監(jiān)控類型組成：

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

這個(gè)問題實(shí)際上對(duì)于京東來說會(huì)非常地嚴(yán)重，因?yàn)樗鼤?huì)直接影響到用戶流量乃至用戶訂單的損失，所以我們要從用戶的層面上做好黑盒檢測(cè)。

基礎(chǔ)監(jiān)控

具體來說，對(duì)于機(jī)器監(jiān)控，我們從采集、到計(jì)算、再到報(bào)警，實(shí)現(xiàn)了機(jī)器連通性的全程自動(dòng)化，從而免于人工的干預(yù)。

同時(shí)我們給各種報(bào)警指標(biāo)設(shè)定了默認(rèn)值，比如說：通過發(fā)現(xiàn)某臺(tái)機(jī)器的 cpu.idle 小于 10%，我們就可以獲知它所隸屬的服務(wù)，從服務(wù)名稱獲知其維護(hù)者是誰，進(jìn)而向其維護(hù)者發(fā)出報(bào)警信息，通過報(bào)警信息我們就能大概知曉相關(guān)的數(shù)據(jù)，這樣便實(shí)現(xiàn)了后臺(tái)聯(lián)動(dòng)。

存活監(jiān)控

對(duì)于存活監(jiān)控來說，主要查看的是進(jìn)程以及端口兩個(gè)方面是否存活。為了實(shí)現(xiàn)部署聯(lián)動(dòng)，我們規(guī)定了進(jìn)程與端口的部署路徑。

有了進(jìn)程的路徑，我們就能獲知進(jìn)程的類型和對(duì)外開通的端口，從而實(shí)現(xiàn)了自然監(jiān)控。

性能監(jiān)控

我們?cè)賮砜葱阅鼙O(jiān)控方面，它主要關(guān)注的是服務(wù)對(duì)外的指標(biāo)，該指標(biāo)一般來自于日志。

為了統(tǒng)一，我們事先規(guī)定、規(guī)范、并約定一種日志格式，從多個(gè)維度讀取日志信息里的不同 tag（標(biāo)簽）值。

比如說：從宏觀層面上看京東的整體流量是平穩(wěn)的，但是我們通過多維度的聚合，就能發(fā)現(xiàn)某個(gè)省的機(jī)房流量存在著細(xì)微的底層波動(dòng)。

當(dāng)然在采集方式上除了從日志里主動(dòng)抓取之外，我們還能從程序和用戶處的報(bào)警來獲知。

業(yè)務(wù)監(jiān)控

業(yè)務(wù)監(jiān)控是從用戶處查看服務(wù)是否正常。例如：電商常用到的是通過模擬全國(guó)各地的用戶訪問來發(fā)現(xiàn)分省份、分運(yùn)營(yíng)商或者分機(jī)房訪問的情況。

這就是運(yùn)用外網(wǎng)或是自定義的方式來測(cè)試業(yè)務(wù)。另外，我們也會(huì)運(yùn)用模擬云操作的方式，去監(jiān)控云服務(wù)。

例如：模擬一個(gè)用戶登錄到云網(wǎng)站→購(gòu)買一臺(tái)主機(jī)→部署一個(gè)鏡像→進(jìn)行一次發(fā)布。

我們來判斷全程是否一切正常。如此，我們就能夠從用戶的角度，先于用戶發(fā)現(xiàn)問題、處理問題、并排除故障。

總結(jié)與展望

如上圖所示，我們最終在前面的基礎(chǔ)上構(gòu)建了京東云的自動(dòng)化運(yùn)維平臺(tái) ark。

在界面上，它能夠提供：

• 配置管理、JNS 管理和資源管理。
• 當(dāng)天的部署過程。
• 應(yīng)用相關(guān)的工具和組件。
• 各種報(bào)表。
• 監(jiān)控的對(duì)外展示，包括如何做對(duì)比、報(bào)表和查詢。

總結(jié)起來，我們的監(jiān)控自動(dòng)化平臺(tái)，通過各種技術(shù)的運(yùn)用基本實(shí)現(xiàn)了服務(wù)化，做到了全生命周期的 DevOps。

面對(duì)數(shù)量龐大的 SaaS 客戶，我們的解決方案為他們保證了交付效率、節(jié)約了成本、并為各種可能碰到的問題做好了準(zhǔn)備。 

[[225423]]

鄭永寬，京東云資深架構(gòu)師，華中科技大學(xué)碩士。擁有 6 年自動(dòng)化運(yùn)維平臺(tái)研發(fā)運(yùn)營(yíng)經(jīng)驗(yàn)。2011 年-2016 年任百度自動(dòng)化運(yùn)維平臺(tái)經(jīng)理，主要負(fù)責(zé)分布式任務(wù)調(diào)度系統(tǒng)，數(shù)據(jù)傳輸系統(tǒng)，百度部署發(fā)布系統(tǒng)。2016 年至今，任京東云運(yùn)維平臺(tái)負(fù)責(zé)人，主要負(fù)責(zé)京東云自動(dòng)化運(yùn)維體系構(gòu)建。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】