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

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

開發(fā)

架構

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

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

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

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

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

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

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

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

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

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

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

這個在當前集團信息化建設中相當超前。

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

可以看到，引入了如下復雜性。

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

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

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

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

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

集團的多組織架構談起

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

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

答案顯然不是。

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

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

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

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

比如集團構建一套SCM供應鏈系統(tǒng)。

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

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

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

也就是說20個組織。

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

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

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

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

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

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

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

能按子組織拆分，堅決不進行微服務拆分

再回來談下微服務。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

標題名稱：企業(yè)信息化大集中化建設應重回分布式單元架構
本文地址：http://www.dlmjj.cn/article/djepdih.html