企業(yè)信息化大集中化建設(shè)應(yīng)重回分布式單元架構(gòu)

作者：何明璐 2022-01-10 11:51:14

開發(fā)

架構(gòu)

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

睢寧縣ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)建站的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18982081108（備注：SSL證書合作）期待與您的合作！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

答案顯然不是。

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

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

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

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

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

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

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

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

也就是說20個組織。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

文章名稱：企業(yè)信息化大集中化建設(shè)應(yīng)重回分布式單元架構(gòu)
地址分享：http://m.5511xx.com/article/djepdih.html