在3月份寫了一篇質(zhì)疑中臺(tái)的博客，后來在網(wǎng)上又看到了《中臺(tái)，我信了你的邪 | 深氪》一文，該文早在今年1月份就指出了“中臺(tái)”架構(gòu)理念在企業(yè)實(shí)際實(shí)施中出現(xiàn)的一些問題。而近期又看到了諸多解釋企業(yè)實(shí)施中臺(tái)架構(gòu)不理想的原因分析的文章，這些解釋性文章總體的意思是說，因?yàn)榘⒗镏信_(tái)是成功的，所以中臺(tái)架構(gòu)應(yīng)該沒問題，實(shí)施不好主要是企業(yè)自己的原因，業(yè)務(wù)需求弄不清，企業(yè)自己的團(tuán)隊(duì)水平不夠，企業(yè)一把手不重視，相應(yīng)的組織架構(gòu)調(diào)整跟不上等等。我認(rèn)為不可否認(rèn)存在這些因素，而且這些因素也是那些“非數(shù)字化原生”的傳統(tǒng)企業(yè)信息化建設(shè)中或多或少一直存在的問題。但也不應(yīng)否認(rèn)，企業(yè)過去信息化和信息系統(tǒng)建設(shè)還是取得了很大的成功，很好地支撐了業(yè)務(wù)的運(yùn)轉(zhuǎn)，之所以企業(yè)會(huì)抱怨中臺(tái)實(shí)施出現(xiàn)的問題，那是因?yàn)閿?shù)字化轉(zhuǎn)型的今天，企業(yè)對(duì)采用中臺(tái)架構(gòu)來來提升業(yè)務(wù)能力抱有了極大的熱情與期望，這是中國(guó)軟件行業(yè)的好事情，非常難得并應(yīng)該珍惜。顯然，當(dāng)前中臺(tái)架構(gòu)在傳統(tǒng)企業(yè)的實(shí)踐中并未很好地滿足這種期待。所以，我們不能一味抱怨客戶，也有必要從偏理性或偏理論方面探討一下“中臺(tái)架構(gòu)”本身是否存在了誤導(dǎo)，是否有某些需要糾正的觀點(diǎn)和理念，這樣才有利于行業(yè)的發(fā)展，畢竟，中國(guó)在IT技術(shù)方面還是相對(duì)落后，絕大多都是以國(guó)外開源軟件為基礎(chǔ)構(gòu)建平臺(tái)或應(yīng)用。因此，這在里從自己的編程經(jīng)驗(yàn)與架構(gòu)經(jīng)驗(yàn)提點(diǎn)意見與建議，真誠(chéng)希望架構(gòu)師朋友們探討一番，尤其是中臺(tái)架構(gòu)的推出者和推廣者，本文如有誤解中臺(tái)理念之處，請(qǐng)及時(shí)指出和澄清，謝謝！

1.中臺(tái)架構(gòu)的定義首先更應(yīng)該是非嚴(yán)肅的架構(gòu)術(shù)語(yǔ)而非營(yíng)銷術(shù)語(yǔ)。它要經(jīng)得起真正的CTO和架構(gòu)師的質(zhì)疑。在我看來，其所使用的理念還是有些相互矛盾的地方。當(dāng)然技術(shù)與認(rèn)識(shí)是不斷進(jìn)步的，這種現(xiàn)象很正常，我們做軟件的人總是在不斷解決老問題之后發(fā)現(xiàn)新問題，然后再推翻或改進(jìn)過去認(rèn)識(shí)，不斷螺旋上升。

它強(qiáng)調(diào)中臺(tái)能夠快速構(gòu)建業(yè)務(wù)應(yīng)用，但是中臺(tái)自身卻需要慢慢演化提煉。前者看起來非常誘人，也是被大力推崇的，但是，后者卻在實(shí)際上抵消了前者的好處，甚至所付出的代價(jià)要遠(yuǎn)遠(yuǎn)大于前者所帶來的好處，二者之間存在一個(gè)收益（前者）與成本（后者）的函數(shù)關(guān)系和一個(gè)臨界區(qū)間。需要不同的企業(yè)根據(jù)自身進(jìn)行度量，或者說，中臺(tái)架構(gòu)的推行者們應(yīng)該提出度量的體系。目前，后者卻沒有被人們重視，或者說已被忽略了。我感覺這就像一個(gè)魔術(shù)師在表演魔術(shù)，比如，頭與身體分離，效果很夢(mèng)幻，但實(shí)際上人的頭和身體無法分離，所看到的效果是表面現(xiàn)象，觀眾想要的頭與身體分離可能就是根本不存在的幻覺，當(dāng)然，除非觀眾就想要這種幻覺，那又另當(dāng)別論。

中臺(tái)在強(qiáng)調(diào)去“中心化”，卻又在制造“大中臺(tái)“和“服務(wù)共享中心”。前者很好，是我們想要的，但是一個(gè)服務(wù)一旦被共享多了，必然就會(huì)產(chǎn)生“中心化”的問題，雖然不是技術(shù)上的中心化，但也是業(yè)務(wù)功能中心。想要去中心化，那么就只能減少重用（共享），增加“重復(fù)”。大家可以回想一下所有“去中心化”的技術(shù)是不是都這么干的。比如，從“中心化”的ZooKeeper的服務(wù)發(fā)現(xiàn)變?yōu)椤叭ブ行幕钡幕诹餮詡鞑サ膮f(xié)議。雖然絕對(duì)的“去中心化”很難，但是以共享為目的的服務(wù)中心是否合理仍值得商榷。

它強(qiáng)調(diào)松耦合，卻又極力推崇服務(wù)復(fù)用。前者很好，但是后者卻是增加耦合的一個(gè)重要因素，我不是說耦合不好，耦合有時(shí)候非常好，沒有耦合，事物之間就沒有了關(guān)系，那就什么都做不成。但是，在服務(wù)這個(gè)級(jí)別的功能耦合就值得商榷。一個(gè)服務(wù)被復(fù)用的越多，對(duì)這個(gè)服務(wù)的耦合就越嚴(yán)重，當(dāng)你有一個(gè)服務(wù)被所有其他服務(wù)與應(yīng)用所復(fù)用之時(shí)，這個(gè)服務(wù)就是系統(tǒng)中的上帝式服務(wù)，一旦對(duì)這個(gè)服務(wù)業(yè)務(wù)認(rèn)識(shí)發(fā)生了深刻變化，導(dǎo)致服務(wù)接口的業(yè)務(wù)語(yǔ)義發(fā)生明顯變化，那么災(zāi)難就可能產(chǎn)生。

中臺(tái)強(qiáng)調(diào)“大中臺(tái)，小前端”。如果您堅(jiān)信“二八原則”的普適性，并且，如果用代碼量來度量系統(tǒng)規(guī)模，那么系統(tǒng)關(guān)鍵部分的中臺(tái)規(guī)模應(yīng)該不大，應(yīng)該只占到整個(gè)系統(tǒng)的20%，除非，中臺(tái)不是系統(tǒng)的關(guān)鍵核心部分，或者“二八原則”不適用，又或者這里大中臺(tái)的“大”不是我所理解的系統(tǒng)代碼規(guī)模而是其他的含義，比如硬件資源的占用規(guī)模，那就另當(dāng)別論。就我個(gè)人而言，感覺還是“小中臺(tái)”才能衍生大量應(yīng)用，才符合“三生萬(wàn)物”的樸素哲學(xué)。而論證“大中臺(tái)、小前端”理念最具吸引力的則是這樣的一個(gè)比喻：前線士兵（小前端），調(diào)用后臺(tái)的導(dǎo)彈或者大炮兵（大中臺(tái)）。我認(rèn)為這里混淆了一個(gè)概念，導(dǎo)彈或者大炮兵是為了解決前線需要打擊的大量敵人的問題（大負(fù)載量），如果前線只有一個(gè)敵人，或者根本用不上導(dǎo)彈或者大炮兵，前線士兵就可以解決問題。因此，調(diào)用何種作戰(zhàn)單位（職責(zé)明確的服務(wù)類型），以及多少該作戰(zhàn)單位（服務(wù)的實(shí)例數(shù)）取決于戰(zhàn)場(chǎng)的態(tài)勢(shì)（前端，其實(shí)也很復(fù)雜），這個(gè)比喻其實(shí)更適合后臺(tái)服務(wù)動(dòng)態(tài)部署（大炮兵集群）以解性能問題（大量的敵人），這是一個(gè)使服務(wù)實(shí)例數(shù)量按負(fù)載動(dòng)態(tài)擴(kuò)展的技術(shù)問題。

如果一切都是中臺(tái)，那么一切都不是中臺(tái)。傳統(tǒng)三層（其實(shí)是多層，業(yè)務(wù)邏輯會(huì)分進(jìn)一步層）架構(gòu)中前臺(tái)UI（負(fù)責(zé)人機(jī)交互），中臺(tái)業(yè)務(wù)執(zhí)行（負(fù)責(zé)業(yè)務(wù)邏輯），后臺(tái)數(shù)據(jù)（負(fù)責(zé)數(shù)據(jù)存?。?，這個(gè)定義很嚴(yán)格。在此之前，更古老的兩層架構(gòu)之時(shí)，前臺(tái)（負(fù)責(zé)人機(jī)交互+部分業(yè)務(wù)邏輯），后臺(tái)（負(fù)責(zé)數(shù)據(jù)存取+部分業(yè)務(wù)邏輯——存儲(chǔ)過程）?！皞鹘y(tǒng)三層架構(gòu)中的中臺(tái)”是把事務(wù)處理的業(yè)務(wù)邏前臺(tái)從前、后臺(tái)中剝離出來，形成了獨(dú)立的業(yè)務(wù)服務(wù)層。受限于技術(shù)（主要是性能），無法把分析業(yè)務(wù)也從數(shù)據(jù)庫(kù)或數(shù)據(jù)倉(cāng)庫(kù)中剝離出來做成現(xiàn)在所謂的數(shù)據(jù)服務(wù)實(shí)時(shí)地參與業(yè)務(wù)處理?，F(xiàn)在把數(shù)據(jù)也叫中臺(tái)，大概是想強(qiáng)調(diào)提供“數(shù)據(jù)服務(wù)”，但是數(shù)據(jù)服務(wù)不是業(yè)務(wù)嗎？數(shù)據(jù)本身就是描述、記錄和度量業(yè)務(wù)對(duì)象、活動(dòng)過程及其結(jié)果。開發(fā)數(shù)據(jù)服務(wù)，和開發(fā)其他的業(yè)務(wù)服務(wù)沒有什么本質(zhì)不同，無論你使用了AI算法，又或者是傳統(tǒng)的線性分析和統(tǒng)計(jì)算法，在架構(gòu)層面，仍不過是業(yè)務(wù)系統(tǒng)中的“事務(wù)處理”與“分析處理”罷了，前者按照業(yè)務(wù)邏輯的因果關(guān)系處理每個(gè)業(yè)務(wù)活動(dòng)（從一個(gè)業(yè)務(wù)事實(shí)轉(zhuǎn)化為另一個(gè)業(yè)務(wù)事實(shí)而已），后者，按照業(yè)務(wù)邏輯處理大批業(yè)務(wù)活動(dòng)結(jié)果（業(yè)務(wù)事實(shí)），產(chǎn)生高級(jí)的衍生業(yè)務(wù)數(shù)據(jù)（癥狀、原因、走勢(shì)、指導(dǎo)決策），并可能進(jìn)一步參與到“事務(wù)處理”業(yè)務(wù)中。也就是說，一個(gè)完整的業(yè)務(wù)過程中，事務(wù)處理與分析處理可能會(huì)實(shí)時(shí)融合，靜止數(shù)據(jù)與運(yùn)動(dòng)數(shù)據(jù)在流計(jì)算技術(shù)的推動(dòng)下能夠很好地互動(dòng)了。那么，在云計(jì)算和流計(jì)算技術(shù)的加持下，把大規(guī)模數(shù)據(jù)分析（本質(zhì)是業(yè)務(wù)分析）做成了實(shí)時(shí)性更好的數(shù)據(jù)服務(wù)。如果數(shù)據(jù)服務(wù)的本質(zhì)是這樣，那么，數(shù)據(jù)服務(wù)應(yīng)該是傳統(tǒng)三層（多層）架構(gòu)的進(jìn)一步完整落地而已。所以，業(yè)務(wù)中臺(tái)與數(shù)據(jù)中臺(tái)這兩個(gè)概念無非是（業(yè)務(wù)的）事務(wù)處理服務(wù)和（業(yè)務(wù)的）分析處理服務(wù)的兩個(gè)漂亮的別名而已，那么“中臺(tái)”這個(gè)詞，還是回歸傳統(tǒng)定義為好（這不代表我贊同回歸來自傳統(tǒng)大單體應(yīng)用的分層架構(gòu)），以避免產(chǎn)生混亂。但是，實(shí)際上，感覺中臺(tái)概念已經(jīng)造成了混亂，還出現(xiàn)了“算法中臺(tái)”、“技術(shù)中臺(tái)”這樣的術(shù)語(yǔ)，如果沒有一個(gè)定義，我們很多人確實(shí)不知道它是指的是在物理硬件到所謂業(yè)務(wù)領(lǐng)域服務(wù)之間的所需要經(jīng)歷的操作系統(tǒng)、虛擬機(jī)、云操作系統(tǒng)、中間件平臺(tái)、身份認(rèn)證與訪問控制等基礎(chǔ)服務(wù)之間的哪一層。技術(shù)中臺(tái)的上面、下面或前面、后面或左邊、右邊還有什么？另外，TOGAF架構(gòu)方法論中，認(rèn)為架構(gòu)有四個(gè)組成部分：業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)和技術(shù)架構(gòu)，其中應(yīng)用架構(gòu)與數(shù)據(jù)架構(gòu)合起來叫做信息系統(tǒng)架構(gòu)，信息系統(tǒng)架構(gòu)與技術(shù)架構(gòu)合起來叫做IT架構(gòu)。因而，業(yè)務(wù)架構(gòu)在IT架構(gòu)之外，指導(dǎo)和驅(qū)動(dòng)IT架構(gòu)，是IT架構(gòu)的需求。中臺(tái)架構(gòu)里的業(yè)務(wù)中臺(tái)和數(shù)據(jù)中臺(tái)怎么也不應(yīng)該是對(duì)應(yīng)TOGAF的業(yè)務(wù)架構(gòu)與數(shù)據(jù)架構(gòu)吧？所以，真誠(chéng)希望提出或推廣這些中臺(tái)概念的朋友們能給出一個(gè)系統(tǒng)化的解釋，以消除混亂。要么，就讓我們回歸國(guó)際IT業(yè)主流行業(yè)術(shù)語(yǔ)，方便國(guó)內(nèi)外的同行交流。該是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)就是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)，該是微服務(wù)架構(gòu)就是微服務(wù)架構(gòu)，該是云原生技術(shù)就是云原生技術(shù)。該是什么就是什么，或者按照TOGAF架構(gòu)方法論，給出不同行業(yè)企業(yè)的業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)和技術(shù)架構(gòu)。

2. 5G、物聯(lián)網(wǎng)、流計(jì)算的發(fā)展，使得響應(yīng)式應(yīng)用等新一代云原生應(yīng)用興起，確實(shí)更需要我們對(duì)傳統(tǒng)的架構(gòu)理念、設(shè)計(jì)理念與模式進(jìn)行革新，尤其是在源于大單體的分層架構(gòu)而出的架構(gòu)概念確實(shí)需要革新，處于領(lǐng)先且務(wù)實(shí)的架構(gòu)理念推廣者有責(zé)任至少在以下方面為大家掃清困惑：

如何從傳統(tǒng)數(shù)據(jù)庫(kù)所提供各種便利的“幻覺”中解脫出來？我們很多老一代的程序員主要與Oracle為代表的關(guān)系數(shù)據(jù)庫(kù)打交道，這些關(guān)系數(shù)據(jù)庫(kù)提供了強(qiáng)大的功能（比如，事務(wù)，現(xiàn)在看起來可能是“上癮的毒品”），使我們養(yǎng)成了許多基于關(guān)系數(shù)據(jù)的設(shè)計(jì)模式和思維，已不適用于當(dāng)今時(shí)代，但這些設(shè)計(jì)理念仍然被傳承了，而缺少?gòu)V泛質(zhì)疑。比如，“絕對(duì)的現(xiàn)在”可能根本不存在。世界在持續(xù)變化，業(yè)務(wù)在不斷發(fā)生，當(dāng)前所見數(shù)據(jù)在你讀取之后可能馬上就發(fā)生了變化?！毙畔⒖偸莵碜赃^去，總是代表另一個(gè)現(xiàn)在，代表世界的另一個(gè)視圖（例如，我們所看到的太陽(yáng)總是8分20 秒前的太陽(yáng)）”。因此，在高速交易流下，查看商品“當(dāng)前庫(kù)存有多少”可能真的沒有多大實(shí)際意義。另外，很多的數(shù)據(jù)一致性方案是程序員根據(jù)傳統(tǒng)數(shù)據(jù)庫(kù)能力人為制造出來的，并非業(yè)務(wù)所必須。現(xiàn)實(shí)中的業(yè)務(wù)一致性需要根據(jù)領(lǐng)域模型中以聚合根對(duì)象為代表的“聚合”來確定，一個(gè)“聚合”才是業(yè)務(wù)一致性的最小邊界，也就是說，數(shù)據(jù)庫(kù)事務(wù)在一個(gè)以聚合根為代表的“聚合”維護(hù)服務(wù)中使用即可，真正需要跨系統(tǒng)的事務(wù)少之又少。

在領(lǐng)域模型設(shè)計(jì)方面，如何將我們從過去在模型設(shè)計(jì)中所受存儲(chǔ)容量、性能等約束之中解放出來，更好地還原領(lǐng)域業(yè)務(wù)的客觀本質(zhì)？比如，過去我們只表達(dá)當(dāng)前時(shí)間切片下業(yè)務(wù)的“快照模型”，轉(zhuǎn)變?yōu)榭梢员磉_(dá)追溯歷史的“全息模型”。比如，客戶類型，過去設(shè)計(jì)為“客戶”的一個(gè)屬性，現(xiàn)在則是一個(gè)獨(dú)立的業(yè)務(wù)對(duì)象，客戶在其生命周期中屬于哪種“客戶類型”均被該對(duì)象所記錄和管理。因此，任何可以知道任何時(shí)間點(diǎn)的客戶類型。又如，過去我們?yōu)榱斯?jié)省內(nèi)存和磁盤，把很多“值對(duì)象”設(shè)計(jì)為“實(shí)體對(duì)象”，甚至有人認(rèn)為任何數(shù)據(jù)都應(yīng)有一個(gè)ID，所謂的“One Data，One ID”。誠(chéng)然，把所有數(shù)據(jù)對(duì)象都設(shè)計(jì)為“實(shí)體對(duì)象”的好處就是，它們都有一個(gè)“唯一ID”，引用該ID就可以節(jié)省很多存儲(chǔ)，而且在單體應(yīng)用中，使用起來還比較方便。而如果設(shè)計(jì)為“值對(duì)象”就要增加值對(duì)象的拷貝，但“值對(duì)象”拷貝所產(chǎn)生的冗余是合理的，這種冗余符合值對(duì)象的天然定義，也有利于“去中心化”；另外，“值對(duì)象”還可以避免“實(shí)體對(duì)象”不變ID掩蓋數(shù)據(jù)變化所帶來的Bug或?yàn)榧m正該Bug而引起的業(yè)務(wù)邏輯復(fù)雜度?！皩?shí)體對(duì)象”和“值對(duì)象”是領(lǐng)域驅(qū)動(dòng)里面的術(shù)語(yǔ)，我個(gè)人認(rèn)為當(dāng)前時(shí)代，更應(yīng)該從業(yè)務(wù)內(nèi)涵出發(fā)而非技術(shù)便利性出發(fā)來考慮一個(gè)業(yè)務(wù)對(duì)象到底應(yīng)該是“實(shí)體對(duì)象”還是“值對(duì)象”，這是當(dāng)前領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中一個(gè)被忽視的重要問題。

在微觀與宏觀架構(gòu)方面，如何考慮不同粒度的軟件要素（函數(shù)、類、庫(kù)、微服務(wù)）之間的“耦合”，合理利用“緊耦合”與“松耦合”？并不是“松耦合（增加了獨(dú)立變化的靈活性，但降低了復(fù)用性）”都是好的，也不是“緊耦合”都是壞的（增加了依賴，但可以最大程度發(fā)揮被依賴者的價(jià)值—復(fù)用更多的功能）。歸根到底，業(yè)務(wù)系統(tǒng)中什么才是真正的“數(shù)據(jù)”，所有被存儲(chǔ)的信息都是數(shù)據(jù)嗎？“計(jì)算（一種常見的業(yè)務(wù)行為）”的本質(zhì)來源是什么？數(shù)據(jù)與行為（計(jì)算）相比，哪個(gè)更穩(wěn)定？什么樣的數(shù)據(jù)與行為應(yīng)緊密耦合。數(shù)據(jù)與數(shù)據(jù)之間、行為與行為之間，數(shù)據(jù)與行為之間到底是什么樣的耦合方式更好？以什么樣的軟件形式來體現(xiàn)耦合？換句話說，什么時(shí)候設(shè)計(jì)為函數(shù)，什么時(shí)候設(shè)計(jì)為類（什么時(shí)候用繼承、什么時(shí)候用混入與組合），什么時(shí)候設(shè)計(jì)為庫(kù)，什么時(shí)候設(shè)計(jì)為微服務(wù)，什么時(shí)候采用同步通信，什么時(shí)候采用異步通信。所以，適合于“微觀架構(gòu)（函數(shù)、類、庫(kù)）”的功能復(fù)用理念，對(duì)于宏觀架構(gòu)（微服務(wù)）并不一定適用，所以，無論提出什么樣的架構(gòu)理念，都必須對(duì)這些從微觀到宏觀的架構(gòu)問題提出具體的知指導(dǎo)原則。

最后，鑒于漂亮的PPT很可能掩蓋糟糕的代碼和設(shè)計(jì)，關(guān)鍵的中臺(tái)服務(wù)應(yīng)該開源，至少對(duì)客戶應(yīng)該開源。因?yàn)閼?yīng)用并不是業(yè)務(wù)系統(tǒng)的核心關(guān)鍵部分，又在不斷地繁榮發(fā)展，所以開源的必要性并不大。