最近公司做了一次IT應(yīng)用架構(gòu)的重構(gòu)和升級(jí)，整個(gè)流程走下來，收獲頗豐，在這里略作總結(jié)，以備后查。

階段一：煙囪式

公司老的IT架構(gòu)屬于傳統(tǒng)的“煙囪式”架構(gòu)，也就是每個(gè)業(yè)務(wù)線之間由不同的開發(fā)團(tuán)隊(duì)獨(dú)立建設(shè)，技術(shù)棧不同，互不聯(lián)系。見下圖：

階段一-煙囪式架構(gòu).png

我想這也是許多傳統(tǒng)企業(yè)的IT架構(gòu)的樣子，這樣的架構(gòu)有幾個(gè)主要的弊端：

1. 重復(fù)開發(fā)。每個(gè)業(yè)務(wù)線中間同樣的模塊會(huì)重復(fù)開發(fā)，比如會(huì)員營(yíng)銷模塊，A業(yè)務(wù)線要建一個(gè)會(huì)員營(yíng)銷系統(tǒng)，B業(yè)務(wù)線也要建一個(gè)會(huì)員營(yíng)銷系統(tǒng)，這會(huì)造成很大的開發(fā)資源浪費(fèi)；
2. 技術(shù)棧不統(tǒng)一?？赡蹵系統(tǒng)用的是Spring MVC, B系統(tǒng)用的就是Spring Boot/Cloud。這會(huì)造成公司內(nèi)部IT架構(gòu)無法統(tǒng)一規(guī)劃，且技術(shù)能力難以積累的問題；
3. 數(shù)據(jù)無法打通。A系統(tǒng)的會(huì)員存在A系統(tǒng)的MySQL庫(kù)中，B系統(tǒng)的會(huì)員存在B系統(tǒng)的Oracle庫(kù)中，如果要識(shí)別A系統(tǒng)中的001會(huì)員和B系統(tǒng)中的002會(huì)員是同一個(gè)人，也許只能在數(shù)倉(cāng)中實(shí)現(xiàn)了。

總結(jié)：這樣的架構(gòu)的好處就是可以互不影響地獨(dú)立部署獨(dú)立迭代了，適合業(yè)務(wù)線較少且比較獨(dú)立的公司采用。

階段二：平臺(tái)

在清楚了煙囪式架構(gòu)的弊端，且業(yè)務(wù)線越來越多的情況下，公司IT團(tuán)隊(duì)開始考慮平臺(tái)化的架構(gòu)，即提供一個(gè)統(tǒng)一的會(huì)員營(yíng)銷平臺(tái)來管理全集團(tuán)的會(huì)員，來配置全集團(tuán)的營(yíng)銷活動(dòng)，A系統(tǒng)和B系統(tǒng)的用戶都在平臺(tái)上進(jìn)行操作：

平臺(tái)化架構(gòu).png

在設(shè)計(jì)的過程中，我們逐漸發(fā)現(xiàn)，這樣的架構(gòu)對(duì)于像我們這樣的老系統(tǒng)來說改造成本非常之大。舉個(gè)例子，A系統(tǒng)有抽獎(jiǎng)活動(dòng)，特價(jià)活動(dòng)這兩種營(yíng)銷活動(dòng)；B系統(tǒng)有抽獎(jiǎng)活動(dòng)，簽到活動(dòng)這兩種營(yíng)銷活動(dòng)?，F(xiàn)在要做一個(gè)統(tǒng)一的會(huì)員營(yíng)銷平臺(tái)，就是讓管理者可以統(tǒng)一配置這兩個(gè)系統(tǒng)的三種活動(dòng)。但雖說都是抽獎(jiǎng)活動(dòng)，實(shí)則由于渠道、規(guī)則、限制、獎(jiǎng)品等的不同，兩種活動(dòng)其實(shí)只是活動(dòng)名稱相同而已，具體的實(shí)現(xiàn)完全不同。最終造成的結(jié)果就是雖然是平臺(tái)化了，但是實(shí)際上內(nèi)部的實(shí)現(xiàn)還是根據(jù)具體的適用系統(tǒng)而走了不同的邏輯。雖然前端看起來是一個(gè)統(tǒng)一平臺(tái)，但實(shí)際后端很大程度只是把原來兩個(gè)系統(tǒng)的代碼合并在了一起而已。對(duì)于原來兩個(gè)系統(tǒng)獨(dú)有的活動(dòng)，也還是獨(dú)立的去實(shí)現(xiàn)，并沒有節(jié)省什么開發(fā)工作量，反而因?yàn)樾枰槍?duì)那些兩個(gè)系統(tǒng)都存的在同類活動(dòng)的合并而絞盡腦汁去抽象數(shù)據(jù)結(jié)構(gòu)和邏輯流程，且一旦合并后，如果其中一個(gè)系統(tǒng)的活動(dòng)邏輯需要調(diào)整，還可能影響到另一個(gè)系統(tǒng)的同類活動(dòng)。

總結(jié)：這樣的架構(gòu)適合全新的IT應(yīng)用，即從一開始就按平臺(tái)化規(guī)劃的應(yīng)用架構(gòu)，這樣在設(shè)計(jì)之初就可以統(tǒng)一規(guī)劃營(yíng)銷活動(dòng)、會(huì)員屬性等同臺(tái)統(tǒng)一的屬性。

階段三：平臺(tái)+中臺(tái)

在被平臺(tái)化搞得頭大之時(shí)，大家轉(zhuǎn)而想到了年初看過的一本《企業(yè)IT架構(gòu)轉(zhuǎn)型之道-阿里巴巴中臺(tái)戰(zhàn)略思想與架構(gòu)實(shí)戰(zhàn)》里提到的“中臺(tái)”的概念。簡(jiǎn)單闡述下何為中臺(tái)：中臺(tái)思想即將不同業(yè)務(wù)中相同或相似的基礎(chǔ)服務(wù)沉淀到統(tǒng)一的中臺(tái)應(yīng)用中，如將所有的業(yè)務(wù)中的會(huì)員服務(wù)沉淀為會(huì)員中臺(tái)，將所有的業(yè)務(wù)中的訂單服務(wù)沉淀為訂單中臺(tái)等。將原來的業(yè)務(wù)系統(tǒng)剝離為較薄的一層“前臺(tái)”應(yīng)用，只包含該業(yè)務(wù)系統(tǒng)特有的業(yè)務(wù)邏輯。這樣做的好處有：

1. 減少重復(fù)開發(fā)。每個(gè)系統(tǒng)不再需要開發(fā)單獨(dú)的會(huì)員模塊、訂單模塊等，全都可以直接調(diào)用相應(yīng)的中臺(tái)接口。
2. 增加服務(wù)的復(fù)用性。能夠沉淀到中臺(tái)的必然是多個(gè)應(yīng)用都能夠適用的通用邏輯，自然保證了中臺(tái)服務(wù)的復(fù)用性。
3. 快速構(gòu)建前臺(tái)應(yīng)用。如果要新增一個(gè)應(yīng)用系統(tǒng)，只需要構(gòu)建薄薄的一層前臺(tái)應(yīng)用即可上線，交付時(shí)間短，開發(fā)更加靈活。
4. 數(shù)據(jù)打通。不同業(yè)務(wù)線的基礎(chǔ)中臺(tái)數(shù)據(jù)有相同的數(shù)據(jù)模型，可以統(tǒng)一調(diào)用。

正所謂它山之石可以攻玉，將中臺(tái)的構(gòu)建也納入我們的IT應(yīng)用架構(gòu)中：首先將A/B系統(tǒng)中基礎(chǔ)的會(huì)員營(yíng)銷服務(wù)沉淀到member中臺(tái)中，基礎(chǔ)的會(huì)員營(yíng)銷數(shù)據(jù)也沉淀在中臺(tái)庫(kù)中。同時(shí)將兩個(gè)系統(tǒng)中可以統(tǒng)一的營(yíng)銷活動(dòng)平臺(tái)化，將兩個(gè)系統(tǒng)中各自個(gè)性化的營(yíng)銷活動(dòng)保留在原有的“前臺(tái)”應(yīng)用中，且前臺(tái)應(yīng)用直連業(yè)務(wù)庫(kù)，可得架構(gòu)圖如下：

平臺(tái)+中臺(tái)

注：圖中的member中臺(tái)實(shí)際上是分為多個(gè)中心的，如會(huì)員中心，卡券中心等，下圖同

但這樣的設(shè)計(jì)還是有一些問題：

1. 對(duì)于A、B系統(tǒng)的用戶來說，他要配置一個(gè)營(yíng)銷活動(dòng)，可能要去業(yè)務(wù)系統(tǒng)中配置，也可能去平臺(tái)中配置，比較混亂；
2. 對(duì)于平臺(tái)化的營(yíng)銷活動(dòng)，如果調(diào)整了邏輯會(huì)影響到所有應(yīng)用系統(tǒng)；
3. 由于A、B系統(tǒng)的需求都有專門的產(chǎn)品經(jīng)理負(fù)責(zé)，且之后的需求也只會(huì)針對(duì)A、B系統(tǒng)分別提，那就會(huì)造成新的功能邏輯都分別在A、B前臺(tái)系統(tǒng)上不停的生長(zhǎng)，而沒有專人負(fù)責(zé)平臺(tái)的需求及后期規(guī)劃。

其實(shí)，上面的第3點(diǎn)恰好道出了一條架構(gòu)設(shè)計(jì)中很重要的定律——康威定律Conway’s law：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations。
設(shè)計(jì)系統(tǒng)的組織，其產(chǎn)生的設(shè)計(jì)和架構(gòu)等價(jià)于組織間的溝通結(jié)構(gòu)。

放在IT架構(gòu)中說白了就是系統(tǒng)架構(gòu)需要與組織架構(gòu)一一對(duì)應(yīng)。這條大名鼎鼎的定律之前都是只聞其名，不知其實(shí)踐。到這里我們像大徹大悟一般：除非平臺(tái)有專門的業(yè)務(wù)部門負(fù)責(zé)（比如集團(tuán)會(huì)員營(yíng)銷部之類的），否則就不應(yīng)該存在。上面第3點(diǎn)的問題也正是因?yàn)榻y(tǒng)一平臺(tái)缺乏對(duì)應(yīng)的組織造成的，即應(yīng)用架構(gòu)與組織架構(gòu)不匹配，違反了康威定律。

總結(jié)：平臺(tái)并不是不可取，平臺(tái)實(shí)際上也是一個(gè)前臺(tái)應(yīng)用，只不過需要有相應(yīng)的業(yè)務(wù)部門（組織）負(fù)責(zé)，這樣才是符合康威定律的架構(gòu)設(shè)計(jì)。

階段四：中臺(tái)

這個(gè)階段實(shí)際上就是把階段三的平臺(tái)給去掉。只留下了中臺(tái)，以及能夠找到組織架構(gòu)中對(duì)應(yīng)業(yè)務(wù)部門的前臺(tái)應(yīng)用：

中臺(tái)

對(duì)于中臺(tái)，還是將A、B系統(tǒng)的通用會(huì)員營(yíng)銷邏輯沉淀下去，如會(huì)員資產(chǎn)：積分、等級(jí)、優(yōu)惠券、訂單等。但對(duì)于特有的營(yíng)銷活動(dòng)，還是保留在業(yè)務(wù)前臺(tái)系統(tǒng)中分別實(shí)現(xiàn)。這樣既保留了系統(tǒng)獨(dú)立的業(yè)務(wù)自由度，也能將集團(tuán)范圍內(nèi)的公共數(shù)據(jù)資產(chǎn)和服務(wù)通過中臺(tái)思想進(jìn)行沉淀。且當(dāng)未來出現(xiàn)某個(gè)組織來統(tǒng)籌“平臺(tái)”時(shí)，也可以在中臺(tái)的基礎(chǔ)上很快的構(gòu)建。

以上就是最近我參與的一個(gè)IT架構(gòu)改造的經(jīng)歷。總結(jié)成一句話：

沒有最好的IT架構(gòu)，只有最合適的。