京東無線服務端

首先，在大會上統計一下資料，不知道多少人的手機上安裝了京東手機APP，從舉手的比例來看，大家也能猜到。就像這個圖畫的一樣，京東無線服務端的流量像這個瀑布一樣，洶湧不絕。服務端就是APP後端默默支援它的親密愛人，你可以使勁地消費，你可以隨便地購買，我來承擔你給我帶來的流量。

這是我們服務端的一個進化歷程，其實它也是隨著我們京東無線整個業務在進化。我一直在強調，所謂技術驅動公司——這個詞不能曲解——實際上是靠技術去輔助業務來演進的公司，京東作為電商，一個自營電商，它就是這種技術驅動的公司。

2011年2月，京東開始做無線。第一版蘋果的客戶端上線，從那時起，京東無線服務端的親密愛人出現了，默默背後支援著。

2012年業務經歷了小高峰。這個達成從2011年開始了，1月份應該是微信第一版也上線了。京東當時已經在PC端取得了比較大的進步，所以無線端我們是吃了一個紅利，隨著整個京東平臺業務在不斷的發展，無線端的業務也在發展。這時候原有初始架構的問題暴露出來了。我們一直撐著，一直到2013年這個矛盾非常突出的時候，進行了第一次的架構升級。這次架構升級的變化還是非常大的，用一句話來概括，這次架構升級，即大家通常說的SOA體系架構，讓我們進入了一個服務化的時代，京東從2013年年初進入了這個時代。

2014年是無線發展非常迅猛的一年。當時無線網際網路的大潮大局已定，大家都有一個共識，無線網際網路應該是未來，在京東無論高層還是基層，對這個都有一致的認知，而且我們的很多資源也都在向無線端傾斜。

到了2015年，無線端通過多年的打磨，技術已經有了一定的積累，業務也比較平穩，比較成熟了，這時候我們開始思考無線端做成什麼樣，無線服務端做成什麼樣。經過了這麼多年的積累，大家最後得出的一個結論就是，我們不能做一個系統，也不是一堆系統的集合，我們要做的應該是一個智慧的生態。後面我會給大家詳細地講一下，我們如何來支撐這個生態。

京東無線服務端架構變遷

現在我們來看看京東服務端架構變遷，可分為初始架構、服務化架構、質能生態三個階段。

關於初始架構，我對它的評價就是為了追趕PC股權業務，當時還是PC流量為王，為了把京東整個業務都給補全，把PC端能趕上它，把它的業務都能補上。第二階段是，服務化架構，我們完成業務上的拆分，我們要服務化，因為業務的不斷演進、流量的不斷增加，帶來必須要有這種變革。第三個階段，當然它不是最後的階段，現在我們一直在為之努力的，而且我認為已經初步達到的一個階段，就是智慧生態。大家看一下這個質，沒有寫錯，就是質量的質，我們要為我們的使用者提供一個全方位的、高質量的服務。這階段的主題是，工匠之心不斷打磨，技術趨於成熟的時候，不斷演進我們的細節，一顆工匠之心對我們來講是非常重要的。

初始架構

我們大致來看一下初始架構。其實任何一個架構，包括任何一件事，都有它形成的一個背景。2011年京東無線端初始架構的背景什麼樣呢？第一，無線網際網路熱潮已經興起了，但是2011年，大家都在說無線網際網路是未來，有可能它很牛，但是誰又能確定未來到底能不能取得成功呢？雖然京東在2011年的時候已經很強大了，但是它也是抱著一個試水的態度涉足無線。我們在無線端嘗試做京東商城的APP，通過手機購物帶來多少的流量，給使用者解決什麼樣的問題。

還有一個背景。京東作為全國最大的自營電商，它的業務非常複雜，因為大家知道，我們大部分的商品是自買自賣。所以就像一個開商店的，為了讓使用者在這兒得到更好的體驗，我們的採銷、市場想出非常多的花樣，讓使用者能得到實惠，又能有良好的購物體驗，而且把這個東西能賣出去，大家能雙贏。另外，提交結算的時候還有很多滿減，購物車各種玩法，這些是特別複雜的。

基於這樣一個背景，我們無線網際網路及試水，業務比較複雜、比較多。所以第一版架構基本遵循了三個原則。第一，優先解決有無，開始的架構都是第一解決零和一的問題。第二，瞄準PC，把業務給股權，不可能說手機端，人家在PC端享受到的東西手機端不讓玩兒，那更談不上發展了。第三，快速響應產品的需求，產品指導研發，很多場景、很多的玩法必須幫助產品實現，而且速度要非常快，要快速迭代。當時整個無線端抱著一種創業的態度做這件事情。

後兩個原則可以合到一塊，因為它們有很大的關係，小團隊開發快速部署。2011年的時候，京東的無線服務端只有三個研發，大家可能想不到當時京東的業務已經非常完備了，現在的研發只有三個，確實是這樣的。所以我們要求在小團隊的規模下可以部署得非常迅速，可以開發迭代得非常快，這就是我們遵循的幾大原則。

總結一句，初始的架構就是一個簡單的Web系統。中間的負載均衡沒有畫，業務系統通過程式碼模組的形式組織各種業務就是一個簡單的Web系統，後面掛了資料庫，比如交易、價格、庫存、使用者，等等。可以看到，我們這個基礎的架構，內網的互動協議當時還是非常複雜的，我們有各種協議，也沒有統一，對外就是HTTP。當時的管理系統其實是通過一個快取跟業務系統互動的，這種方法回過頭來看非常low。當時三個人的小團隊開發各種業務，我們考慮只能用最簡單、最粗暴的方式實現，能快速地股權業務。當時的流量真的不是第一重要的問題，也不是最主要的矛盾。

對於初創階段，我總結了三點。第一，業務一直就是架構變遷的驅動力，不可能脫離業務去談技術。第二，成熟簡單的技術就是最合適的，這個理念一直貫穿始終。我經常跟我的團隊說，不要把事情複雜的形態呈現給我，我的腦子非常簡單，想不了那麼複雜的事兒。第三，不要過分追求架構。大家看到初始的架構等於沒有架構，但是這種形式在這時是最符合業務需求的一個，能快速迭代，能非常方便上線，而且人員這麼少，能Hold住這個系統。

只說了初始架構的優點，其實還有很多的問題，所以到了流量越來越高的時候，就沒有辦法解決了，只能進行架構升級。但是更情願這個老架構的光榮退休。

服務化的架構

下面看看第二階段，服務化的架構。

2012年業務有一個小的增長，它帶來了流量的增長。當時每天的日均介面訪問速度突破了八千萬，合併了很多介面以後，這個量其實在當時就已經不低了。到了當年6月18日，已經破億了。這點對於我們來說變化真的非常大。我剛進無線的時候，如果訂單上了一千都要吃飯慶祝一下，但是現在訪問次數已經突破了這麼多。無線端要發力了，我們要去股權我們的業務了，領導已經認識到無線端的重要性了，所以我們要擴大我們的團隊。

我記得2012年的時候，無線端人員增長非常快，突然三個人變成無線端的老員工了，來了很多實習生還有社招引進的一些人才，他們組成了整個無線服務端，這會兒我們就要協同作戰了。也就是說，我們把人分成若干個組，去開發不同的業務線條。因為隨著業務的增長，提出的業務需求變更越來越多，可能一個小團隊響應不過來了，人員要分開，一些去做庫存，一些去做購物車，還有一個團隊專門負責商品。我們的業務線劃分從團隊劃分開始，並不是從系統開始。

還有一個大的背景。整個京東都在升級，從.NET升級到Java了。我們很早就已經在Java架構上摸爬滾打了，從2010年、2009年京東開始Java架構了。底層很多基礎服務的架構有了非常大的改進，互動協議不斷統一。

我們看一看，初始架構面臨了一些問題。開始第一業務團隊分離，系統並沒有分離。比如這樣一個例子，做商品的，今天有十個需求要上線，做購物車的有五個，結果做商品晚上五點開發完了，做購物車的到八點還沒有做，今晚要上線，做商品的等著購物車，兩個團隊都等著，最終一塊上線。還有就是做庫存的把基礎的服務類給改了，做商品提交程式碼的時候忘了，出現了衝突這怎麼辦？團隊擴大了，系統沒有隔離造成了開發上的問題。還有單一系統的流量，其實這個時候流量已經開始是問題了，我們希望能夠隨機地調配流量。最簡單的，業務上提了一個新的需求，我希望北京的使用者可以提前兩天能看到這個，我希望把北京的IP切到單獨的業務叢集上，它有新的功能，而其他在老的業務叢集上。這會兒給我們提出極大的挑戰，沒有辦法，只能找運維，告訴他，我要在負載均衡這塊去切，但是危險性非常大了。

我們經常說的系統肥胖病出現了。京東的業務非常複雜，是一個非常完整的自營體系的購物流程，整個流程做下來，程式碼量非常大。當時一個服務端的程式碼，涉及的人很多，很多人程式碼寫得不一樣，又缺少非常良好的程式碼管理，於是帶來了程式碼質量問題。我記得當時一個純程式碼包幾十兆，加上它依賴的庫，體量非常大，每次上線讓人心驚膽戰，往伺服器傳都是一個問題。

所以基於這些問題，服務化架構開始了。其實就是拆字決，大部分的公司遵循這種理念。系統越來越大，我們從兩方面開始拆。第一，縱向的分層，獨立出API閘道器，很多業務面臨這種問題的時候也是這樣，而且我在閘道器可以做很多的公共策略，比如，安全策略、公用策略等，都可以做在API閘道器，它的特點就是它可以理論上進行擴充套件的，它和記憶體有關。第二，做業務的拆分，這個是非常重要的，把業務給梳理了，給它拆成幾大業務線條獨立的部署，也就是我們說的服務化的架構，商品獨立成商品系統，購物車一系列的介面都從這兒出，專門的團隊運維它，去研發。這樣大家的職責非常明確了，也不會有衝突，購物車想第二天凌晨上線都沒有問題，商品可能頭天晚上5點多上完線了。

大家看一下，這是比較簡單的，描述了一下當時的服務化架構、API閘道器，我們通過一個HTTP協議，為什麼中間沒有自有的協議呢？我們開始服務化架構剛剛形成的時候，內部自有框架沒有那麼成熟，而且不斷響應業務的變化，抽調出來做服務化改進的人非常少，我們只能是遵從原來一直在說的簡單實用、能把控的一個技術，對我們來說是最合適的。所以我們還是採取了HTTP協議，我們把當時的Apache httpclient 升級了一下，到了四點幾的版本。

大家知道，它有一個池化的功能，高併發下比較強的機制影響它的效能，基於這個，我們自己實現了一個連線池，可以把這個HTTP連線複用，這樣對效能有比較大的提升。我們把配置管理整個升級了，現在看到的所謂的非同步配置管理是推拉結合的，早期做了非同步的版本，有一個嚴格的版本管理功能，拉取我們的配置。後來我們又上了一版來實時的推送我們的配置，這個配置管理系統是非常重要的。我知道，線上電商流量來的時候誰都擋不住，我們可做一些有損或者無損的降級，這種降級依賴很多配置的下發，一個開關，任何一個對資源類呼叫，我們抽象的，對後端服務介面的呼叫，嚴格規定對任何資源類呼叫必須要有開關，這個是不能妥協的。我們開關可以冗餘，但是沒有的時候關不掉，眼看著後端某一個服務把你拖死的時候很可怕了，我們改造了這個配置管理系統。

大家還可以看到，我在這裡特意突出了快取叢集123，原來在初始架構的時候，所有的業務都用一個快取的叢集，我們用的是memcached，它的記憶體管理機制會導致一個問題，如果k-v鍵值對大小非常不一致，非常散的話，這個利用率非常成問題。基於這個，把所有應用而不是按應用來劃分這個快取，而是按應用的特點，來劃分這個快取，而且秉承最重要的理念，快取如果沒有特殊需求，我們要求小對多部署，一個片不能分得過大，如果流量來了，這個承受能力是不一樣的。

總結一下，對於這個服務化架構的階段有幾點心得，可能是基於我們一些積累。第一，不要為了拆分而拆分。在開始的時候一個系統其實完全響應了我們的業務需求，在不同階段需要做不同的事，如果沒有必要去拆分這個東西，我也不會選擇這個。我去過一些朋友的公司或者一些小公司，大家跟我談這些，我們需要拆成多少個服務，我說你的業務量沒有達到這個量級，你的流量、你服務之間的矛盾不是主要矛盾的時候，你沒有必要去拆。因為大家知道，拆了以後，每個叢集都要做冗災，叢集之間的互動，這些也是成本，都要考慮到。

適當的冗餘，其實可以把這一條跟第四條結合一下，在一個服務化的架構來看，我們最頭疼的是服務的治理，它之間呼叫關係的治理是非常難的。在起初吃到了很多虧，我們很多橫向的呼叫，我們內部在使用者這一塊，我要展示使用者買過哪些商品，開發商品業務的同事會說，我們能不能調內部的，跟他們溝通比較困難，沒知會的你的情況下橫向調，後來梳理的時候發現服務之間的呼叫就像一個蜘蛛網，大家已經沒有辦法去理清你調了誰，誰又調了你，這種對我們的傷害是非常大的。很難確定你的上游，你上游的上游是誰，可能就成為一個最脆弱的階段，你掛了，可能這個環中所有的人都掛了，呼叫關係的梳理是非常重要的。

質能生態

接下來說說質能生態，這可能是我們要著力去講的。前兩個內容大致講了一下，大家大致上能猜得出來高併發的後臺系統，它的演進過程是什麼。我沒有刻意地跟大家突出流量達到多少了，才去做，因為沒有一個現實的標準。大家可以根據自己的情況去定，哪個矛盾是最突出的，根據這個矛盾，要想一個什麼策略，再去決定自己的系統架構什麼樣的。架構沒有絕對。所謂系統架構就是一個權衡，如果你覺得這個是最主要的矛盾，OK，需要我改就改，這就是一個架構。

質能生態的背景是這樣的。京東已經進入了完全的無線化，從2015年Q4，京東無線整個訂單量完全超越了，非常迅猛的一個速度，我們對外發布的是220%的增長。大家可以想象，無線業務的發展，從原來基礎的電商能力，比如說一個黃金的購物流程，首頁、商品、購物車下單到結算，從基礎的購物流程，京東其他的一些電商能力，我們也要開放，不光侷限於讓使用者購買，可能其他一些大家印象非常深刻的倉配的能力、物流的能力，可能後面都需要去開放，我們怎麼去開放這個東西。

無線服務端作為京東第一個去試水無線的，其實非常明顯在這個中間起到的作用，我們是探路者，我們肩負著一個重要的職責，我們積累的這些知識、這些經驗，我們希望把現有的京東無線服務端形成一個體系，打造一個服務的質能生態。

現在簡單解釋一下質能生態。其實質能是許總最早提出來，秉承了京東一直強調的“客戶為先”的理念，給客戶提供的服務應該是高質量的。從我一個技術人出身，我希望每臺機器，我的服務達到幾個九，但是從使用者的角度，能不能順利地購物，響應時間是多少，會不會經常提出網路開小差了，這是對我們基本的要求，是我們要貫穿始終的。

還有就是生態。這個詞看著是炒概念，但確實經過我們這麼多年的積累，京東無線服務端發展了五年，才走到了QCon這個講臺上給大家分享一些我們的心得。我覺得我們原來還只是在做一個系統，或者說的大一點系統的集合。回過頭來看的時候，當我站在使用者的角度看，站在我同行、同事、市場採銷同事的角度去看這個問題，我發現我們應該建造一個生態，是一個能讓我們所有的服務非常安全的一個環境。我總結了這樣一個生態：它應該接入友好，監控應該非常到位，變更應該非常方便，資料應該非常完備。

我更喜歡把生態比喻成學校，我們開始就是在建立這麼一所學校。

我覺得有三大利器，可以用來打造京東服務端的質能生態。第一，團隊。第二，技術的支撐。第三，流程上的保證。人、技術還有規則，我們都要有。

團隊

首先，重點給大家講一下我們團隊。我們無線服務端是非常小的團隊，我們在業務快速迭代的過程中沒有很多的精力重視技術、程式碼的質量、架構是什麼樣的，我們要用哪些先進的技術，但隨著流量越來越大，業務發展越來越快，系統越來越複雜，我要求我們團隊越來越應該具備一顆工匠的心。

有三個非常簡單的要求，不是全部，我列舉了一下。

第一，基本功一定要紮實。你可以不知道框架，但是不能不精通資料結構，因為我們用的是Java。大家應該有一個共識，現在在市場上招聘，你能招到程式設計師，80%都會跟你說，哪些框架用得非常好。但事實上在我們面試的時候，很少考這些東西，基本不會問，你用過哪些框架，希望你對基本的演算法資料結構能夠做到非常熟練，我都不求精通，但是一定要非常熟練。我認為這是一個程式設計師的靈魂，應該是一個基本素養。

第二，對自己的程式碼要有工匠之心，追求質量的極致。這可能是非常冠冕堂皇的話，但是確實需要這麼做。我們的系統非常複雜，現在無線端後端光業務系統接入了好幾十個，不下50個業務系統，這些系統需要怎麼對待你的程式碼，態度是非常重要的。

第三，對開源專案要有鑽研探索的精神，我要求團隊對引入的任何一個開源的專案、開源的包、原始碼，都有極致的瞭解，包括現在用的ZK、Netty，Apache其他的專案，我們引進的時候有嚴格的技術評審，到底能給我們帶來什麼收益，給我們帶來什麼不利的問題。因為任何一個東西，尤其是技術，都是雙刃劍，能解決一些問題，但勢必會帶來一些問題。

比如，最初我們的架構，不能說它不好，它是非常優秀的框架，但是隨著發展不再適合我們，我們毅然地去掉了它。為什麼？幾次在爆出它的漏洞、它的效能問題，我們經過橫向對比。所以我要求對原始碼、框架都要有非常細緻的研究，才能去使用它。否則它放在一個要求365×24小時不宕機複雜的線上交易系統中，實在不敢說，哪天宕機，一幫工程師在那兒要研究幾個小時。可能幾分鐘的宕機帶來的經濟上的損失都是非常巨大的。

我一直在強調，我們不能站在工程師的角度去考慮問題，尤其是你的系統在演進，相信各位開發人員的能力也是不斷在打怪升級，不斷往上走。所以我認為我們的視角一定不能只侷限於在工程師的視角考慮問題，不要為了技術而技術。我的團隊經常跟我說，我們是不是要用這個東西，這個東西非常牛，是哪個公司推出的，它會給我們帶來什麼。事實上我基本上持否定的，持非常審慎的目光看待這件事，因為最先進的高精尖的技術不一定肯定能解決你的問題，反而帶來使用上的成本。

團隊目標一定要一致，要具有戰鬥精神，這是團隊理念問題。我認為一個團隊最重要的是目標的一致，如果目標不統一很難做成一件事。現在我們團隊一直灌輸的目標就是，我們的系統一定要是可持續運營的。這個概念非常重要。一個可持續運營的系統，它不是快，不是技術有多高精尖，不是有多先進，我們要求的系統目標是可持續的運營，我能非常好地監控它，可監控、可控制、可擴充套件，這就是一個可持續運營的系統。

戰鬥精神有多重要呢？精神食糧有時候非常重要。我們迭代的次數非常頻繁，京東的迭代，一週標準是兩次，但是我們的業務非常多，可能一週至少兩次，也可能每天都在釋出，每週又各種促銷活動，大家經常去買一些現在有的超級品牌日。第一期，我記得好像是樂視，我不知道大家有沒有買過樂視的電視。還有五糧液超級品牌日，基本上每天都有促銷。還有一元秒殺，大家都感覺秒不上，確實秒的人太多了，我也沒有秒上。這說明我們的業務都有非常多的玩法。

現在我們團隊的工作是刀尖上的舞者。這種工作有很多形容：我們在給高速行駛的列車換輪子，我們在懸崖邊跳舞。我用一個非常高大上的詞，我們是刀尖上的舞者。我們既要保證海量訪問的系統，它能正常地為使用者提供服務，讓使用者無感知，保質保量，而且我們需要把非常複雜、非常多變的業務迭代上線。

技術支撐

第二點，我覺得除團隊外，我們的技術是非常重要的，即技術支撐。作為電商公司不可能不談技術。

首先，我一直在強調大到至簡，一個簡單的系統。任何系統能夠做複雜太容易，如果把複雜的系統做簡單，把複雜的業務用非常簡單的系統展示出來，這真的需要功底。我對這個的理解是，技術選型不刻意追求高精尖，本著夠用、合適的架構儘量簡單，它很穩定不需要用很多的時間來開發、研究，但是它一直承擔流量，能承擔到幾十億級的流量，也可以用為數不多的伺服器看你的流量。

其次，架構設計要簡單，權衡才是架構的本質。我很少談架構，架構不斷在演進，到了這個地步了，我需要這麼去做，到了另一個地步，又需要這麼去做，不斷解決問題。當我回過頭來發現，原來我們這樣是合理的，已經演進成這個樣子了。在演進的過程中，我們可能把不合理的東西去掉了，或者我們認為失敗踩過的坑，我們都給忽略掉了，最後能跟大家講這個架構，其實過程中還是很辛酸的。不要為了設計模式而設計模式，也不要為了模式犧牲可讀性。不要過於追求設計模式，那些設計模式往往造成一個程式碼的可讀。我們對一個模式認知的不同，大家互動語言不同，跟一個坦尚尼亞人說漢語肯定不懂。所以我很少讓大家說，你必須用什麼設計模式。

我們需要學會把一個問題簡化，提煉出來，這才是我們架構的本質。

可擴充套件，架構靈活的可擴充套件。比如，現在這個服務化的架構，說實話沒有想過再去做一個更深入的服務化，我覺得它現在能達到我的一個要求。它可以橫向擴充套件，我現在先要上一個業務直接上一個服務，從API閘道器接入，就沒有問題了，我能很好地支撐這個業務。還有就是快速搭建服務，最簡單的，我們有很多的模板，我們可以快速的生成一個工程，還有程式碼生成的工具，可以把公用的模板程式碼快速的生成，這只是其中的小工具。服務化架構最重要的就是接入要方便，接入方便最基本的就是協議要統一。統一併不代表單一協議，我們需要支援幾種比較主流的協議，如 HTTP、JSF、SAF。

這個協議說的是對外協議。我們的API閘道器是對外統一的互動協議，移動端是一個過敏體質，大家一定要記住，它非常敏感，對流量敏感、對資費敏感、對使用者資訊保安也非常敏感。大家經常說你們這客戶端特別費流量，那個客戶端特別省流量，尤其在你用自己3G、4G的時候，這都是銀子。對協議的要求，使用者感知的速度，大家最直觀的，我在2G網路下訪問京東購物能不能購物，在3G、4G訪問什麼樣的體驗，在Wifi訪問是什麼樣的體驗，這個要求一定要流暢。對外互動協議有沒有改進？其實並不是說對技術非常保守，我們只是要把一個技術用得非常成熟可以拿出來給大家用，不去誤導大家。現在其實在用的跟客戶端的互動還是HTTP 1.1，正在實施的是 HTTP 2.0。大家都是做網際網路的，都有一個共識，一個是安全性，一個是在全站支援SSL的情況下，希望連結可複用的，而且現在spdy也在併入HTTP 2.0，我們想直接邁到這一步。

技術支撐最重要的一個就是基礎的元件。我列舉一下，類似於JimDB，基於Redis的快取、持久化功能強大、完善的操作管理平臺。還有ZK Cloud、Hermes、UDP，內部的資料收集如果沒有非常強的精確性要求，我們內部的資料收集基本上都是走UDP，在內網UDP丟包率非常低，而且保證程式的效能。HttpDNS的目的是為了解決域名劫持的問題，現在更加發現，其實它能讓流量排程功能更靠前，在前端進行非常好的流量監督。還有JvmDebuger，大家可以看看這些系統的截圖。

(點選放大影象)

比如，這是ZK的管理工具、資料平臺，可以實時配置，可以把資料展示在你面前。

(點選放大影象)

還有非常重要的是監控。我覺得監控對於網際網路公司太重要了，基本是各個層面從作業系統到應用都是有監控的，而且我們的理念可以冗餘，但不能沒有，一個層面可以有多個監控。現在每個業務團隊自己都開發很多的監控，但絕對不能冗餘，對監控系統有要求的，要求監控的系統必須要有一個統一的協議，要接入簡單，因為大家記住，我們要構建的是一個生態，這個生態裡，學生入學了，想去實驗室做實驗，想去衛生間、去食堂，不知道路怎麼走，不知道怎麼去，何談生態呢？

大家可以看看我們的監控，其中這是我們對於介面的監控，每天可能都能收到一些這樣的簡訊，它可以通過簡訊、咚咚、京東內部的聊天工具，還有微信、郵件的方式展示給我們，還有一個圖表，這個非常重要，可以看到流量的變化，能細化到介面甚至不同的版本，這是對HTTP連線池的平均，排隊數、空閒數。

(點選放大影象)

容災就是大致幾個套路，快機房、資料備份的能力、流量的隔離要有不同的流量入口，入口之間可以切換，這是網際網路冗災最基本的常識。資料非常重要，一切的監控系統很多元件依託於資料，我們收集了全量的資料，通過實時計算平臺，把這些資料變現，變成能對我們有利的一些圖表、一些監控、一些安防系統，它的基礎都是我們的資料。這個就是資料收集的一個過程，基本上通過UDP，我們有一個統一的UDP管理功能，通過介面來配置，這個資料定製到哪個系統，流程就是上線流程、釋出流程、基礎元件使用接入流程，來控制系統接入的風險。

流程保證

最後，基本上現在的流程都是通過工作流的過程，我們閘道器的接入流程審批，要把你的服務對外，走系統審批，要提交，而不是通過一個個郵件，這樣非常原始了，現在基本上70%的系統都是採用工作流接入的方式去審批，需要團隊的領導還有給你操作，比如說無線閘道器的審批，你的服務才能對外發布。而且我這裡沒有列舉，我們接入的元件基本要求必須有全方位的監控接入，才能使用。

這個就是接入我們的ZK管理，使用ZK Cloud實現一個系統提交，形成一個工作流程的審批。這就是對於質能生態大致概括的圖，我們有閘道器對外發布，我們的服務希望通過一個良好的協議上下非常好的互動，有很多的工具可以供你使用，可以有非常好的資料平臺，有非常好的協議跟你互動，底層支撐有非常好的運營，可以冗災、跨機房、資料備份。

(點選放大影象)

小結

總結一下，質量是我們永遠考慮的第一要素，質量是一個綜合體，我們說的速度、可用率都整合在這裡，生態化的理念還在延續打造這個生態。我要再次強調，高精尖真的不一定能解決問題，不是我保守，但是希望你們能好好去考慮一下你們選型，團隊風格非常重要，有風格的團隊我相信能做好很多事。