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

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

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

中臺與前后臺

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

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

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

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

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

中臺與平臺

很多人難免混淆中臺與平臺的概念。我們拿 Supercell 公司舉例，阿里的中臺戰(zhàn)略緣起于對 Supercell 公司的參觀訪問，他們驚嘆于如此小規(guī)模的團(tuán)隊卻能夠快速的開發(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 擁有的是中臺還是平臺？讓我們來定義一下它們之間的區(qū)別：中臺是支持多個前臺業(yè)務(wù)且具備業(yè)務(wù)屬性的可復(fù)用系統(tǒng)；而平臺是支持多個前臺但不具備業(yè)務(wù)屬性的系統(tǒng)。業(yè)務(wù)相關(guān)性和業(yè)務(wù)無關(guān)性，是衡量中臺與平臺的唯一標(biāo)準(zhǔn)。因此，要區(qū)分中臺和平臺，只需要基于一點去考慮，就是判斷它們是否具有業(yè)務(wù)屬性。

中臺分類

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

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

定義中臺

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

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

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

2. 必由之路：構(gòu)建中臺的重要性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 未來可期：中臺展望

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

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

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

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

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

5. 作者介紹

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