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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

集團的多組織架構談起

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

但是上一套系統難道就意味著必須所有的數據都存在在一個數據庫?

答案顯然不是。

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

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

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

多套系統能否統一集中管控?

比如集團構建一套SCM供應鏈系統。

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

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

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

也就是說20個組織。

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

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

對于部署的20套系統又需要做到統一的發布和交付，統一的后續監控運維。在傳統模式下你會發現這個很難做到。

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

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

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

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

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

再回來談下微服務。

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

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

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

但是集中化建設完全可以是業務規范流程+IT管控的集中化。

而不是說業務系統一定只能夠部署一套。

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

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

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

統一納管-DevOps和容器云

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

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

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

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

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