| 這兩年中臺很火，已經代替微服務成爲架構首選，涌現出各類各樣的中臺名詞，業務中臺、數據中臺、技術中臺、算法中臺等，讓人眼花繚亂，稍微大點的互聯網公司都號稱在作中臺。本人從去年開始，作過相似的事情，這裏結合本身的實踐，談談對中臺的理解，但願可以幫助你們更清晰地瞭解中臺，一家之言，僅供參考。前端 本文的內容包括：算法 1.什麼是中臺小程序 2.中臺和微服務的區別後端 4.爲何要作中臺安全 4.深刻中臺架構微信 1. 什麼是中臺架構 既然講中臺，必然還有前臺和後臺。前臺很好理解，指的是面向 C 端的應用，包括前端 (如 App/ 小程序) 和對應的服務端。至於後臺，不少人把它等同於管理後臺，好比商品管理後臺，負責商品定義 / 上下架等，提供給內部運營人員使用，這可能不夠準確。分佈式 簡單來講，對於一個交易系統，前臺對應用戶能看到的部分，如商品瀏覽和下單，屬於接單的部分；後臺對應履單部分，如倉庫揀貨 / 配送 / 財務結算 / 採購補貨等，屬於實際幹活的，由企業內部人員負責，處於一個交易處理流程的後端。微服務 在傳統企業，沒有在線的前臺，基本是線下手工接單，內部信息管理系統基本都屬於履單範疇，例如 ERP、CRM、採購系統、倉庫管理系統，財務系統等，這些系統屬於通常意義上的後臺概念。spa 在互聯網企業，由於系統通常是本身開發，管理後臺既包含面向前臺銷售的功能，如商品上下架和促銷管理，也包含面向履單部分，好比配送、採購、財務結算，因此互聯網企業的管理後臺並不簡單等同於履單後臺。 接單和履單之間還有一系列事情要作，包括生成訂單時的優惠計算 / 建立實際的訂單 / 支付 / 庫存扣減等, 這部分功能屬於交易邏輯的核心。在簡單場景下，前臺應用包含這部分功能，在複雜的場景下，就有必要把這部分獨立出來，構成獨立的中臺，爲前臺減負。 一些文章籠統地介紹中臺是用來鏈接前臺和後臺的，這個值得商榷。若是管理後臺就是後臺，那沒有鏈接的必要，由於管理後臺自己就是系統的附屬部分，和前臺屬於一體兩面。至於履單後臺，前臺接單系統和後臺履單系統設計時就是打通的，也不須要額外定義一箇中臺來鏈接二者。互聯網企業的中臺更多的是基礎業務下沉，實現多業務場景共享，但在傳統企業，後臺系統清晰地存在，中臺確實起到鏈接後臺 (內部老系統) 和前臺 (新的 C 端應用) 的做用，因此互聯網企業的中臺和傳統企業的中臺定位和側重點是有差別的，這個下文會展開介紹。 爲了更好地理解中臺，這裏舉個形象的例子： 
最上面是各類具體的桌面應用，好比 office 套件，最底下是各類硬件設備，磁盤 / 內存 /CPU 等。 桌面應用能不能直接操縱底層硬件設備完成功能？理論上是能夠的，好比在應用裏嵌入彙編語言直接操做硬件，但顯然開發效率低，可維護性不好。若是中間加一層操做系統進行轉換，向下管理硬件，向上提供簡潔的 API，應用開發就很是方便，這裏操做系統相似中臺的定位。 對於大型傳統零售企業 (上圖右邊部分)，企業通過多年信息化建設，購買了大量的商業套裝軟件，造成內部 IT 基礎設施，如今要往新零售轉型，理論上 C 端的應用能夠直接調用老系統的 API(如 SAP 產品提供必定的開放能力) 來實現功能打通。但和桌面應用直接控制電腦硬件設備相似，這二者直接對接是低效的，二者的服務對象 (2C 和 2B)/ 數據模型 / 技術棧 / 實時性要求差別很大，並且新的應用進來，又要從頭至尾對接一遍，新業務上線，至少須要大半年的時間。 這時若是有個中間層負責橋接和轉換，就很是方便。C 端應用能夠快速基於這個中間層構建，不用關心底層遺留系統的實現細節。這個中間層就是中臺，起到相似操做系統的做用，把舊的基礎設施轉換成面向互聯網的基礎平臺，並且這個平臺很是通用，新業務能夠快速對接，短期搞定上線。傳統企業在作全面數字化轉型時，這樣的一箇中臺必不可少。 2. 中臺和微服務的區別 中臺源於大型互聯網企業，這些系統通常是分佈式的微服務架構，那麼中臺和微服務架構有什麼區別呢？ 簡單地說，我認爲中颱是微服務的升級，原來只是一個個離散的服務，只負責提供接口功能，如商品服務 / 訂單服務 / 權限服務，在中臺裏，升級爲商品中心 / 訂單中心，每一箇中心更強調體系，包括更好的邊界劃分和業務抽象，更好地監控和系統運營能力 (穩定性 / 故障定位)，更好的業務運營能力 (好比商品中心自帶商品管理後臺，支持基礎商品定義)。每一個服務中心圍繞核心業務，自成體系，成爲一個微內核，這些微內核既相互獨立，又造成一個總體，共同構成基礎業務平臺，也即中臺。鬆散的微服務 -> 共享服務體系 -> 中臺，這是微服務架構和中臺的區別和聯繫。 如今你們談的最多的是業務中臺，我認爲一個典型的業務中臺包含 3 層：
對於中臺來講，完善的基礎業務功能由通用基礎業務平臺實現；通用聚合服務進一步提高易用性 ; 通用中間件平臺保證系統的穩定性。 除了業務中臺，提的比較多的是數據中臺，數據中臺也是整合數據能力，能夠高效地給業務賦能，好比智能推薦，千人千面，精準營銷等。 補充說明下，這裏通用中間件平臺和技術中臺一個概念，我以爲沒有必要單獨叫技術中臺，不帶業務的中臺是沒有靈魂的，不能叫中臺。同理內容中臺的說法是合適的，但算法中臺就不合適，你們能夠用這個原則區分各類中臺的真僞。 3. 爲何要作中臺 軟件架構從單體架構，到分佈式 SOA，到微服務，到中臺架構，這都是業務複雜化的結果，架構比如生產關係，業務是生產力，架構必定要隨着業務發展而演化。 0 到 1 階段，只有一條業務線，好比出租車業務，直接根據需求實現便可。從 1 到 n 階段，業務線逐漸增長，好比快車 / 順風車。 這時系統有兩種作法，第一種是新業務線仍是單獨實現，多個業務線之家是相互獨立的，系統結構總體上是」川」字型，以下圖所示。但若是業務線相似，它們的核心邏輯（地圖 / 調度 / 訂單支付）也是相似的，子系統之間有大量的代碼複製和多地維護，這是很是低效的。 第二種作法是把核心邏輯單獨抽取出來，作好通用化，共同服務於全部業務線的需求，此時對於各個業務線系統而言，包括自身的應用層和通用層兩部分，定製的東西在應用層解決，共享的東西由通用層提供，再經過編排共享邏輯完成業務流程。系統結構總體上是」山」字型，這個通用層就是山字最底下一橫，把各個業務線有機粘合在一塊兒，共享業務邏輯和統一業務規則，實現最大程度的複用。 固然搭建山字形是有難度的，何時轉型爲「山」字形？ 一方面和 n 值有關，好比 n>=3 時，應該要考慮轉到山字形，另外一個因素和各個業務線的類似度有關，類似度高更適合」山」字形，好比電商的 C2C 和 B2C 業務；差別比較大，適合」川」字形，好比電商業務和互聯網金融業務，不必強行扭在一塊兒。
從業務角度看，中臺表明通用的基礎業務，一個企業基礎的業務能力和業務規則是相對穩固和清晰的，各個業務線能夠認爲具體業務場景，如小程序下單 / 三方外賣等相對複雜和多變，但能夠經過組裝各個基礎業務，快速知足業務場景需求。對於新的業務來講，基礎的東西已經差很少有了，只須要少許針對場景的定製開發。總的來講，中臺收斂了業務場景，統一了業務規則，好比各個渠道的訂單都歸到中臺的訂單服務，遵循相似的訂單狀態流轉和履單過程。 基礎業務是有限的，業務場景是無限的，特別是在移動互聯網和全面數字化轉型的大背景下，傳統企業須要開拓大量新渠道，搭建中臺，能夠很好地經過有限的基礎業務知足無限的業務場景。 從系統角度看，中臺至關於商業操做系統，提供標準接口給上層應用，對於傳統企業來講，中臺之下還有明確的後臺，中臺很好地把前端應用 (面向互聯網) 和企業遺留系統 (面向內部管理) 銜接起來，屏蔽底層系統的複雜性和各類適配工做。 從數據角度看，中臺收斂業務場景的同時，也收斂了數據 好比自有小程序的訂單和外賣訂單統一到一個訂單庫，使用同一套數據模型（具體用到的字段可能略有差別），這爲後續的數據中臺搭建打下良好基礎。 4. 深刻中臺架構 大一點的互聯網企業，系統已是類中臺的「山」字型架構，更多的是局部強化和整合。對於傳統企業來講，系統基本是」川」字型，大量相互獨立的商業套件組成遺留系統。如何基於這些系統搭建中臺挑戰很大，因此這裏更多剖析傳統企業的中臺架構。 下圖是比較典型的傳統企業中臺架構：
整個架構從上到下分 4 層： 渠道 & 應用 這是整個系統對外部分，包括各個應用的前端，如 APP/ 小程序 / 公衆號, 這些是須要定製部分。同時提供 Open API，對外部企業輸出業務能力。 應用平臺 應用平臺是各個實際應用的母體，首先包含各個應用的服務端，好比小程序服務端 /APP 服務端，這些服務端針對具體場景，作流程編排和信息的聚合。 還有各個比較獨立的應用模塊，如搜索 / 推薦 / 評論 / 拼團，這些模塊不強調各個業務線之間共享，只是做爲獨立模塊從服務端剝離出來，方便維護。 還有一些相對簡單服務，不屬於基礎共享業務範疇，好比和具體某個業務相關的配置數據，也經過服務的方式封裝。 網關實現先後端隔離，包括外部訪問的安全驗證和監控，以及內部路由和消息格式轉換。 業務中臺 由一系列的通用基礎服務構成，這些基礎服務邊界清晰，相互獨立，沒有調用關係。有些業務場景須要跨服務的數據，好比下單，須要同時涉及商品服務 / 庫存服務 / 訂單服務，通常在基礎服務之上有一層聚合服務，經過組合這些基礎服務，造成更大粒度的功能接口，供應用平臺調用。 中臺最底下是技術中間件，包括消息推送，短信郵件，數據訪問等，穩定性主要由這部分保證。 後臺 包括兩部分，適配插件用於鏈接商戶內部系統和中臺基礎服務，好比在中臺商品服務和後臺 ERP 之間同步商品和庫存數據，在會員服務和 CRM 之間同步會員信息。通常針對每一個內部系統有一個適配插件，適配插件起到相似硬件驅動程序的做用，這個定製化程度比較高。 商戶內部系統就不展開，各個企業的狀況不一樣。 架構圖最右邊是三方 API 對接，典型的如微信 / 支付寶的對接，美團 / 餓了嗎三方外賣對接，天貓 / 京東的電商平臺對接。這個對接前端 / 應用平臺 / 中臺都會涉及。 5. 總結 架構向中臺轉型是業務複雜化發展的必然結果，中臺提供了多方面的價值，無論互聯網企業仍是傳統企業，中臺的大方向都是沒錯的。 對於互聯網企業，有基礎，往中臺靠是改良，須要注意的是，根據當前的業務發展階段，平衡投入和產生比，適時啓動中臺改造。 對於傳統企業，內部 IT 基礎設施和麪向互聯網的應用差別很大，往中臺轉是革命性動做。如何落地中臺戰略既須要頂層思考，又須要結合實際，作各類平衡和妥協。作的很差，效果拔苗助長，所謂不作中臺等死，作中臺立刻死，從這個意義上說，是否上中臺，有點相似十幾年前上大型 ERP，須要務實的評估，拒絕形式主義。 |