今天我分享的主題是京東服務技術中臺探索與實踐，分別從三個方面來講：

為何我們要做中臺？

京東服務技術中臺建設思路；

關于中臺建設的個人思考。

為何做中臺？答：拆掉煙囪

為什么要做服務技術中臺呢？舉個例子，假設一個用戶在京東買了東西，但不滿意，希望退換貨。他會通過在線聊天、電話找到客服，客服會對其進行接待，并將用戶反映的問題記錄下來。最終京東官方會給出一個解決方案，可能是換貨、退貨或賠付。如果客戶是從京東平臺第三方商家買到的產品，那么京東還需要從中立角度為他與商家執行仲裁。

所以，若想服務好顧客，我們會和許多部門打交道，包括物流、倉儲、維修等等，所以服務技術中臺是圍繞于人、財、物三者進行服務的。

就架構發展歷程來講，京東第一階段的應用結構都是單體應用，例如在物理機上部署一個 Nginx+Tomcat，要求非常簡單，就是快。那么多時間做復雜的設計，簡單粗暴，一堆代碼放上去能跑就可以了。當然，這種設計的缺點也非常明顯，就是運維成本非常高，沒有什么災備部署，服務器掛了就是掛了。

第二階段是“修身治國”，即當業務開始快速增長，我們對業務架構提出了更高的要求。在這種情況下，我們開始做業務的解耦和微服務化，將集群部署在多個不同的IDC，統一進行服務治理，包括建立了自動部署體系、統一的日志體系、統一的監控體系等基本的運維設施。自此，運維工作具備了橫向擴展能力：日常運維基于容器，部署自動化，可以很方便地收集、分析、處理告警，同時具備了一定的平臺化和可配置能力。

看起來一切都已經很不錯，那為什么還要做中臺呢？很多同學在另一個角度上提出了這種疑惑，即微服務化改造和中臺戰略到底有什么區別？那么接下來，我來講一講為何要做中臺，以及中臺和微服務有什么不一樣。

從單一角度來看，第二階段確實沒有什么明顯問題。但如果站高一點，站到整個公司的層面俯視，就會看到一堆“煙囪”，為什么是一堆“煙囪”？

首先我們會看到“產品煙囪”：不同的產品間，定位和功能雷同；

第二是“系統煙囪”，研發人員有一個特點：自己寫代碼開發的系統才用著放心，別人的不愿意用，所以總是重復開發；

第三是“數據煙囪”，在第二階段，各個系統產生的數據其實已經匯聚到大數據平臺。在一定程度上，數據不存在分別存儲的問題，但這依然存在一些問題：產品不同，因而數據計算邏輯和口徑是不同的，那么很可能同一個數據指標有不同的計算邏輯和計算口徑去計算，導致難以合并分析；

最后就是“組織煙囪”，即“部門墻”，天然存在，存在即合理。可當“部門墻”太厚就形成了“組織煙囪”，導致信息不透明。

以上就是第二階段存在的問題。

京東的解決思路是什么？就是中臺戰略，兼濟天下，無論是產品還是工具，不能只為自己考慮，不管他人死活，中臺要賦能整個公司、社區、環境。產品的使用人數越多越能凸顯價值。

京東服務技術中臺建設思路

京東服務技術中臺經過檢驗建設，共分為三層。

平臺層：核心能力包括及時通信平臺能力、音視頻能力，再加上業務引擎和基礎 SaaS 設施，這構成了我們的平臺層。

組件層：主要分為三個部分，第一部分是平臺插件和中心化。對于相對通用、容易用配置實現的功能或規則，用平臺配置中心完成，使標準化需求可以得到快速滿足；第二部分是插件裝配中心。如果一些需求無法標準化成配置，那么我們允許第三方，可以定制化自己的插件，插入我們的系統中，給用戶提供相應的功能服務。比如說常見的訂單插件、商品插件；最后一部分是個性化接入中心，部分業務邏輯、流程與中臺已有的非常不一樣，這種差異導致計劃配置也要差異化實現。這時候我們提供個性化接入，讓其可以變成做成標準化服務，接入整個服務網絡里面。

服務產品層：在前兩層之上，我們的產品體系最終得以構建，包括客服服務平臺、電話呼叫中心服務平臺、售后服務平臺等，在這一層對接、服務京東所有的業務領域。

服務技術中臺主要解決兩個問題：成本和速度。

“成本”這個詞非常好理解，繁多的職能和產品整合到了一起，人力成本首先得到了解決；“速度”，指的是交付速度，當新風口出現的時候，如果沒有中臺戰略良好的底層積累，產品質量沒有辦法保證。而對于中臺來說，新的產品可能只是換個殼。我們常說大中臺、小前臺，小前臺可以做得很快很輕，基于中臺的配置去完成。

所以，我們圍繞產品、系統、數據和組織來構建中臺架構。其中，組織其實是第一步工作，要把相同的產品、功能合并，再于產品之間進行整合，使之成為一個完整的個體，成為一個中臺，去對外提供服務。

我稱這種整合為一種藝術，為什么？第一，不同的“煙囪”確實代表業務需求不一樣，如果需求一致，不可能出現幾個煙囪；第二，業務方并不關心底層有幾套系統在做支撐，他們關注的是體驗和交付有沒有得到提升，但我們要得到業務方的支持。因為中臺建設其實需要投入大量的資源和人力，在這個過程中，一定程度上會減少支撐業務的技術人員數量，所以要和業務方提前達成一致。這就像要為高速奔馳的賽車更換發動機，簡單的系統一兩周就遷移完了，復雜的系統可能要半年、一年才能遷移完成。

這里還需要解決一個基本問題：產品整合完之后，同一個中臺要支撐不同的業務線，不同的業務線又有不同的邏輯和流程、不同的業務量和資源需求，那么第一步要做什么？

就是用多租戶把整個業務線的配置、資源（計算資源、存儲資源）隔離開。不同產品的多租戶身份必須是統一的、唯一的，因為如果每個系統都去建立自己的多租戶，當兩者需要配合完成任務的時候，就會發生沖突。

在這個基礎上，我們要按照“開放封閉原則”去打造生態。開放封閉原則，大家一定不陌生，中臺內部有非常完善的體系，我們并不希望外部需求去影響中臺的發展。同時，為了實現這個目標，我們對外開放了足夠多的擴展，包括多租戶、賬戶認證、訂單接口等。

只要滿足我們的協議，能夠快速進行配置，就完成了接入，速度非常快。同時產品和產品之間也是解耦的，包括CM、工單和機器人。我們允許第三方接入，讓單一的產品也能和第三方配合起來，同時提供PaaS、SaaS、私有云這三種模式來給集團賦能、外部賦能。

建設中臺的3問及5個必要條件

最后是我對服務技術中臺的一些思考。

首先建設中臺要問自己三個問題：

需要支撐多個不同的業務線嗎？

用戶來自不同的群體嗎？

存在重復建設嗎？

如果用戶和業務線相同，其實中臺在某種程度上是一個偽需求。

服務技術中臺建設的一些必要條件：

1.符合公司戰略發展方向；

2.領導層全力支持；

3.業務側的協同認可；

4.基礎設施能提供支撐；

5.基礎服務治理。

我在分享服務技術中臺的構建時，并沒有分享統一日志、統一監控、分布式框架、集群、容災等方面的內容，因為這些內容在第二階段就已經完成了。它們重不重要？非常重要，這是服務技術中臺建設的基礎。所以中臺建設的時機很重要，如果沒有這些基礎，沒有領導層支持，與公司戰略也不吻合，中臺建設就會非常吃力。

中臺建設的最大挑戰

在我看來，建設服務技術中臺的最大挑戰，既不是技術，也不是基礎設施，而是組織和文化。

為什么這么說？前面我們提到很多“煙囪”，需要將他們進行合并，最簡單的方式就是將兩個部門合并、將相同的產品合并，這就涉及到組織架構調整，沒有高層支持是不可能的。

我之前遇到一個講師，他在深圳做整個公司的架構負責人。他說，公司內部另外一個業務部門做了和他們一樣的東西。這讓他非常困惑，想推廣本部門產品非常困難，推到做了“競品”的業務部門死活推不下去，這是非常現實的情況，也是沒有得到高層支持時，常見的情況。

另一個挑戰是文化，其實很多公司都在進行中臺建設，但是在建設過程當中會遇到很多文化挑戰。文化挑戰分兩種：第一種是供給者，第二種是需求者。

對于需求者來說，最大的挑戰是要克服“什么都要我自己做”的心理。舉個例子，當產生了一個需求，最先想到的應該是，在公司內有無類似的產品是可以復用的，當別人的產品能夠部分滿足我們需求時，其實我們需要盡量地push他們，讓產品能夠盡量滿足我們的需求，而不是自己做。

對于供給者來說，最大的問題是工作和KPI是否能保持一致。如果只是滿足部門內需求就可以了，為什么要把產品給整個公司使用呢？這其實是增加了該部門的運營負擔，但如果高層想實施中臺戰略，那么他一定會把這個部門的職責，定義成為將產品覆蓋到整個公司，而不是只服務自己。當這二者之間有了契合的時候，作為供給者的戰斗力才會發揮到最大。

（作者：京東商城服務技術中臺研發負責人賈樂  本文由一鵬根據賈樂在10月26日結束的GTLC·成都站上的現場發言整理而成。）