微服務(wù)業(yè)務(wù)系統(tǒng)（Biz-UI）的中臺(tái)構(gòu)建之路

導(dǎo)讀：

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

霧里看花 - 解開中臺(tái)的面紗

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

01 中臺(tái)與前后臺(tái)

我們先來為前臺(tái)和后臺(tái)做一個(gè)宏觀的定義。

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

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

穩(wěn)定、可靠是后臺(tái)所追求的目標(biāo)。而前臺(tái)因?yàn)楹涂蛻艚换サ脑?，需要快速響?yīng)客戶頻繁的需求變化。因此，前后臺(tái)之間在目標(biāo)訴求、響應(yīng)速度等方面具有不可調(diào)和的矛盾。它們就像一大一小兩個(gè)齒輪，因?yàn)辇X比密度的不同，難以平滑的協(xié)調(diào)運(yùn)轉(zhuǎn)。

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

02 中臺(tái)與平臺(tái)

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

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

03 中臺(tái)分類

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

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

04 定義中臺(tái)

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

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

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

必由之路 - 構(gòu)建中臺(tái)的重要性

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

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

磨礪前行 - Biz-UI 業(yè)務(wù)中臺(tái)構(gòu)建之路

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

01 收集需求，構(gòu)建團(tuán)隊(duì)

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

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

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

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

02 分析業(yè)務(wù)，設(shè)計(jì)功能

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

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

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

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

總的來說，在設(shè)計(jì)階段的主要工作就是首先對(duì)識(shí)別的痛點(diǎn)做根因分析，再基于多個(gè)業(yè)務(wù)線進(jìn)行領(lǐng)域分析，討論業(yè)務(wù)的重合度，并抽象出共性業(yè)務(wù)，引入中臺(tái)架構(gòu)并制定出相應(yīng)的解決方案。

03 編碼實(shí)現(xiàn)，接入前臺(tái)

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

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

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

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

一般會(huì)有兩種中臺(tái)接入方式：自助式和一站全包式。

• 自助式接入：顧名思義，接入方自己完成與中臺(tái)組件的整合工作。當(dāng)然，中臺(tái)開發(fā)者會(huì)全程提供文檔、示例、培訓(xùn)等一系列技術(shù)支持。

  
  

• 一站全包式：由中臺(tái)開發(fā)者幫助接入方完成整合工作，包括且不限于提供編碼、配置等服務(wù)。這種方式一般用于組件升級(jí)的時(shí)候，代碼的變更很小，且風(fēng)險(xiǎn)可控，接入方的代碼持有者只需要review修改就可以了。

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

未來可期 - 中臺(tái)展望

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

• 產(chǎn)品化：如果把中臺(tái)想象成一個(gè)產(chǎn)品，那么和任何技術(shù)產(chǎn)品一樣，中臺(tái)所具有的能力不僅僅是業(yè)務(wù)復(fù)用，還應(yīng)該具有一定的非功能性，即各種能力（例如scalability），這也是BSAP項(xiàng)目一開始的初衷。因此，我們的構(gòu)建目標(biāo)也不僅僅局限于業(yè)務(wù)復(fù)用本身，還通過一系列的中間件和工具庫(kù)，讓服務(wù)具有可靠、可擴(kuò)展、可復(fù)用等各種分布式原語能力。另外，作為一個(gè)產(chǎn)品，用戶手冊(cè)是其重要的組成部分。我們的使用文檔還需要進(jìn)一步的打磨，通過標(biāo)準(zhǔn)化和簡(jiǎn)潔規(guī)范的方式給使用者提供便利。

  
  

• 規(guī)范化：因?yàn)橹信_(tái)每個(gè)組件都是由某個(gè)眾籌小分隊(duì)獨(dú)立開發(fā)的，在設(shè)計(jì)和實(shí)現(xiàn)方案上難免不同。因此，接入方式也有所區(qū)別。比如有的組件需要添加一個(gè)攔截器，有的需要引入一個(gè)類庫(kù)，有的需要添加配置文件。這種多樣的使用方式并不友好，在一定程度上增加了接入難度。未來我們考慮通過一套統(tǒng)一的中臺(tái)服務(wù)接口（Unified mid-platform API），為用戶提供統(tǒng)一的接入方式和開發(fā)體驗(yàn)。

  
  

• 服務(wù)化：目前我們大部分中臺(tái)組件都是以公共庫(kù)的方式呈現(xiàn)，優(yōu)勢(shì)是進(jìn)程內(nèi)調(diào)用，效率高，性能好。但其劣勢(shì)就是無法完全對(duì)應(yīng)用透明，需要引入類庫(kù)，也存在語言綁定的問題，無法適用于異構(gòu)應(yīng)用。對(duì)于相對(duì)獨(dú)立或者異步調(diào)用的組件，可以考慮封裝成服務(wù)，屏蔽實(shí)現(xiàn)細(xì)節(jié)，降低接入成本。

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

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

希望此文會(huì)對(duì)你有所幫助！

馬若飛

FreeWheel?Biz-UI團(tuán)隊(duì)首席工程師

《Istio實(shí)戰(zhàn)指南》作者，人民郵電出版社IT專業(yè)圖書專家顧問，ServiceMesher社區(qū)管理委員會(huì)成員。目前就職于FreeWheel，熱衷于技術(shù)探索與分享。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下： 
			
 
		

		

			 
		

長(zhǎng)按訂閱更多精彩▼
		
 
			
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝