2017年12月01-02日，由51CTO主辦的WOTD 2017全球軟件開發(fā)技術峰會在深圳中洲萬豪酒店召開。秉承專注技術、服務技術人員的理念，自2012年以來，WOT品牌大會成功舉辦了十四屆，積累了大量的技術專家資源，獲得了廣大IT從業(yè)者和技術愛好者的一致認可，成為了業(yè)界重要的技術分享交流平臺以及人脈拓展平臺。

本次會議分為10個技術主題，分別是：編程語言與框架，大數據系統(tǒng)架構設計、微服務與容器技術、前端開發(fā)實戰(zhàn)、物聯網（IOT）技術、軟件性能優(yōu)化、深度學習與智能應用開發(fā)、創(chuàng)新運維探索、技術架構遇到業(yè)務架構、CTO訓練營。51CTO作為本次大會的主辦方，將全程圖文直播報道與后期視頻展示這場盛宴。

12月01日上午WOTD2017主會場，京東云資深架構師鄭永寬進行了主題為《京東云自動化運維體系構建》的精彩演講。以下是演講實錄，讓我們先睹為快！

大家了解的京東可能是京東電商，事實上在京東有四個最主要的平臺：電商、物流、金融和保險。京東有技術設施、主機網絡，上面還有一些中間件和PaaS服務，而最主要是我們的電商和物流。

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

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

京東云運維的挑戰(zhàn)是什么？其實京東云不單是提供PaaS服務，而且還提供一些SaaS服務?？蛻舻臉I(yè)務如何保持穩(wěn)定？其實是非常富有挑戰(zhàn)的問題。在這個過程中，我們大概的經歷是，首先從運維技術手，比如服務署、調度系統(tǒng)、客戶端管理系統(tǒng)等等，在這個基礎上把客戶端搭建起來，有了客戶端體系和技術理念才能構建剛才說的這些部署系統(tǒng)，還有發(fā)布系統(tǒng)和任務調度系統(tǒng)，以及監(jiān)控系統(tǒng)等等。最終，我們把這些能力SaaS化，從而支撐更多的人做這些事情，從而更好地服務京東云客戶。

實現自動化運維的***件事就是配置管理。對于服務樹來說我們要解決什么問題呢？一是服務的組織架構的問題，因為我們所有的服務是要有它的依賴，我們要知道它在哪里用，誰在用，可能有什么用。二是我們所有的技術管理，對大公司或者京東這種體量的公司來說，機器的量是在十萬，十萬量級如何知道一臺機器在當前是怎么樣的狀態(tài)？怎么用？我們需要很多組織。三是角色管理與基于角色的權限控制。還有其他的大數據，比如機型、在哪個機房、當前是什么狀態(tài)。最主要的東西其實在于我們的服務在系統(tǒng)中是同步的，我們知道這個服務在哪個機器上，有哪些實例，屬于哪個APP，中間的邏輯過程又是什么樣，對外提供服務的時候，它怎么樣告訴別人我需要什么樣的權限，以及我需要什么樣的監(jiān)控。我們所有的東西都是構建在服務器上。

Naming Service是解決服務之間的解耦關系和服務關聯關系，還有服務對外提供的窗口。右邊的圖展示服務樹與名字服務示意圖，***層展示了從應用到實例關系的解耦，這里面還有它的客戶端需要的。最主要的文件就是任務調度，不管做什么事情，比如我們一起做一個操作或者做上線、部署或者文件分發(fā)，這些系統(tǒng)都需要調度目標機器做相應的事情，也就是說需要對指定的機器按照指定的策略做指定的命令，這個過程其實是需要比較大的挑戰(zhàn)。因為這是實時的，同時又是大批量的，又是同時存在的，所以它需要比較好的系統(tǒng)支撐，同樣能批量使用。還有策略，你需要什么樣的并發(fā)度，比如我需要一百個機器，一百個機器都不一定是同時的。最簡單的就是上線，我不會把一百個機器都上線，可能一批一批，這屬于并發(fā)，以及每次并發(fā)是怎么做的。我做上線或者做任務調度，我當前需要做幾個，成功還是失敗，如果成功或者失敗，下面的邏輯是什么樣的，以及我做到什么程度業(yè)務算是成功或者超時。因為這個底層架構上，它構建了很多業(yè)務，它的調度邏輯是一樣的。

同時所有的執(zhí)行需要可追訴，即需要知道什么人什么時候做什么操作，這對安全性或者規(guī)范性來講是非常重要的。而且單機輸出怎么樣，我需要定位什么問題，如果出現故障，這是任務調度系統(tǒng)，這個基礎上可以做很多事。調度的邏輯則是基于服務樹和Naming Service。

第三個是做監(jiān)控，監(jiān)控無非是從數據采集到數據的匯聚到存儲處理的過程。這里面有一個很重要的概念是監(jiān)控的數據層，不同于我們平時見的，它是時序性的。這里面需要構建時序存儲。意思是收集的監(jiān)控點存儲起來，同時我們需要每次查詢，要查詢大量的、很多的數據點。還有很重要的是“讀少寫多”的過程，而且它的“寫”（寫入數據）相對比較均衡，而“讀”（讀取數據）是有突發(fā)性的。比如看一個監(jiān)控，或者看監(jiān)控狀態(tài)，是隨時做的。寫是10秒或者1秒或者1分鐘做采集，它是寫比較頻發(fā)的過程，讀比較突兀的過程，所以需要做讀寫分離。

我們基于ES做了TSPD，封裝兩個東西，一個是對熱點數據，比較重要的數據或者實時的數據存在redis，對這種歷史數據會有ES，然后再封裝，從而做到這種所謂的讀寫分離。我們的數據是雙寫的過程，保證數據的高可用。自動抽樣，監(jiān)控數據還有一個特點，有時候查他是頻發(fā)，但是查詢會有很大的跨度，比如一年的跨度或者一個月的跨度，因為我們采集的數據點是10秒或者1秒或者1分鐘，如果查一個月或者一年甚至更長時間，我肯定不會把所有數據點查出來，如果都查出來，這個查詢數據量太龐大，不易實現。所以我們寫的時候就自動做了抽樣，我們查15天以上的數據，把這些數據點會每分鐘或者每小時做聚合，然后再放在里面，再查一個月的數據，通過自適應的路由，可以查到一小時的數據，這樣檢測有限，你的數據庫或者業(yè)務系統(tǒng)速度就會比較快。第二是我們的數據實時處理，這里面比較重要的特性是多級化部署，是基于JNS調度的過程，就是我們講的多維度實時計算。

以上這些技術組件還有客戶端，所有的業(yè)務都需要客戶端，對于京東這種體量的公司來說，我們的監(jiān)控、初始化等都是全網部署。大家想象一下，十萬量機器加載的部署，如果每次的升級或者每次的上線都需要操作這十幾萬臺機器，這個事情簡直是不可想象的事情。還有另外一個問題，如果是維護十幾萬機器的Agent，環(huán)境比較復雜，多個IP，什么時候出現什么問題沒有辦法處理，按照單一維度處理，這個東西就沒有辦法做了。Agent有一個很重要的事就是資源超限，比如監(jiān)控Agent，它做了一些計算，把當前的計算打死了，而監(jiān)控又是服務外的東西，這時候因為監(jiān)控這個事情影響了本身服務的穩(wěn)定，這也是有可能的。Agent做的事情，一是我們負責所有的Agent的部署和升級。第二個事情是維護這些Agent的存活，它掛的時候我知道哪臺機器上的Agent什么時候掛了，我需要做什么動作把它拉起來。第三個是資源超限守護。四則是分級發(fā)布，講一下它的實現。我們裝技術的時候會把Agent裝起來，一臺機器進入一個服務，管理的Agent會在我們的服務器注冊，告訴它當前在某個分機房，某個Agent的版本是什么樣的，這樣他自然就會知道：你在加入服務的時候，它知道你屬于哪個機房、屬于哪個服務，我就告訴你Agent期望的版本是什么樣的。這時候他自然把包下下來，這時候你的Agent就知道***的版本是什么，這時候我們就可以實現個過程。這是另外一個客戶端體系。

我們構建完這些客戶端體系或者組件，再構建我們的部署和發(fā)布任務就比較簡單。大概介紹一下我們應用的部署系統(tǒng)，應用的部署系統(tǒng)不單單只是做應用部署，也做了一些服務的維護和資源的管理，甚至還有接入的過程。我們做了幾個事情：一是往前做了編譯構建，往后做了瀏覽接入。這個Agent有一個核心的訴求，是需要跨平臺。京東面臨的環(huán)境比較復雜，我們有虛機、Docker、物理機，那我們的調度需要支持所謂的物理機和虛擬機和Docker。第二個是我們需要把之前說的很多操作融合到一起，同時我們能夠做到容錯，這里面是不允許一臺或者單臺出現故障，從而引起服務故障，同時這些服務有問題的時候，他們自發(fā)現。而且京東很重要的場景是促銷，比如雙十一。你能快速擴容，從而能夠去應對這種比較大的流量高峰或者下降。

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

部署分兩種，一是所謂的基于Docker的鏡像輸出，二是基于傳統(tǒng)部署的物理機或者虛機的包輸出。從編譯構建到自身做的產品庫，這里面有代碼包和代碼項，通過部署服務和構建剛才調度系統(tǒng)上的部署服務做發(fā)布，然后在物理機和容器上都可以做。部署完之后是運行，維護運行之后，尤其對鏡像日志需要收集起來，然后做分析，做了日志服務。前臺做流量接入，中間做了一個LB網絡，最主要的一個點是這個部署分兩種，根據你的服務需要做它事實的升級。這里面所有的服務又是基于服務，它其實不需要關心當前的服務是怎么樣的過程，以及它這個過程是怎樣實現的，因為我們只需要當前需要什么東西以及容量是什么樣，以及我們給你分配了什么樣的資源。

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

講完部署講一下監(jiān)控系統(tǒng)，監(jiān)控最主要大家比較明白，剛才我們的例子，大家迫切需求是恢復：什么時候恢復？***個事情要做的是什么時候發(fā)現，即能夠在***時間發(fā)現問題，這是恢復很重要的一套。第二個是能怎么樣快速定位這個問題，然后知道在哪里。第三步我們能夠去自動調度一些或者提前準備好的預案或者自動準備一些之前所謂通過的算法，然后把這個故障給它自動調度恢復或者人工能夠快速出一些預案。他面臨的環(huán)境應該說是一樣的，它是比較復雜的環(huán)境，需要面臨虛機、Docker，最主要的事情是需要部署聯動，我們在上線過程中，有些東西是分級發(fā)布的，對于分級發(fā)布的過程中，不能停服。

其實這些故障本身又是一個事件，你怎么把這個事件存儲起來，以及方便查詢，從而提供給別人決策的依據。上一個事件影響下一步，你有很好的事件庫，讓上游知道下游什么時候出現故障，這對監(jiān)控很有幫助。然后做離線處理，得到比較好的辦法，反過來反饋計算和報警。

我們能有什么樣的數據展示，可能需要趨勢圖或者儀表盤或者Dashbord，這是我們需要研究的。這些事件或者報警或者上線有什么比較好的方式展現給外部看，這也是很重要的。我們采集，從Agent采集到自定義的日志，以及日志的外部、外網在全國的CDN的點接受探測，這些方式從而決定我們上層構建起很多的監(jiān)控模式在。

在這個基礎上我們構建了京東云監(jiān)控體系，我們把監(jiān)控分為四個層次，或者說四個類型：一是基礎監(jiān)控，就是我們所謂的機器層面，CPU、內存、磁盤等，比較簡單，不需要用戶去配置的，它會自采集。在機器上，機器是好的時候就解決服務的監(jiān)控，這個解決方案比較多一些，大家做得比較多。第二個是怎么解決服務的監(jiān)控，我們需要存活監(jiān)控，比如進程和端口監(jiān)控，還有語義監(jiān)控。

存活監(jiān)控基礎上就是服務層面對外的表現是什么，我們的四大核心指標，解決服務性能或者有異常，確定所謂的邊境問題，這里面通過日志來解決性能的監(jiān)控。再類似黑盒，從用戶側看服務，發(fā)現問題。從用戶的角度，因為很多時候我們看服務是好的，但是服務對外表現不好。很簡單的例子，所有服務指標OK，但是網站不能訪問，這是一個問題，對京東來說這是非常嚴重的，這時候最終你會發(fā)現你的流量在掉，或者你的訂單在掉，這也是很嚴重的問題，就是說我們從業(yè)務的角度，從用戶層面做黑盒的檢測。技術監(jiān)控的機器，從采集到計算到報警到機器連通性都是自動的，這些是不需要用戶做任何事情的，就可以把這些東西采集。這些報警會給一些默認，比如我大概發(fā)現一臺機器cpu.idle小于10%，我們看它屬于哪個服務，從服務知道這個是誰維護，誰維護就知道給誰報警，給誰報警之后，我大概需要做什么樣的數據。我們做這個聯動。上線過程中，這個機器的報警需要做什么評比，這是技術層面的。存活監(jiān)控主要是看基礎日志是不是存活，當前的技術消耗是什么樣。再就是看端口是不是OK的。

性能監(jiān)控方面，主要關注服務對外的指標，這個指標怎么來的呢？一般是日志。這個格式比較統(tǒng)一，我們去規(guī)定和規(guī)范或者約定一個所謂的日志格式，這時候很容易把這些值分出來，其實本身是多維度的，可以發(fā)現京東的流量是平穩(wěn)的過程，但是底下可能比較波動，我們可能發(fā)現總體流量平衡，但是某個時段，比如山東聯通的流量不OK，多維度的聚合你可能發(fā)現這些所謂比較細微的問題。這個采集方式是從日志里抓，還有一種方式是存續(xù)或者用戶自己對我們暴露，然后通過一些方式把這些值輸出出來。

業(yè)務監(jiān)控，從用戶側看服務是否OK，用戶側看服務最主要，能模擬全國各地用戶做訪問，發(fā)現非運營商或者分機房訪問的情況，這是用外網或者自定義的方式，我們用各種方式模擬云操作，監(jiān)控云，模擬一個用戶登錄監(jiān)控云網站，然后購買一個主機，部署一個鏡像，然后做一個發(fā)布，這些過程都是OK的，如果監(jiān)控層OK，理論上用戶也是OK，從用戶的角度可以發(fā)現一些問題，先于用戶發(fā)現問題很重要，先于他發(fā)現，就可以提前處理，這就不是故障，只是小case。

總結一下，我們做京東的監(jiān)控自動化的平臺，接下來是將技術實現服務化，做全生命周期的DevOps，尤其我們有這么多的SaaS客戶，幫他們保證效率，節(jié)約成本，提供解決方案，幫助用戶解決問題。

謝謝！

————————

以上是51CTO.com記者從一線為您帶來的精彩報道。后續(xù)我們還有更加精彩的獨家報道，敬請關注。