一個微服務業務系統的中臺構建之路

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

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

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

中臺與前后臺

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

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

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

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

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

中臺與平臺

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

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

中臺分類

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

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

定義中臺

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

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

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

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

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

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

3磨礪前行：Biz-UI 業務中臺構建之路

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

收集需求，構建團隊

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

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

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

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

分析業務，設計功能

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

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

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

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

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

編碼實現，接入前臺

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

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-xR7jP4kE-1598702752390)(data:image/gif;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQImWNgYGBgAAAABQABh6FO1AAAAABJRU5ErkJggg==)]

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

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

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

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

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

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

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-LSU01K2z-1598702752391)(data:image/gif;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQImWNgYGBgAAAABQABh6FO1AAAAABJRU5ErkJggg==)]

4未來可期：中臺展望

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

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

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

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

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

總結

以上是生活随笔為你收集整理的一个微服务业务系统的中台构建之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。