大家好，我是3y

今天給大家分享一下關(guān)于架構(gòu)和中臺的一些東西。

主要會介紹一下中臺的來源，這個大家可能都比較清楚，網(wǎng)上的文章和視頻啊一大堆。

還有就是關(guān)于架構(gòu)的發(fā)展過程不得不在中間說明一下，由此引申出來中臺的誕生。

最后聊下交易中臺和金融中臺。

中臺由來

首先，來看一下中臺的由來。

中臺的來源主要是阿里，他們在15年拜訪在芬蘭的一家游戲公司，也就是SuperCell。

這家公司非常牛逼，號稱是世界上最成功的的移動游戲公司，做出的游戲也非常有名，肯定很多人也玩過。

比如部落戰(zhàn)爭、海島奇兵等等。

我也玩過一下他們的那個游戲，不過覺得沒啥意思。

這家公司的規(guī)模只有不到200人，公司的開發(fā)模式通常都會由2-7個人的小團隊進行開發(fā)，這個在他們內(nèi)部叫做cell，這也是他們公司名字的由來。

開發(fā)過程通常是團隊內(nèi)部決定，然后用最快的時間開發(fā)出測試版本，如果受歡迎就繼續(xù)干，否則的話就迅速放棄。

產(chǎn)品失敗之后，不光不會受到懲罰，他們還會搞個party來慶祝，慶祝自己學(xué)到了新的東西。

不過我覺得挺奇葩的，要是都按照他們這個模式來，早期騰訊、阿里這些大公司都該死絕了。

我們都知道，騰訊早期的時候想賣100萬都沒人要，馬總實在沒轍才只能硬著頭皮繼續(xù)做下去。

但是，就是這樣一家小公司，2015年的凈利潤達到了15億美元，而且在2016年的時候被騰訊86億美元收購。

這些都不是重點哈，重點我們今天要講的是他們的開發(fā)模式，為什么能快速開發(fā)一個新游戲出來？

本來在我們想象中，開發(fā)一個新的游戲是一個很耗費時間精力的東西，幾周開發(fā)一個還不錯的游戲應(yīng)該是很有難度的事情。

重點就在于他們的”中臺“，也是他們多年游戲沉淀下來的東西。

他們在前面的很多年時間里對通用的游戲素材、算法等等做了很多沉淀。

這也就是后面阿里之后大力搞的中臺了。

聊聊架構(gòu)

講完中臺的來歷，在將中臺之前，我們還是要先說說架構(gòu)的發(fā)展過程。

單體架構(gòu)的時代

在我剛剛上班的時候，大概是11年、12年基本上我接觸到的項目都是這個樣子。

一個團隊的所有東西都在一塊，什么用戶注冊登錄、支付啊、訂單都在一起，經(jīng)常是改一個小東西一個大項目都要跟著發(fā)布。

一般單體的架構(gòu)都是單進程的，這也是針對我們現(xiàn)在的微服務(wù)來說的，就是打個jar包或者war包上傳就完事兒了，所有模塊都在一個進程里，如果要升級或者重啟，那整個應(yīng)用服務(wù)都要重啟。

當(dāng)然了，簡單的項目劃分模塊分層還是有的，比如我們那時候常用的MVC模式。

簡單是很簡單，但是同樣缺點也是很明顯的。

第一點就是團隊協(xié)同合作的成本高，如果說小公司沒幾個人還好，一旦業(yè)務(wù)快速發(fā)展起來，代碼量感人，剛開始上班那會兒我的電腦經(jīng)常就只能跑的動一個項目，不過好像也沒有別的項目了。

經(jīng)常改一個簡單的東西可能到處是沖突，更不要說一個大服務(wù)的發(fā)版問題。

第二點，項目太復(fù)雜了，什么東西都是大雜燴，全在里面。

第三點，數(shù)據(jù)庫連接的問題，一個服務(wù)太大了，就一個數(shù)據(jù)庫的集群，業(yè)務(wù)越來越多，服務(wù)器越來越多，到后面單機可能只搞個個位數(shù)的連接都要不夠用了。

所以，一般伴隨拆分服務(wù)，數(shù)據(jù)庫也會做拆分，獨立的服務(wù)擁有獨立的數(shù)據(jù)庫。

最后一點，拓展性的問題，所有的功能都在一個服務(wù)里，可能實際情況是某幾個功能模塊負載非常高，比如訂單或者庫存的服務(wù)，頻繁的讀寫，這時候想要擴展很難搞。

更嚴(yán)重的問題就是，如果一個模塊出了問題，整個應(yīng)用都不能用了。

這時候沒有辦法了，只能拆分。

因此就到了我們第二個架構(gòu)模式，SOA的時代。

SOA(Service-Oriented Architecture)

我在餓了么工作那會兒，里面就有一大堆的SOA的稱呼，并且一直都是。

SOA是什么意思呢，全名是這個Service-Oriented Architecture，意思就是面向服務(wù)的架構(gòu)，基本上和我們現(xiàn)在的微服務(wù)差不多一樣。

SOA的核心在于：松耦合和服務(wù)重用，當(dāng)單體架構(gòu)出現(xiàn)瓶頸的時候，首先想到的都是拆，SOA時代的話，其實也已經(jīng)就有了服務(wù)注冊發(fā)現(xiàn)、服務(wù)治理這些概念了，和微服務(wù)可以說從認知上沒有任何區(qū)別。

SOA其實有兩種模式，一種是中心化，一種是去中心化，下圖中表示的就是中心化的服務(wù)調(diào)用方式。

服務(wù)調(diào)用之間都通過ESB服務(wù)總線，調(diào)用方之間屏蔽了接口的修改，ESB要做服務(wù)請求路由、數(shù)據(jù)格式轉(zhuǎn)換，各種HTTP SOCKET適配和接入，所有臟活累活都歸他干了。

這樣很明顯的看出來問題了。

第一個就是請求，同樣的請求次數(shù)是通常去中心化的2倍，本來A調(diào)用B，現(xiàn)在要通過ESB。

第二個是肉眼可見的問題，這個ESB的壓力會非常大，可以通過集群解決，但是ESB的性能瓶頸會導(dǎo)致所有服務(wù)的瓶頸。

但是，這個模式在當(dāng)初非常受歡迎，主要原因是什么呢？

就是煙囪式架構(gòu)引發(fā)出來的問題。

煙囪式架構(gòu)是什么？

就像這張圖描述的，你有好幾個業(yè)務(wù)，因為時間或者說團隊、公司各種原因，搞成了好幾套獨立的服務(wù)，開發(fā)和運維都沒啥關(guān)系，大多數(shù)公司之前的發(fā)展過程中都會存在這樣的問題。

比如我之前的公司先做酒店業(yè)務(wù)、然后又有外賣、還有餐飲店、還要賣咖啡。

如果說來一個業(yè)務(wù)就重頭搞一套用戶體系、訂單體系、庫存體系，最終的結(jié)果就是像矗立起來的一個個煙囪，也就是煙囪式架構(gòu)。

煙囪的現(xiàn)象很普遍，大家各玩各的，先把業(yè)務(wù)跑起來再說，但是缺陷有很多。

首先，重復(fù)建設(shè)開發(fā)，不用說都能看出來，每次重頭搞一套，不說開發(fā)成本，就說服務(wù)器和運維成本都夠頭疼的。

第二點，就是系統(tǒng)之間交互協(xié)作成本直線上升，業(yè)務(wù)發(fā)展了，可能要做一些精確營銷活動，設(shè)計用戶畫像，對數(shù)據(jù)分析之類的啦，這都很正常。

哦豁，這時候你發(fā)現(xiàn)用戶在好幾個系統(tǒng)里，這個交互打通的成本就太高了。

要做個數(shù)據(jù)統(tǒng)計，還要調(diào)好幾個系統(tǒng)接口，可能數(shù)據(jù)結(jié)構(gòu)還不一樣，搞都搞死你。

還有就是業(yè)務(wù)沉淀和發(fā)展，這也是后面要說的中臺了。

難道這些系統(tǒng)之間就沒有通用的能抽象的能力可以共用嗎？

這也就是中臺的發(fā)展的方向，抽象、沉淀和共用。

微服務(wù)架構(gòu)

最后就是說到我們的微服務(wù)時代了，這個大家都很熟悉，不需要說太多東西。

至于現(xiàn)在還有Serverless、云原生什么低代碼這里就不展開了，等后面的話有機會再說。

回到微服務(wù)的話題，微服務(wù)和SOA有什么區(qū)別。

個人認為其實很接近，微服務(wù)就是更加自由和更細粒度的SOA。

微服務(wù)沒有那么多框架約束，我們想用啥用啥，雖然在SOA也可以實現(xiàn)，比如通信我們可以用Dubbo，可以用Feign，Thrift，GRPC，想用啥用啥。

舉個例子用 spring cloud 來說，eureka可以幫我們做服務(wù)注冊和發(fā)現(xiàn)，打個@enableEurekaClient就可以成為客戶端連接到Eureka了。

路由直接用zuul，限流熔斷用hystrix，負載均衡用ribbon，遠程調(diào)用用feign。

非常方便，當(dāng)然還可以選擇用Spring Cloud Alibaba，這個我認為可能會是將來一段時間的趨勢，更新維護的非常勤快。

Dubbo Nacos Sentinel這一套整起來明顯更符合國內(nèi)的使用習(xí)慣。

服務(wù)共享

說完架構(gòu)的發(fā)展，可以回到我們之前的中臺話題。

那其實中臺的作用已經(jīng)不言而喻了，就是共享。

以現(xiàn)在比較主流的一些電商來說，幾個共享服務(wù)中心的劃分。

首先用戶中心必不可少，用戶是基礎(chǔ)服務(wù)，用戶中心集成用戶通用的能力，包括注冊登錄，SSO單點登錄，還要和大數(shù)據(jù)配合用戶打標(biāo)簽，用戶畫像等。

營銷中心這個也很重要，包含各種優(yōu)惠活動、優(yōu)惠券、紅包、卡券、積分、會員等級、返傭之類的和營銷相關(guān)的東西。

交易中心處理用戶下訂單，如果下單有返傭，積分之類的話，這個叫做履約，后面再說，關(guān)于交易中臺是我后面要說的。

支付中心負責(zé)支付，退款，三方支付、銀行對接、預(yù)算管控等等。

數(shù)據(jù)中心，這個其實和業(yè)務(wù)中臺是兩塊方向，今天我要說的都是業(yè)務(wù)中臺，針對業(yè)務(wù)系統(tǒng)的沉淀和共享，數(shù)據(jù)中臺則是更偏向大數(shù)據(jù)方向的，不在這里贅述。

最底層服務(wù)是我們的基礎(chǔ)設(shè)施和中間件的能力，比如數(shù)據(jù)庫、消息服務(wù)Kafka、Rabbitmq、數(shù)倉、文件系統(tǒng)。

這張圖畫出來好像除了中臺和前臺沒別的東西了，并不是這樣，我只是想表達說共享服務(wù)是作為支撐上層業(yè)務(wù)的核心，下層還有后臺的服務(wù)并沒有畫出來而已，也就是順應(yīng)著大中臺、小前臺的架構(gòu)來說。

服務(wù)拆分

講到這個服務(wù)抽象和共享就順便說說服務(wù)拆分的原則，這個說法太多了，見仁見智，更多的是遵循原有的一些經(jīng)驗去做處理。

總的來說，現(xiàn)在我們主流的拆分都是根據(jù)業(yè)務(wù)角度去拆分。

高內(nèi)聚、低耦合，這個沒啥說的，所有的服務(wù)都應(yīng)該遵循這個原則，否則你要拆那就是瞎幾把拆。

高內(nèi)聚說的是比如交易中臺，只圍繞交易相關(guān)的、依賴性非常高的進行拆分。

低耦合則是說不同的服務(wù)，業(yè)務(wù)之間要隔離，不要耦合在一起，但是這個得有過程。

舉個例子來說一開始的業(yè)務(wù)沒什么人，用戶地址這些信息就放在用戶的服務(wù)里，好像也沒什么問題。

隨著業(yè)務(wù)的發(fā)展，這個地址信息和物流的服務(wù)好像關(guān)聯(lián)越來越大，是不是就可以拆到物流服務(wù)里。

所以，這個要用發(fā)展的眼光去看待問題，不能一刀切。

回頭去個小公司，別人就幾萬用戶，幾個程序員，就一個服務(wù)，你非要干微服務(wù)，拆幾十個服務(wù)出來，這就不對是不是。

數(shù)據(jù)完整性

其實也類似，業(yè)務(wù)相關(guān)數(shù)據(jù)一定要完整，比如你做拆分，拆分完了之后用戶名字拆到別的系統(tǒng)里去了，那就不太合理了。

持續(xù)迭代

也就是說要可持續(xù)性地做架構(gòu)升級的調(diào)整和拆分，這個還是要跟著業(yè)務(wù)的發(fā)展走，不能一下拆的太細，也不能一下子太粗。。

你能明白我的意思吧，我沒有在開車。。

交易中臺

說了好久，總算說到交易中臺了，我之前干交易中臺干了差不多兩年時間，自認為還算比較了解，除了一些東西沒有實現(xiàn)之外，由于公司發(fā)展和時間的關(guān)系。

交易中臺上面也提到過，主要就是從用戶看到商品，然后到訂單確認頁，最后下訂單，支付，配送，簽收，這樣一個整個過程都是交易中臺在做的事情。

交易的定義就是買賣雙方對有價物品和服務(wù)進行互通有無的行為，可以是以貨幣為交易媒介的過程，也可以是以物易物。

而交易過程，現(xiàn)在一般都是分為訂約和履約兩個，這基本是所有的交易中臺的規(guī)則了。

某某在什么時間做了什么事情，這是訂約。

舉個例子來說，買方給賣方提供了有價物品，比如錢，賣方需要給買方提供服務(wù)。

而履約的則是某某在約定的時間完成約定的事情，比如交付貨幣、物品或者服務(wù)。

整個流程大致就是這個樣子，當(dāng)然一般我們都會分為正向和逆向兩個方向去處理，正向完成交易的過程，逆向你可以理解為取消、退款這個環(huán)節(jié)。

既然是中臺，那么就要能適應(yīng)各類的交易場景。

比如酒店行業(yè)你去預(yù)訂房間，這是正向交易，最后你去入住、離店，這是你履約的過程。

供應(yīng)鏈要采購，然后商家會發(fā)貨，最后你簽收，這也是訂約和履約的過程。

點外賣也是同樣的道理。

這些所有的場景，那么我們都可以用通用的流程來歸納起來，就是上面提到的通用的交易流程。

抽象的概念說完了，需要再形象一點的來描述一下。

上面我們說到了一些現(xiàn)在比較常見的服務(wù)拆分和服務(wù)的劃分，下面根據(jù)實際場景看看我們服務(wù)到底是怎么劃分的。

這張圖是美團的訂單確認頁，一般也叫做提單頁。圖太長，我拆分為3個小圖來描述。

可以一起來分析一下這個頁面應(yīng)該由哪些服務(wù)來構(gòu)成，由誰來聚合這么多服務(wù)的接口？

首先地址信息上面也提到過了， 這個由用戶服務(wù)或者說是物流服務(wù)來提供比較合適。

那配送時間這方面就應(yīng)該由物流的算法來提供，他們會根據(jù)運力、天氣、騎手一堆信息來計算一個比較合理的送達時間。

中間這一部分商品的詳細信息肯定由商品服務(wù)來提供。

至于配送費啊、各種補貼、紅包優(yōu)惠券是不是該由營銷來提供，這里其實會很復(fù)雜， 因為要計算各種條件的價格，計算出最終應(yīng)該支付的金額，這個一般我們會由價格服務(wù)來輸出。

最下面這一部分叫做搭售，可以在下單的同時去購買會員，這個其實就相當(dāng)于下了兩個訂單，一單是外賣單，另外一個訂單就是搭售訂單，購買會員的訂單，最終兩個訂單合并支付，保持最終一致性就行了，下單成功，同時會員購買成功。

最終下單成功之后發(fā)送消息，物流團隊根據(jù)消息去履約配送，營銷根據(jù)下單消息該送積分、送紅包就怎么送，另外如果有搭售會員的話，還需要進行會員升級，這也是屬于履約的一部分。

這個地方還有兩個挺有意思的點。

第一個是扣庫存的問題，應(yīng)該是下單成功扣庫存，還是支付成功扣庫存（不用太考慮保存訂單和扣庫存分布式事務(wù)的問題，這個會保證最終一致性）。

一般所有的業(yè)務(wù)都會下單就扣庫存，但是這樣會有一個問題。

之前我們做活動，會把很多房間拿出來做優(yōu)惠活動，單價就會便宜，但是庫存有限，這個叫做尾房甩賣。

很多黃牛就先去下單把庫存占住，然后再賣給用戶，馬上取消訂單，幫用戶下單。

所以我們之前有兩種模式，針對這種類型的特殊情況會支付成功后才扣庫存，普通模式像電商外賣一般沒這種問題，都是下單就扣。

還有一個就是這個券的問題，不知道大家發(fā)現(xiàn)了沒有，買了會員送券，可以立刻使用，下面還標(biāo)注了，本單可用。

你肯定能想到這個問題，一般我們是券發(fā)給用戶了才能用，這里下單成功后發(fā)消息->履約->發(fā)券，這個券都還沒有怎么提前用。

這又是一個交易系統(tǒng)里比較常見的，早兩年應(yīng)該是沒有這個玩法的，也算是一個優(yōu)化，一般會叫做虛擬券。

下單的時候去核銷優(yōu)惠券，一般會給營銷傳一個特殊的標(biāo)記和參數(shù)，營銷根據(jù)這個判斷做特殊的處理，至于具體的邏輯，我也不是很清楚，搞的挺復(fù)雜的就是了。

再結(jié)合全景圖看一下就清晰了和架構(gòu)圖看一下就清晰多了。

<<< 左右滑動見更多 >>>

金融中臺

金融中臺不夠純粹，與其說是中臺，不如說是事業(yè)部更合適一點，一般現(xiàn)在國內(nèi)很多公司的金融中臺基本都逃脫不了這幾塊的內(nèi)容，很多都非常類似，就是根據(jù)不同的業(yè)務(wù)有點出入而已。

支付是整個金融中臺的核心，跳轉(zhuǎn)的統(tǒng)一收銀臺又是支付的核心。

清結(jié)算也很核心，非常重要，這個我也干過一段時間，預(yù)算，活動、券這是營銷的角度，預(yù)算則是財務(wù)金融的角度。

一般創(chuàng)建活動的時候一定要申請預(yù)算，活動創(chuàng)建設(shè)置庫存數(shù)量，同時申請財務(wù)預(yù)算，一般情況都是1：1，創(chuàng)建成功不可以修改，庫存可以臨時改，但是預(yù)算改不了，除非重新申請。

金融中臺自己領(lǐng)會好吧。

去中臺化

這一段我不能放，涉及到一些公司隱私的東西，但是可以聊聊其他的。

比如開發(fā)流程，就我經(jīng)歷過的，中臺這種部門一旦起來了，很容易一家獨大，話語權(quán)太強，并且對于穩(wěn)定性的要求太高，一定程度上阻礙了業(yè)務(wù)的開發(fā)。

其次對于業(yè)務(wù)的支撐和快速發(fā)展，其實可能沒有想象中的那么好，經(jīng)歷過的大家應(yīng)該也都會有體會的。

再者，中臺這種產(chǎn)品必然涉及了太多的政治層面的博弈，我覺得SuperCell那種小公司玩得轉(zhuǎn)確實可以，但是體量太大的公司玩的好挺難的，那體量不大的公司又沒有太大必要搞什么鬼中臺，你又不是啥游戲公司對不對，畢竟還是互聯(lián)網(wǎng)公司為主，做業(yè)務(wù)開發(fā)為主。

文章內(nèi)容參考的書是鳳凰架構(gòu)，鄒老師寫的，沒有買實體書的同學(xué)可以看看電子版的：http://icyfenix.cn/introduction/about-me.html