本文轉(zhuǎn)載自微信公眾號(hào)「人月聊IT」，作者何明璐。轉(zhuǎn)載本文請(qǐng)聯(lián)系人月聊IT公眾號(hào)。

個(gè)人從2009年就開始參與電信運(yùn)營(yíng)商的ERP集中化建設(shè)。

簡(jiǎn)單來說就是原來各個(gè)省，子公司都有的IT系統(tǒng)全部廢棄，采用全新構(gòu)建的一套集中化系統(tǒng)來滿足集團(tuán)所有省公司，專業(yè)公司的需求。

這樣建設(shè)的好處當(dāng)前是顯而易見的，即從建設(shè)成本，運(yùn)維成本，業(yè)務(wù)特別是財(cái)務(wù)管控能力提升各個(gè)方面都明顯增強(qiáng)。集中化即集約化，不僅僅是成本降低，更加重要的是集團(tuán)整體管控能力大幅提升。

09年的大集中化建設(shè)，基本還是傳統(tǒng)的單體應(yīng)用架構(gòu)，而且是IOE模式。

即采用EMC集中化存儲(chǔ)，Oracle數(shù)據(jù)庫，小型機(jī)來完成IT基礎(chǔ)設(shè)施架構(gòu)的搭建。這些IT硬件設(shè)備雖然昂貴，但是最大的好處就是高可用和高可靠，確保了IT基礎(chǔ)設(shè)施層足夠穩(wěn)定。

但是集中化建設(shè)的系統(tǒng)仍然會(huì)面臨擴(kuò)展性的問題。

即從5年到10年的長(zhǎng)周期來看，原來的IT基礎(chǔ)設(shè)施架構(gòu)是否能夠平滑擴(kuò)展支撐，就是一個(gè)關(guān)鍵問題。特別是我前面文章經(jīng)常談到的DB數(shù)據(jù)庫能力，DB數(shù)據(jù)庫集群要做到完全水平彈性擴(kuò)展很難，包括Oracle RAC集群本身也有性能極限，一般來說也就擴(kuò)展到單點(diǎn)2到3倍能力就是極限。

因此在2012年啟動(dòng)了私有云PaaS平臺(tái)建設(shè)工作，提出了平臺(tái)+應(yīng)用的構(gòu)建模式，并且參考互聯(lián)網(wǎng)的做法進(jìn)行去IOE，采用開源軟件和X86服務(wù)器進(jìn)行替代。

這個(gè)在當(dāng)前集團(tuán)信息化建設(shè)中相當(dāng)超前。

不僅僅是去IOE和開源化軟件應(yīng)用，更加重要的是進(jìn)行了組件化拆分，和當(dāng)前微服務(wù)一個(gè)道理。組件化拆分最重要的又是數(shù)據(jù)庫拆分。一個(gè)單體應(yīng)用首先按組件模塊進(jìn)行了一次拆分，拆分為多個(gè)數(shù)據(jù)庫。同時(shí)為了滿足所有省份和組織的使用，又對(duì)數(shù)據(jù)庫進(jìn)行了一次水平拆分和分片操作。

可以看到，引入了如下復(fù)雜性。

• 開源化和去IOE，從IaaS過渡到PaaS層
• 微服務(wù)拆分后的橫向集成
• 消息，緩存等技術(shù)服務(wù)縱向集成
• 數(shù)據(jù)庫拆分，包括DaaS層的分布式事務(wù)

如此多的復(fù)雜性引入，要做好是相對(duì)困難的事情。因此整個(gè)私有云PaaS平臺(tái)建設(shè)和推進(jìn)實(shí)際并不算太成功。這個(gè)不僅僅是技術(shù)的問題，還是涉及到業(yè)務(wù)，組織管控，廠商配合度各個(gè)方面的問題需要去解決。

這也再次印證了在合適的時(shí)間采用合適的技術(shù)的道理。

好了，在這里拋出今天的問題。

即使在集中化建設(shè)模式下，為了應(yīng)對(duì)高可用性和擴(kuò)展性，也會(huì)對(duì)單體應(yīng)用進(jìn)行微服務(wù)拆分，同時(shí)對(duì)數(shù)據(jù)庫進(jìn)行水平和垂直拆分來滿足性能和擴(kuò)展性要求。但是由于微服務(wù)和數(shù)據(jù)庫的拆分，在集成協(xié)同，分布式事務(wù)處理方面引入大量問題。是否有更好的思路去解決這個(gè)問題?

集團(tuán)的多組織架構(gòu)談起

一個(gè)集團(tuán)可能有很多的子公司，集中化建設(shè)的思路就是全部上一套系統(tǒng)以方便管控。一套系統(tǒng)就代表固化了一套標(biāo)準(zhǔn)的業(yè)務(wù)流程和規(guī)則，這個(gè)思路本身沒有錯(cuò)。

但是上一套系統(tǒng)難道就意味著必須所有的數(shù)據(jù)都存在在一個(gè)數(shù)據(jù)庫?

答案顯然不是。

即使在傳統(tǒng)多組織架構(gòu)下你也可以看到，集團(tuán)和子公司之間是有交互，比如全面預(yù)算管理，預(yù)算下達(dá)，財(cái)務(wù)的管控和統(tǒng)一財(cái)務(wù)報(bào)表。關(guān)鍵是項(xiàng)目的跨組織審批和確認(rèn)。

但是你會(huì)看到實(shí)際上集團(tuán)和各個(gè)子公司間的協(xié)同點(diǎn)并不多，大部分業(yè)務(wù)運(yùn)作往往在子公司內(nèi)部就可以完成。也就是集團(tuán)和子公司本身就是一種松耦合關(guān)系。

那么在這種情況下日常業(yè)務(wù)運(yùn)作并不需要數(shù)據(jù)大集中。數(shù)據(jù)大集中更多是為了后續(xù)的數(shù)據(jù)運(yùn)營(yíng)和數(shù)據(jù)分析，這個(gè)本身可以后續(xù)通過構(gòu)建類似大數(shù)據(jù)平臺(tái)，數(shù)據(jù)中臺(tái)來解決。

多套系統(tǒng)能否統(tǒng)一集中管控?

比如集團(tuán)構(gòu)建一套SCM供應(yīng)鏈系統(tǒng)。

傳統(tǒng)集中化做法就是構(gòu)建一套系統(tǒng)再微服務(wù)化拆分，然后統(tǒng)一部署，統(tǒng)一管理和運(yùn)維。但是集中化本身也帶來新問題。

• 其一是后續(xù)談下擴(kuò)展很麻煩，或者無法做到彈性擴(kuò)展。
• 其二是系統(tǒng)一旦宕機(jī)或故障，往往會(huì)影響所有組織的業(yè)務(wù)運(yùn)作

那么能否既做到所有組織用一套系統(tǒng)，又讓各套業(yè)務(wù)系統(tǒng)完全垂直化獨(dú)立部署和管控。從應(yīng)用，中間件，上層業(yè)務(wù)系統(tǒng)都形成一種分布式的單元模組。

也就是說20個(gè)組織。

那么我們開發(fā)的SCM系統(tǒng)就獨(dú)立部署20套，每個(gè)組織使用一套獨(dú)立的系統(tǒng)。當(dāng)然如果存在小型組織，也可以多個(gè)組織使用一套獨(dú)立系統(tǒng)。

組織和系統(tǒng)間形成一種松耦合，可配置的關(guān)系。

對(duì)于部署的20套系統(tǒng)又需要做到統(tǒng)一的發(fā)布和交付，統(tǒng)一的后續(xù)監(jiān)控運(yùn)維。在傳統(tǒng)模式下你會(huì)發(fā)現(xiàn)這個(gè)很難做到。

但是在當(dāng)前云原生架構(gòu)下，基于DevOps的持續(xù)集成和持續(xù)交付能力完全可以做到。也就是說雖然業(yè)務(wù)系統(tǒng)有20套，但是整體的管控只有一套，還是能夠做到集中化的管控。

在這種模式下，我們唯一需要解決的問題就是。

將涉及到集團(tuán)和子公司協(xié)同交互的能力單獨(dú)出來，構(gòu)建一個(gè)獨(dú)立的集中化系統(tǒng)來應(yīng)對(duì)這種少量集成和交付。即使這樣也可以看到，這個(gè)集中化系統(tǒng)本身不會(huì)有太重的業(yè)務(wù)數(shù)據(jù)產(chǎn)生，更多的是基于底層業(yè)務(wù)系統(tǒng)已有的API服務(wù)能力進(jìn)行組合或組裝編排。

業(yè)務(wù)系統(tǒng)按子組織拆分，也不再需要去考慮復(fù)雜的DaaS數(shù)據(jù)層和分布式事務(wù)問題。同時(shí)也建設(shè)了各個(gè)子組織之間的相互影響。

能按子組織拆分，堅(jiān)決不進(jìn)行微服務(wù)拆分

再回來談下微服務(wù)。

從單體應(yīng)用到微服務(wù)，一個(gè)重點(diǎn)就是解決傳統(tǒng)單體應(yīng)用的擴(kuò)展性問題，解決業(yè)務(wù)系統(tǒng)后續(xù)的變更影響問題。同時(shí)也方便配合敏捷開發(fā)和團(tuán)隊(duì)管理思想的推進(jìn)。

但是微服務(wù)帶來的巨大問題就是集成和協(xié)同的困難，分布式事務(wù)等。

比如前面談到集中化建設(shè)，當(dāng)集中化建設(shè)后整個(gè)業(yè)務(wù)系統(tǒng)的并發(fā)量，數(shù)據(jù)量都急劇增加。這個(gè)時(shí)候你不得不將大的單體進(jìn)行拆分，以解決擴(kuò)展性和性能問題。

但是集中化建設(shè)完全可以是業(yè)務(wù)規(guī)范流程+IT管控的集中化。

而不是說業(yè)務(wù)系統(tǒng)一定只能夠部署一套。

你完全可以按組織分別部署多套系統(tǒng)，再集中化進(jìn)行管控。按子組織拆分，自然不會(huì)涉及到單個(gè)業(yè)務(wù)系統(tǒng)具體的并發(fā)量和性能問題。

當(dāng)你按組織拆分解決了性能問題后，為何一定要繼續(xù)拆分微服務(wù)呢?

實(shí)際上你也可以看到，按組織進(jìn)行拆分，為每個(gè)組織分配一套系統(tǒng)，但是又對(duì)系統(tǒng)進(jìn)行統(tǒng)一管控，這才是最佳的做法。這種成本投入遠(yuǎn)遠(yuǎn)小于拆分微服務(wù)方式。

統(tǒng)一納管-DevOps和容器云

傳統(tǒng)模式下，要部署和管理20套相同的系統(tǒng)是相對(duì)困難的事情。

但是在容器云和DevOps快速發(fā)展下，已經(jīng)具備了持續(xù)集成和持續(xù)交付的能力，同時(shí)可以通過容器云來實(shí)現(xiàn)資源的快速擴(kuò)展。

比如我們可以預(yù)留20臺(tái)計(jì)算節(jié)點(diǎn)資源，在統(tǒng)一監(jiān)控20套業(yè)務(wù)系統(tǒng)，如果發(fā)現(xiàn)有明顯的性能問題后，可以動(dòng)態(tài)的對(duì)某組應(yīng)用進(jìn)行資源擴(kuò)展操作。而這些操作都可以通過k8s來快速完成動(dòng)態(tài)調(diào)度和資源分配。

由于云原生下的不可變基礎(chǔ)設(shè)施，也更加方便了確保多套系統(tǒng)使用同樣一套部署版本和鏡像，確保了業(yè)務(wù)系統(tǒng)本身的版本統(tǒng)一性。

當(dāng)然，我們還可以基于這種分布式單元架構(gòu)，實(shí)現(xiàn)各組系統(tǒng)之間的相互冗余和熱備能力。比如將A組織對(duì)應(yīng)的A套系統(tǒng)的數(shù)據(jù)，異步的準(zhǔn)時(shí)候同步到B套系統(tǒng)。那么在A套系統(tǒng)發(fā)生系統(tǒng)故障的時(shí)候，可以快速的通過流量切換將A組織的全部訪問切換到B系統(tǒng)上來滿足A系統(tǒng)的高可用。