中臺是近兩年軟件開發(fā)領域的熱點話題，相關的文章也成為了各個技術社區(qū)和媒體爭相報道的網(wǎng)紅內(nèi)容。作為企業(yè)支撐業(yè)務開發(fā)的核心系統(tǒng)，中臺的重要性不言而喻，很多企業(yè)也開始嘗試中臺的構建和落地工作。Biz-UI 的業(yè)務中臺孵化于 BSAP（Business Service Architecture and Practice）項目，經(jīng)過一年多的積累，終于開花結果。本文將從中臺的基本概念講起，帶你一起探尋 Biz-UI 團隊的業(yè)務中臺構建之旅。

1. 霧里看花：解開中臺的面紗

2015 年阿里制定了“大中臺，小前臺”的戰(zhàn)略方向，中臺一詞由此誕生。作為一個國人創(chuàng)造的詞匯，中臺沒有一個原生的英語詞匯來表示，我個人更傾向于使用“middle-end”或者“middle-platform”來表示。但可以確定，中臺是介于前臺和后臺之間的產(chǎn)物。所以在理解中臺概念之前，我們先來看一下它和前后臺的區(qū)別。

中臺與前后臺

我們先來為前臺和后臺做一個宏觀的定義。

前臺： 企業(yè)交付給終端用戶（客戶）所使用的系統(tǒng)，是企業(yè)與客戶進行交互的平臺，例如用戶直接訪問的網(wǎng)站、App 等都可以算做前臺。對于 FreeWheel MRM 核心業(yè)務系統(tǒng)來說，前臺就是提供給客戶使用的前端頁面，以及為頁面提供業(yè)務邏輯支撐的微服務系統(tǒng)，也就是我們內(nèi)部所說的 Domain services。

后臺： 管理企業(yè)核心信息資源（數(shù)據(jù)）的后端系統(tǒng)、計算平臺、基礎設施。后臺不會和終端用戶直接交互，不（也不應該）具備業(yè)務屬性。對于 FreeWheelMRM 核心業(yè)務系統(tǒng)來說 ，搜索平臺，數(shù)據(jù)訪問層，基礎設施都屬于后臺的范疇。

穩(wěn)定、可靠是后臺所追求的目標。而前臺因為和客戶交互的原因，需要快速響應客戶頻繁的需求變化。因此，前后臺之間在目標訴求、響應速度等方面具有不可調(diào)和的矛盾。它們就像一大一小兩個齒輪，因為齒比密度的不同，難以平滑的協(xié)調(diào)運轉。

在軟件開發(fā)領域流傳著這樣一句話：“軟件設計與開發(fā)過程中出現(xiàn)的任何問題，都可以通過增加一層來解決”。在這里我們不去探討它的對錯和適用范圍，但可以確定的是，中臺的出現(xiàn)，就是為了解決前后臺運轉效率不同的矛盾，通過中臺這個變速齒輪銜接前臺和后臺，消除兩者在效率上的差異性，以此達到系統(tǒng)整體的平衡。

中臺與平臺

很多人難免混淆中臺與平臺的概念。我們拿 Supercell 公司舉例，阿里的中臺戰(zhàn)略緣起于對 Supercell 公司的參觀訪問，他們驚嘆于如此小規(guī)模的團隊卻能夠快速的開發(fā)和復制出成功的產(chǎn)品。而背后功臣，就是 Supercell 所擁有的具有業(yè)務復用能力的系統(tǒng)，比如玩家系統(tǒng)、技能系統(tǒng)、裝備系統(tǒng)、道具系統(tǒng)等等。這些業(yè)務系統(tǒng)可以讓其快速的復制出新的產(chǎn)品，而無需重復開發(fā)相似業(yè)務。Supercell 的這些系統(tǒng)，都是真正的業(yè)務系統(tǒng)。

那么，Supercell 擁有的是中臺還是平臺？讓我們來定義一下它們之間的區(qū)別：中臺是支持多個前臺業(yè)務且具備業(yè)務屬性的可復用系統(tǒng)；而平臺是支持多個前臺但不具備業(yè)務屬性的系統(tǒng)。業(yè)務相關性和業(yè)務無關性，是衡量中臺與平臺的唯一標準。因此，要區(qū)分中臺和平臺，只需要基于一點去考慮，就是判斷它們是否具有業(yè)務屬性。

中臺分類

我們常常會聽到各種各樣的中臺：業(yè)務中臺、數(shù)據(jù)中臺、技術中臺等等。在中臺分類這一點上，我非常認同網(wǎng)易副總裁汪源的理念：“所有的中臺都是業(yè)務中臺”。從廣義上講，所謂某某中臺，都是為業(yè)務服務的，是為了企業(yè)可以以更低的成本、更高的效率，快速響應業(yè)務需求并推出新產(chǎn)品。比如所謂數(shù)據(jù)中臺，就是對業(yè)務數(shù)據(jù)進行二次加工，并將輸出結果再次服務于業(yè)務。本質(zhì)上講，數(shù)據(jù)就是業(yè)務的載體。而所謂技術中臺，其實是將基礎設施、中間件的能力進行整合與封裝，提供統(tǒng)一的可重用接口。從這一點來說，它僅僅是一個中間件平臺。

中臺需要具有實現(xiàn)業(yè)務系統(tǒng)所必需的業(yè)務元素，并封裝了問題域（業(yè)務領域）的通用解決方案，這也是本文所主張的業(yè)務中臺的核心描述。

定義中臺

中臺是業(yè)務抽象層面的復用平臺，其核心是將具有共性的業(yè)務抽象出來，并提供復用。復用定義了中臺的核心價值，具備可復用性才能達成降本提效的目的，為企業(yè)帶來效益。中臺的搭建也不僅僅是個技術問題，還應該跳出單一的業(yè)務線，從企業(yè)架構的層面上去考慮，站在企業(yè)的視角來審視業(yè)務全貌。

另一方面，我們也可以認為中臺是產(chǎn)品的平臺化產(chǎn)物。通過將產(chǎn)品中具有共性的業(yè)務下沉，形成一個可復用的平臺；反過來理解也可以，即平臺產(chǎn)品化：為平臺植入業(yè)務屬性，使其具有部分產(chǎn)品的特性，為構建具體產(chǎn)品提供必要的業(yè)務元素。

當然，每個人對中臺的理解不盡相同，我們也無需強加一個統(tǒng)一的定義。理解中臺的本質(zhì)，并通過它降低開發(fā)成本、提升開發(fā)效率，為企業(yè)產(chǎn)品賦能，這才是構建中臺的關鍵點。

2. 必由之路：構建中臺的重要性

從定義可以看出，中臺的存在會改變業(yè)務的開發(fā)與交付方式，并以一種更高效的方法來響應業(yè)務需求。構建中臺背后的訴求，其實是希望對多業(yè)務進行支持，快速響應前臺的變化和創(chuàng)新，并構建新的業(yè)務和產(chǎn)品線。中臺是平臺發(fā)展到一定階段的產(chǎn)物，當我們的業(yè)務擴展和變化速度超過了平臺的服務能力后，需要將一部分具有共性的業(yè)務抽象出來并下沉到平臺，以便可以快速的支持新的業(yè)務開發(fā)。因此，中臺也可以理解為是平臺向業(yè)務進化的產(chǎn)物。

作為 MRM 核心業(yè)務系統(tǒng)的開發(fā)團隊，遷移到微服務架構后痛點也逐漸顯露出來。在服務鏈路的梳理和重構過程中，我們發(fā)現(xiàn)有很多業(yè)務邏輯是具有共性的，應該被抽象出來。同時，隨著公司業(yè)務線的擴展，Marketplace 這樣的新產(chǎn)品也需要搭建一系列新的服務。如何高效的構建新服務，并復用現(xiàn)有的業(yè)務邏輯成為了團隊急需解決的問題。因此，搭建業(yè)務中臺，成為了我們解決開發(fā)效率方面的首要任務。

3. 磨礪前行：Biz-UI 業(yè)務中臺構建之路

任何系統(tǒng)的構建過程都不是一蹴而就的，業(yè)務中臺更是如此。前路漫漫，上下求索，通過不斷的打磨、試錯、重構，經(jīng)過一年多的開發(fā)，適用于 Biz-UI 團隊的業(yè)務中臺概念愈加清晰，功能模塊也逐漸完善和系統(tǒng)化。開發(fā)過程可以劃分為 3 個階段。

收集需求，構建團隊

2017 年我們將業(yè)務系統(tǒng)從單體結構重建為微服務架構時，是通過自底向上的方式，基于業(yè)務能力進行服務的劃分。這種方式最大的優(yōu)勢就是能夠快速的完成構建和開發(fā)過程，盡早完成遷移。但其劣勢也很明顯：沒有統(tǒng)一的規(guī)劃和設計，整個系統(tǒng)缺乏通用的框架和服務治理能力。為解決這一問題，我們提出了 BSAP（Business Service Architecture and Practice）項目，旨在改進和優(yōu)化現(xiàn)有的微服務架構，為各個業(yè)務線提供可復用的服務治理能力，同時提供一整套的公共庫和中間件，以提高微服務的開發(fā)效率。業(yè)務中臺就孵化于此。

和阿里這種先制定中臺戰(zhàn)略，再統(tǒng)一開發(fā)的方式不同，項目初期我們并沒有想要刻意的構建一個業(yè)務中臺。初衷很簡單，就是想把相似的業(yè)務邏輯以組件或類庫的方式抽象出來，以便達到復用的目的。隨著具有業(yè)務共性的中間件和類庫越來越多，我們意識到在本質(zhì)上，我們所構建的這些組件的集合正是所謂的業(yè)務中臺。

從投資結構的角度來講，我們的中臺團隊是通過“眾籌模式”組建起來的，參與項目的都是各個業(yè)務線的核心開發(fā)人員，他們描述自己業(yè)務的需求和痛點，并提出解決方案，在 BSAP 會議上通過分析、討論，如果認為是有價值的議題就會正式進入開發(fā)階段。而開發(fā)團隊就是需求的提出者，當然他可以招募一些幫手，其他有共同訴求或者感興趣的同學也可以自愿加入。他們同時扮演著用戶和開發(fā)者的角色，對痛點有深刻的理解，因此這種自給自足的開發(fā)方式能夠準確的命中需求，不必擔心需求和實現(xiàn)不匹配。每個項目團隊都是自愿組成，利用業(yè)余時間完成開發(fā)任務。相比“投資模式”來說，眾籌模式不需要特別的抽調(diào)開發(fā)人員獨立成組，在人力資源成本、管理成本和開發(fā)意愿等方面都有較大優(yōu)勢。

中臺團隊是一個共享服務團隊，與前臺（業(yè)務開發(fā)方）是服務與被服務的關系。一個龐大的中臺規(guī)劃因為其長期性和復雜性，很難在短期內(nèi)滿足前臺的業(yè)務需求，中臺團隊也很可能因為要服務于多個前臺業(yè)務而出現(xiàn)資源競爭的矛盾。而我們的中臺是以類似拼圖的方式逐漸積累而成，現(xiàn)做現(xiàn)用，能快速響應前臺業(yè)務方需求。與阿里這種大廠打造的有成百上千人員規(guī)模的中臺團隊來說，我們這種小快靈的精英特種部隊機動靈活，打一槍換一個地方（做完一個中臺項目再做別的項目），具有先天的優(yōu)勢，且構建成本極低，是最適合中小型企業(yè)的構建方式。

分析業(yè)務，設計功能

明確需求之后，就可以進入當前議題的設計階段。和任何軟件開發(fā)流程一樣，設計是不可或缺的階段，作為需求和實現(xiàn)之間的橋梁，它將業(yè)務建模轉變?yōu)榧夹g方案，并保證實施的正確性。對于中臺來說，設計階段的內(nèi)容又有其特殊的地方：就是通過對各個領域的業(yè)務進行分析，尋找出可以抽象的共性能力。因為中臺要服務的是多個前臺業(yè)務線，必須要對整體業(yè)務進行分析并找到通用的部分，才能滿足復用這一核心價值。如果僅僅是從單一業(yè)務出發(fā)，只滿足當前需求，就等于為當前的微服務實現(xiàn)了它獨有的業(yè)務邏輯而已。

為避免出現(xiàn)這種問題，在議題分析階段，我們會通過頭腦風暴的方式進行思維碰撞，當某一個人在描述自己的需求時，具有相同或相似痛點的人也會產(chǎn)生共鳴，并提出自己的補充觀點，最終整合出一個既滿足通用需求，又滿足特性需求的技術解決方案。舉例來說，我們開發(fā)的 Job 中間件是一個基于 Golang 和 Redis 的輕量級定時任務系統(tǒng)，除了具備最基本的定時任務功能外，還根據(jù)客戶的需求做了個性化擴展。比如“Dynamic Cron”功能支持客戶在任務運行期間動態(tài)的修改執(zhí)行周期；“Hook”功能可以讓客戶定制任務執(zhí)行后的回調(diào)流程，比如調(diào)用三方接口，將執(zhí)行結果發(fā)送郵件，或是上傳到 AWS S3 等，對個性化的業(yè)務操作做到即插即用。目前 Order、Forecast、Partner、Inventory 等服務都接入了 Job 系統(tǒng)，滿足了各業(yè)務線復用的需求。

需要指出的是，所謂的共性能力包括業(yè)務數(shù)據(jù)、業(yè)務功能以及通用的技術能力。比如 Placement（廣告位）就是一個幾乎被各個業(yè)務都使用到的業(yè)務數(shù)據(jù)，同時它又具有一定的變體，在廣告預測（Forecast）業(yè)務中它會具有額外的預測屬性，在合作方（Partner）業(yè)務中它又會具有中間商相關屬性。它們都共享 Placement 的基本數(shù)據(jù)同時又具有自己的特殊字段。對于這樣的情況我們會把對核心數(shù)據(jù)模型的操作抽象出來作為模板方法，各業(yè)務在此基礎上做個性化定制。

對通用技術能力的抽象也有很多例子。比如為了更方便的開發(fā)一個新的微服務，我們設計了一套輕量級的服務通信層框架，新服務只需要實現(xiàn)應用初始化接口（AppInitializer），并在配置文件中定義好對應的端口號，就可以實現(xiàn)一個同時支持 HTTP 和 gRPC 協(xié)議的 Web 服務器，并可以在 ServerOption 中添加中臺里實現(xiàn)的各種攔截器，完成追蹤、請求日志、API 權限控制等一系列服務治理功能。而新服務的開發(fā)者只需要在標準的 protobuf 文件中定義自己的業(yè)務接口并實現(xiàn)即可。

總的來說，在設計階段的主要工作就是首先對識別的痛點做根因分析，再基于多個業(yè)務線進行領域分析，討論業(yè)務的重合度，并抽象出共性業(yè)務，引入中臺架構并制定出相應的解決方案。

編碼實現(xiàn)，接入前臺

在實現(xiàn)階段我們采用了精益創(chuàng)業(yè)中的 MVP（Minimum Viable Product）原則。MVP 即最小價值化產(chǎn)品策略，是指開發(fā)團隊通過提供最小化可行性產(chǎn)品，獲得用戶反饋，并在其基礎上持續(xù)的快速迭代，最終讓產(chǎn)品達到一個穩(wěn)定完善的形態(tài)。下圖是一個經(jīng)典的 MVP 示例，產(chǎn)品的愿景是開發(fā)一種交通工具，可以將用戶從 A 點帶到 B 點。使用 MVP 設計的產(chǎn)品一直遵循著產(chǎn)品的核心價值，即運輸能力，從一輛簡單的滑板車開始，逐步演進，最終完成了汽車的制造。在任何一個迭代階段，產(chǎn)品都是可用的且能滿足客戶需求。而沒有遵循 MVP 的實現(xiàn)方式就犯了眼高手低的錯誤，從一開始就設計了一輛汽車但只能提供輪子，其結果就是在大部分迭代階段都不可用，也無法得到用戶反饋，最終很可能會偏離設計目標，與用戶的需求不符。

MVP 原則對初創(chuàng)型團隊非常有效，可以通過試錯，快速驗證團隊的目標，從而定位出產(chǎn)品的核心價值屬性。在中臺的構建過程中，我們每一個眾籌小分隊就是一個典型的初創(chuàng)團隊，先通過一個最簡化的實現(xiàn)方案，解決現(xiàn)有痛點，再逐步完善、擴展，以滿足不同業(yè)務線的需求。

在開發(fā)流程上，我們遵循公司成熟的 SAFe 體系，每個任務都有 ticket 追蹤。每周的 BSAP 例會上各個團隊會對開發(fā)任務做進度更新，在設計、開發(fā)、提交代碼等階段進行專項的 Review 會議，盡最大可能保證整個實現(xiàn)流程的可靠和可控性。

我們的中臺用戶是各個業(yè)務線的微服務開發(fā)人員，而這些開發(fā)人員對中臺能力的需求，來源于客戶對產(chǎn)品的需求。因此，業(yè)務需求驅(qū)動了中臺用戶（開發(fā)者）需求，而用戶需求又驅(qū)動了中臺的能力需求。在這一需求鏈中，業(yè)務線的開發(fā)者同時扮演了甲方和乙方，他們作為種子用戶，將自己的開發(fā)成果接入到各自負責的業(yè)務微服務中。而該服務就自然而然的成為了中臺功能的試點（Pilot），用于試錯和驗證產(chǎn)品的正確性。在該組件的可靠性和穩(wěn)定性得到肯定后，就會推廣到其他業(yè)務線進行接入工作。

一般會有兩種中臺接入方式：自助式和一站全包式。

• 自助式接入： 顧名思義，接入方自己完成與中臺組件的整合工作。當然，中臺開發(fā)者會全程提供文檔、示例、培訓等一系列技術支持。
• 一站全包式： 由中臺開發(fā)者幫助接入方完成整合工作，包括且不限于提供編碼、配置等服務。這種方式一般用于組件升級的時候，代碼的變更很小，且風險可控，接入方的代碼持有者只需要 review 修改就可以了。

除此之外，為了在公司內(nèi)更大范圍地共享成果，我們還專門構建了一個 BSAP 的項目網(wǎng)站，提供了業(yè)務中臺各個組件的設計文檔和用戶手冊，以便其他兄弟團隊也能以自助的方式接入中臺，從而在公司范圍內(nèi)達到降本提效、技術共享的目的。經(jīng)過了一年多的努力，我們的中臺項目也日趨完整，覆蓋了如下圖所示的應用場景：

4. 未來可期：中臺展望

在業(yè)務中臺初具規(guī)模后，我們開始思考后續(xù)的發(fā)展。眾籌開發(fā)模式讓中臺拼圖逐漸完整，但仍然缺少一種黏合劑，可以讓它更加的牢固可靠，成為一個真正完善的系統(tǒng)級產(chǎn)品。這需要我們站在企業(yè)級架構的層面上去思考問題，以自頂向下的方式去梳理我們的業(yè)務和產(chǎn)品線，并結合現(xiàn)有中臺做進一步的優(yōu)化。為此，我們提出了中臺未來規(guī)劃的三個方面：

• 產(chǎn)品化： 如果把中臺想象成一個產(chǎn)品，那么和任何技術產(chǎn)品一樣，中臺所具有的能力不僅僅是業(yè)務復用，還應該具有一定的非功能性，即各種能力（例如 scalability），這也是 BSAP 項目一開始的初衷。因此，我們的構建目標也不僅僅局限于業(yè)務復用本身，還通過一系列的中間件和工具庫，讓服務具有可靠、可擴展、可復用等各種分布式原語能力。另外，作為一個產(chǎn)品，用戶手冊是其重要的組成部分。我們的使用文檔還需要進一步的打磨，通過標準化和簡潔規(guī)范的方式給使用者提供便利。
• 規(guī)范化： 因為中臺每個組件都是由某個眾籌小分隊獨立開發(fā)的，在設計和實現(xiàn)方案上難免不同。因此，接入方式也有所區(qū)別。比如有的組件需要添加一個攔截器，有的需要引入一個類庫，有的需要添加配置文件。這種多樣的使用方式并不友好，在一定程度上增加了接入難度。未來我們考慮通過一套統(tǒng)一的中臺服務接口（Unified mid-platform API），為用戶提供統(tǒng)一的接入方式和開發(fā)體驗。
• 服務化： 目前我們大部分中臺組件都是以公共庫的方式呈現(xiàn)，優(yōu)勢是進程內(nèi)調(diào)用，效率高，性能好。但其劣勢就是無法完全對應用透明，需要引入類庫，也存在語言綁定的問題，無法適用于異構應用。對于相對獨立或者異步調(diào)用的組件，可以考慮封裝成服務，屏蔽實現(xiàn)細節(jié)，降低接入成本。

業(yè)務中臺作為一個具有戰(zhàn)略意義的產(chǎn)品，其構建過程不是一蹴而就的。現(xiàn)階段的重點依然是盡可能的打磨和優(yōu)化，讓各個組件在易用性、可靠性、穩(wěn)定性等各方面達到一個較高的水準，從而讓用戶在使用上更加放心。未來值得期許，但也需要腳踏實地的一步一步前行。

每個人對中臺的理解各有不同，但其意義是顯而易見的：通過中臺戰(zhàn)略，將業(yè)務能力下沉并復用，使企業(yè)擁有快速響應需求、快速試錯和創(chuàng)新的能力，從而能夠引領市場，獲得可持續(xù)發(fā)展。FreeWheel 是以客戶為中心的公司，中臺之所以重要，就是因為它賦予了我們這類公司最核心的能力：用戶響應力。中臺的出現(xiàn)，改變了業(yè)務的開發(fā)方式和交付形態(tài)，加速了產(chǎn)品的迭代和進化周期。我們有理由相信，中臺并不會是曇花一現(xiàn)的產(chǎn)物，它會和微服務、云原生技術一樣，成為軟件開發(fā)領域的弄潮兒，讓我們拭目以待。

希望此文會對你有所幫助！

5. 作者介紹

馬若飛，F(xiàn)reeWheel Biz-UI 團隊首席工程師，《Istio 實戰(zhàn)指南》作者，人民郵電出版社 IT 專業(yè)圖書專家顧問，ServiceMesher 社區(qū)管理委員會成員。目前就職于 FreeWheel，熱衷于技術探索與分享。