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

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

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

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

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

中臺(tái)由來(lái)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

他們?cè)谇懊娴暮芏嗄陼r(shí)間里對(duì)通用的游戲素材、算法等等做了很多沉淀。

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

聊聊架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

因此就到了我們第二個(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ù)注冊(cè)發(fā)現(xiàn)、服務(wù)治理這些概念了，和微服務(wù)可以說(shuō)從認(rèn)知上沒(méi)有任何區(qū)別。

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

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

這樣很明顯的看出來(lái)問(wèn)題了。

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

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

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

就是煙囪式架構(gòu)引發(fā)出來(lái)的問(wèn)題。

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

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

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

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

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

首先，重復(fù)建設(shè)開(kāi)發(fā)，不用說(shuō)都能看出來(lái)，每次重頭搞一套，不說(shuō)開(kāi)發(fā)成本，就說(shuō)服務(wù)器和運(yùn)維成本都?jí)蝾^疼的。

第二點(diǎn)，就是系統(tǒng)之間交互協(xié)作成本直線上升，業(yè)務(wù)發(fā)展了，可能要做一些精確營(yíng)銷活動(dòng)，設(shè)計(jì)用戶畫像，對(duì)數(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ā)展，這也是后面要說(shuō)的中臺(tái)了。

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

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

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

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

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

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

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

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

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

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

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

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

服務(wù)共享

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

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

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

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

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

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

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

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

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

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

服務(wù)拆分

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

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

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

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

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

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

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

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

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

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

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

持續(xù)迭代

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

你能明白我的意思吧，我沒(méi)有在開(kāi)車。。

交易中臺(tái)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

金融中臺(tái)

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

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

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

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

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

去中臺(tái)化

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

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

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

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

好了，言盡于此吧，大家88，我是艾小仙，我們下期見(jiàn)，最近會(huì)不間歇性的保持周更的節(jié)奏，閱讀掉的有點(diǎn)狠，大家加把勁幫忙點(diǎn)贊轉(zhuǎn)發(fā)一些，感激不盡。

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

另外一些是之前公司內(nèi)部的PPT我修改的，還有一些記錄的是參考的好像阿里的一本啥書，之前看過(guò)記錄的一點(diǎn)東西，現(xiàn)在有點(diǎn)記不起來(lái)了。