TL;DR(too long don't read)

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

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

[[279237]]

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

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

[[279238]]

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

我們從系統上，也可以創造這樣的一些中臺。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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