公司內(nèi)做的一個(gè)簡單的分享，文章內(nèi)容是我根據(jù)自己講的還有錄音又手?jǐn)]了一遍，累，口語化的做簡單修改。

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

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

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

最后會(huì)就關(guān)于交易中臺(tái)和金融中臺(tái)做一個(gè)介紹，因?yàn)槲易罱鼉赡暝谄渌咀龅囊粋€(gè)是交易中臺(tái)，還有一個(gè)就是金融中臺(tái)相關(guān)的業(yè)務(wù)。

中臺(tái)由來

首先，來看一下中臺(tái)的由來。

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

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

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

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

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

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

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

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

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

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

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

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

重點(diǎn)就在于他們的”中臺(tái)“，也是他們多年游戲沉淀下來的東西。

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

這也就是后面阿里之后大力搞的中臺(tái)了。

聊聊架構(gòu)

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

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

在我剛剛上班的時(shí)候，大概是11年、12年基本上我接觸到的項(xiàng)目都是這個(gè)樣子。

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

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

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

簡單是很簡單，但是同樣缺點(diǎn)也是很明顯的。

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

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

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

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

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

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

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

這時(shí)候沒有辦法了，只能拆分。

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

SOA(Service-Oriented Architecture)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

個(gè)人認(rèn)為其實(shí)很接近，微服務(wù)就是更加自由和更細(xì)粒度的SOA。

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

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

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

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

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

服務(wù)共享

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

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

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

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

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

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

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

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

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

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

服務(wù)拆分

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

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

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

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

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

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

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

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

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

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

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

持續(xù)迭代

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

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

交易中臺(tái)

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

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

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

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

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

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

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

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

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

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

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

點(diǎn)外賣也是同樣的道理。

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

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

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

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

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

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

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

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

至于配送費(fèi)啊、各種補(bǔ)貼、紅包優(yōu)惠券是不是該由營銷來提供，這里其實(shí)會(huì)很復(fù)雜， 因?yàn)橐?jì)算各種條件的價(jià)格，計(jì)算出最終應(yīng)該支付的金額，這個(gè)一般我們會(huì)由價(jià)格服務(wù)來輸出。

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

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

這個(gè)地方還有兩個(gè)挺有意思的點(diǎn)。

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

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

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

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

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

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

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

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

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

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

<<< 左右滑動(dòng)見更多 >>>

金融中臺(tái)

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

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

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

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

金融中臺(tái)自己領(lǐng)會(huì)好吧。

去中臺(tái)化

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

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

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

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

好了，言盡于此吧，大家加把勁幫忙點(diǎn)贊轉(zhuǎn)發(fā)一些，感激不盡。