京東服務技術中臺：你必須知道的全流程建設方法論！
大家下午好，我是京東研發總監——賈樂。今天我分享的主題是京東服務技術中臺探索與實踐，分別從三個方面來講：
1、為何我們要做中臺？
2、京東服務技術中臺建設思路；
3、關於中臺建設的個人思考。
為何做中臺？答：拆掉煙囪
為什麼要做服務技術中臺呢？舉個例子，假設一個使用者在京東買了東西，但不滿意，希望退換貨。他會通過線上聊天、電話找到客服，客服會對其進行接待，並將使用者反映的問題記錄下來。最終京東官方會給出一個解決方案，可能是換貨、退貨或賠付；如果客戶是從京東平臺第三方商家買到的產品，那麼京東還需要從中立角度為他與商家執行仲裁。
所以，若想服務好顧客，我們會和許多部門打交道，包括物流、倉儲、維修等等，所以服務技術中臺是圍繞於人、財、物三者進行服務的。
就架構發展歷程來講，京東第一階段的應用結構都是單體應用，例如在物理機上部署一個 Nginx+Tomcat，要求非常簡單，就是快。那麼多時間做複雜的設計，簡單粗暴，一堆程式碼放上去能跑就可以了。當然，這種設計的缺點也非常明顯，就是運維成本非常高，沒有什麼災備部署，伺服器掛了就是掛了。
第二階段是“修身治國”，即當業務開始快速增長，我們對業務架構提出了更高的要求。在這種情況下，我們開始做業務的解耦和微服務化，將叢集部署在多個不同的 IDC，統一進行服務治理，包括建立了自動部署體系、統一的日誌體系、統一的監控體系等基本的運維設施。自此，運維工作具備了橫向擴充套件能力：日常運維基於容器，部署自動化，可以很方便的收集、分析、處理告警，同時具備了一定的平臺化和可配置能力。
看起來一切都已經很不錯，那為什麼還要做中臺呢？很多同學在另一個角度上提出了這種疑惑，即微服務化改造和中臺戰略到底有什麼區別？那麼接下來，我來講一講為何要做中臺，以及中臺和微服務有什麼不一樣。
從單一角度來看，第二階段確實沒有什麼明顯問題。但如果站高一點，站到整個公司的層面俯視，就會看到一堆“煙囪”，為什麼是一堆“煙囪” ？
首先我們會看到“產品煙囪”：不同的產品間，定位和功能雷同；
第二是“系統煙囪”，研發人員有一個特點：自己寫程式碼開發的系統才用著放心，別人的不願意用，所以總是重複開發；
第三是“資料煙囪”，在第二階段，各個系統產生的資料其實已經匯聚到大資料平臺。在一定程度上，資料不存在分別儲存的問題，但這依然存在一些問題：產品不同，因而資料計算邏輯和口徑是不同的，那麼很可能同一個資料指標有不同的計算邏輯和計算口徑去計算，導致難以合併分析；
最後就是“組織煙囪”，即“部門牆”，天然存在，存在即合理。可當“部門牆”太厚就形成了“組織煙囪”，導致資訊不透明。
以上就是第二階段存在的問題。
京東的解決思路是什麼？就是中臺戰略，兼濟天下，無論是產品還是工具，不能只為自己考慮，不管他人死活，中臺要賦能整個公司、社群、環境，產品的使用人數越多越能凸顯價值。
京東服務技術中臺建設思路
京東服務技術中臺經過檢驗建設，共分為三層：
平臺層：核心能力包括及時通訊平臺能力、音視訊能力，再加上業務引擎和基礎 SaaS 設施，這構成了我們的平臺層。
元件層：主要分為三個部分，第一部分是平臺外掛和中心化。對於相對通用、容易用配置實現的功能或規則，用平臺配置中心完成，使標準化需求可以得到快速滿足；第二部分是外掛裝配中心。如果一些需求無法標準化成配置，那麼我們允許第三方，可以定製化自己的外掛，插入我們的系統中，給使用者提供相應的功能服務。比如說常見的訂單外掛、商品外掛；最後一部分是個性化接入中心，部分業務邏輯、流程與中臺已有的非常不一樣，這種差異導致計劃配置也要差異化實現。這時候我們提供個性化接入，讓其可以變成做成標準化服務，接入整個服務網路裡面。
服務產品層：在前兩層之上，我們的產品體系最終得以構建，包括客服服務平臺、電話呼叫中心服務平臺、售後服務平臺等，在這一層對接、服務京東所有的業務領域。
服務技術中臺主要解決兩個問題：成本和速度。
“成本”這個詞非常好理解，繁多的職能和產品整合到了一起，人力成本首先得到了解決；“速度”，指的是交付速度，當新風口出現的時候，如果沒有中臺戰略良好的底層積累，產品質量沒有辦法保證。而對於中臺來說，新的產品可能只是換個殼。我們常說大中臺、小前臺，小前臺可以做得很快很輕，基於中臺的配置去完成。
所以，我們圍繞產品、系統、資料和組織來構建中臺架構。其中，組織其實是第一步工作，要把相同的產品、功能合併，再於產品之間進行整合，使之成為一個完整的個體，成為一箇中臺，去對外提供服務。
我稱這種整合為一種藝術，為什麼？第一，不同的“煙囪”確實代表業務需求不一樣，如果需求一致，不可能出現幾個煙囪；第二，業務方並不關心底層有幾套系統在做支撐，他們關注的是體驗和交付有沒有得到提升，但我們要得到業務方的支援。因為中颱建設其實需要投入大量的資源和人力，在這個過程中，一定程度上會減少支撐業務的技術人員數量，所以要和業務方提前達成一致。這就像要為高速賓士的賽車更換髮動機，簡單的系統一兩週就遷移完了，複雜的系統可能要半年、一年才能遷移完成。
這裡還需要解決一個基本問題：產品整合完之後，同一個中臺要支撐不同的業務線，不同的業務線又有不同的邏輯和流程、不同的業務量和資源需求，那麼第一步要做什麼？
就是用多租戶把整個業務線的配置、資源（計算資源、儲存資源）隔離開。不同產品的多租戶身份必須是統一的、唯一的，因為如果每個系統都去建立自己的多租戶，當兩者需要配合完成任務的時候，就會發生衝突。
在這個基礎上，我們要按照開放封閉原則去打造生態。開放封閉原則，大家一定不陌生，中臺內部有非常完善的體系，我們並不希望外部需求去影響中臺的發展。同時，為了實現這個目標，我們對外開放了足夠多的擴充套件，包括多租戶、帳戶認證、訂單介面等。
只要滿足我們的協議，能夠快速的進行配置，就完成了接入，速度非常快。同時產品和產品之間也是解耦的，包括 CM、工單和機器人。我們允許第三方接入，讓單一的產品也能和第三方配合起來，同時提供 PaaS、SaaS、私有云這三種模式來給集團賦能、外部賦能。
建設中臺的 3 問及 5 個必要條件
最後是我對服務技術中臺的一些思考。
首先建設中臺要問自己三個問題：
1、需要支撐多個不同的業務線嗎？
2、使用者來自不同的群體嗎？
3、存在重複建設嗎？
如果使用者和業務線相同，其實中臺在某種程度上是一個偽需求。
服務技術中臺建設的一些必要條件：
1、符合公司戰略發展方向；
2、領導層全力支援；
3、業務側的協同認可；
4、基礎設施能提供支撐；
5、基礎服務治理。
我在分享服務技術中臺的構建時，並沒有分享統一日誌、統一監控、分散式框架、叢集、容災等方面的內容，因為這些內容在第二階段就已經完成了。它們重不重要？非常重要，這是服務技術中臺建設的基礎。所以中臺建設的時機很重要，如果沒有這些基礎，沒有領導層支援，與公司戰略也不吻合，中臺建設就會非常吃力。
寫在最後
在我看來，建設服務技術中臺的最大挑戰，既不是技術，也不是基礎設施，而是組織和文化。
為什麼這麼說？前面我們提到很多“煙囪”，需要將他們進行合併，最簡單的方式就是將兩個部門合併、將相同的產品合併，這就涉及到組織架構調整，沒有高層支援是不可能的。
我之前遇到一個講師，他在深圳做整個公司的架構負責人。他說，公司內部另外一個業務部門做了和他們一樣的東西。這讓他非常困惑，想推廣本部門產品非常困難，推到做了“競品”的業務部門死活推不下去，這是非常現實的情況，也是沒有得到高層支援時，常見的情況。
另一個挑戰是文化，其實很多公司都在進行中臺建設，但是在建設過程當中會遇到很多文化挑戰。文化挑戰分兩種：第一種是供給者，第二種是需求者。
對於需求者來說，最大的挑戰是要克服“什麼都要我自己做”的心理。舉個例子，當產生了一個需求，最先想到的應該是，在公司內有無類似的產品是可以複用的，這時我們要有把自己的後背交給兄弟的決心，當別人的產品能夠部分滿足我們需求時，其實我們需要儘量的 push 他們，讓產品能夠儘量滿足我們的需求，而不是自己做。
對於供給者來說，最大的問題是工作和 KPI 是否能保持一致。如果只是滿足部門內需求就可以了，為什麼要把產品給整個公司使用呢？這其實是增加了該部門的運營負擔，但如果從高層想實施中臺戰略，那麼他一定會把這個部門的職責，定義成為將產品覆蓋到整個公司，而不是隻服務自己。當這二者之間有了契合的時候，作為供給者的戰鬥力才會發揮到最大。
也歡迎就今天聊的話題在評論區看到你的身影！
公眾號對話方塊回覆W，獲取微信與我建立連線，微信空位不多。
-------
以往熱文推薦：
更多精彩，關注我公眾號，一起學習、成長
▲長按關注軍哥手記，一起學習、成長