TL;DR(too long don't read)

1、業(yè)務中臺就是流程模板+擴展點

2、沒法很好抽象就別做中臺，沒那么多需求和業(yè)務線就別做中臺。

[[279237]]

很多同學都會問，啥叫中臺，做到怎么樣的程度才算中臺?我們可以用一小批一小批精英海空陸戰(zhàn)隊來說明這個例子。

我們都知道海空陸戰(zhàn)隊很厲害，但是他們不就區(qū)區(qū) 3-7 人小組，強在哪里?

[[279238]]

原來背后有個強大的中臺體系，正在海上待命，隨時輸送彈藥。一旦3人小組偵查到地方精確位置，直接派空軍或者導彈往目標上送，作戰(zhàn)能力max。

我們從系統(tǒng)上，也可以創(chuàng)造這樣的一些中臺。

業(yè)務中臺，提供重用服務，例如用戶中心、訂單中心之類的開箱即用可重用能力。算法中臺，提供算法能力，幫助提供更加個性化的服務，增強用戶體驗。數(shù)據(jù)中臺，為公司內(nèi)外提供行業(yè)決策基礎服務，增強數(shù)據(jù)的應用能力。技術中臺，提供自建系統(tǒng)部分的技術支撐能力，幫助解決基礎設施，分布式數(shù)據(jù)庫等底層技術問題。研發(fā)中臺，提供自建系統(tǒng)部分的管理和技術實踐支撐能力，幫助快速搭建項目、管理進度、測試、持續(xù)集成、持續(xù)交付。

總之，我們把這些能夠保證前臺需求絕大部分能力開箱即用，但又能快速響應前臺需求迭代的服務，我們稱為中臺。

什么叫快速響應需求迭代呢?為什么要有中臺呢?是否需要搭建中臺呢?我們今天只從業(yè)務中臺的理念上，來梳理一下一個中臺的定位。接下來我們通過一個登錄服務實例，從大家熟知的構(gòu)建一個登錄服務平臺到構(gòu)建登錄服務中臺，比較平臺與中臺的差異，看看怎么做到快速響應需求迭代。

根據(jù)我們的設計一個登錄服務平臺，大體需要提供發(fā)送驗證碼，注冊，登錄，登出，身份/權限驗證 等服務。

開始總是分分鐘都妙不可言，我們設計的平臺總能非常好地滿足業(yè)務的訴求，對于一些需要擴展平臺能力的地方，也響應得比較及時。但是，慢慢的，事情好像出了一些變化。在平臺的發(fā)展過程中，業(yè)務方越來越多，需求也越來越復雜。

A業(yè)務系統(tǒng)想指定特定的校驗碼平臺，而這個校驗碼模式我們是沒有對接過的。平臺開發(fā)人員和業(yè)務只好撲騰撲騰派兩個人去對接。B業(yè)務系統(tǒng)來了，說想在登錄失敗N次后，給用戶發(fā)送短信提醒，發(fā)送郵件提醒，平臺開發(fā)人員和業(yè)務只好撲騰撲騰派兩個人去接這些需求。C業(yè)務也來了。D業(yè)務也來了。慢慢的，這個所謂的平臺，已經(jīng)沒有任何人在做平臺了。

本來我們設計拆分前臺與后臺，是為了讓前臺來滿足用戶需求的快速迭代，期望后臺趨于穩(wěn)定。當我們平臺開發(fā)人員并不能確保我們能搞清楚業(yè)務人員的需求是產(chǎn)品經(jīng)理拍腦袋，還是實際需求時，大量頻繁地平臺開發(fā)，甚至規(guī)則變更。無論對平臺的穩(wěn)定性和業(yè)務團隊來說，都是災難性的。很爆炸。

那怎么解呢?中臺就能解?怎么解?

為了解決這樣的問題，我們把上述登錄服務抽象成一個標準的 模板流程：

輸入賬密 -> 驗證碼校驗(默認為平臺實現(xiàn)，可在平臺選擇或下載SDK擴展)-> 賬密校驗 -> 賬密校驗后身份校驗(默認為平臺實現(xiàn)，可在平臺選擇或者下載SDK擴展)-> 登錄失敗次數(shù)后續(xù)動作擴展(下載SDK，每次登錄都會調(diào)用該用戶自定義擴展)。

三個擴展點，驗證碼校驗，身份校驗，登錄失敗后續(xù)動作。這三個動作，平臺可以提供幾種默認的實現(xiàn)，也支持業(yè)務系統(tǒng)自定義。當業(yè)務系統(tǒng)有相應的需求時，可以自行開發(fā)，生成SDK，嵌入到平臺運行時上，根據(jù)請求內(nèi)容指定執(zhí)行擴展動作。這樣就確保了服務的穩(wěn)定，釋放了服務團隊的壓力。

我們再把場景回到A系統(tǒng)，他不是想要一個自己的驗證碼嗎?行，丟一份文檔，讓A系統(tǒng)團隊自行進行實現(xiàn)驗證碼校驗的擴展，然后再以插件的形式部署到中臺上。

我們繼續(xù)場景回到B系統(tǒng)，他不是想要登錄失敗3次后發(fā)送短信通知嗎。行，丟一份文檔，讓A系統(tǒng)團隊自行進行實現(xiàn)登錄失敗后續(xù)動作的擴展，然后再以插件的形式部署到中臺上。

看看，就這簡單的 模板流程+擴展點 的實現(xiàn)，把中臺的開發(fā)人員從繁雜的業(yè)務系統(tǒng)里解救出來了。如果某個擴展點的實現(xiàn)，使用方非常多使用頻率非常高，那么這個擴展點實現(xiàn)可以直接作為平臺的默認擴展選項出現(xiàn)。

怎么理解這個擴展呢?假設我們是一個廚房，我這里有桂皮，八角，糖。然后某一天我要鹵蛋，我要怎么做呢?我要調(diào)料，按配方慢慢稱出桂皮1小塊，八角3個，糖5克。然后第二天，我又要重新一個一個配調(diào)料。而且還有三十個小伙伴也想自己開鹵蛋攤。我就把之前那個配方，直接鹵成一大桶醬汁，命名為鹵蛋1號醬汁。然后過兩天，一個高人告訴我，糖再加2g，顏色可以更深一點，但是只用一次，所以我沒對這個配方進行命名。又過了兩天，大家都更喜歡這個高人的配方，說特別好吃，所以三十個小伙伴都找這個配方，我作為中臺當然察覺到這種趨勢，我就把這個配方命令為鹵蛋2號醬汁，并直接把這一大桶2號醬汁打包出售，這樣鹵蛋攤主又可以繼續(xù)開箱即用了。

你看，效率多高?不需要每個鹵蛋攤主都會調(diào)醬汁，而且一旦鹵蛋攤主有自己的配方，也可以非常方便地把之前的配方改一下。

是否有眾多好的標準流程模板，是衡量一個模板+擴展點是不是一個業(yè)務中臺的標準。

說了這么多是否需要搭建中臺呢?從例子中我們可以了解到，1、中臺需要將實際的業(yè)務或技術沉淀抽象，想做好就需要有扎實的業(yè)務技術抽象能力。2、當產(chǎn)品條線很多，業(yè)務擴展需求很多時，搭建中臺才更有價值，而產(chǎn)品條線少，業(yè)務擴展需求少時，中臺并不經(jīng)濟。