企业信息化大集中化建设应重回分布式单元架构

发布时间：2025-11-05 15:22:36 来源：码上建站 作者：IT科技类资讯

本文转载自微信公众号「人月聊IT」，企业作者何明璐。信息转载本文请联系人月聊IT公众号。化大化建

个人从2009年就开始参与电信运营商的集中ERP集中化建设。

简单来说就是设应式单原来各个省，子公司都有的分布IT系统全部废弃，采用全新构建的元架一套集中化系统来满足集团所有省公司，专业公司的企业需求。

这样建设的信息好处当前是显而易见的，即从建设成本，化大化建运维成本，集中业务特别是设应式单财务管控能力提升各个方面都明显增强。集中化即集约化，分布不仅仅是元架成本降低，更加重要的企业是集团整体管控能力大幅提升。

09年的大集中化建设，基本还是传统的单体应用架构，而且是IOE模式。服务器托管

即采用EMC集中化存储，Oracle数据库，小型机来完成IT基础设施架构的搭建。这些IT硬件设备虽然昂贵，但是最大的好处就是高可用和高可靠，确保了IT基础设施层足够稳定。

但是集中化建设的系统仍然会面临扩展性的问题。

即从5年到10年的长周期来看，原来的IT基础设施架构是否能够平滑扩展支撑，就是一个关键问题。特别是我前面文章经常谈到的DB数据库能力，DB数据库集群要做到完全水平弹性扩展很难，包括Oracle RAC集群本身也有性能极限，一般来说也就扩展到单点2到3倍能力就是极限。

因此在2012年启动了私有云PaaS平台建设工作，提出了平台+应用的构建模式，并且参考互联网的做法进行去IOE，b2b信息网采用开源软件和X86服务器进行替代。

这个在当前集团信息化建设中相当超前。

不仅仅是去IOE和开源化软件应用，更加重要的是进行了组件化拆分，和当前微服务一个道理。组件化拆分最重要的又是数据库拆分。一个单体应用首先按组件模块进行了一次拆分，拆分为多个数据库。同时为了满足所有省份和组织的使用，又对数据库进行了一次水平拆分和分片操作。

可以看到，引入了如下复杂性。

如此多的复杂性引入，要做好是相对困难的事情。因此整个私有云PaaS平台建设和推进实际并不算太成功。这个不仅仅是技术的问题，还是企商汇涉及到业务，组织管控，厂商配合度各个方面的问题需要去解决。

这也再次印证了在合适的时间采用合适的技术的道理。

好了，在这里抛出今天的问题。

即使在集中化建设模式下，为了应对高可用性和扩展性，也会对单体应用进行微服务拆分，同时对数据库进行水平和垂直拆分来满足性能和扩展性要求。但是由于微服务和数据库的拆分，在集成协同，分布式事务处理方面引入大量问题。是否有更好的思路去解决这个问题?

集团的多组织架构谈起

一个集团可能有很多的子公司，集中化建设的思路就是全部上一套系统以方便管控。一套系统就代表固化了一套标准的业务流程和规则，这个思路本身没有错。

但是上一套系统难道就意味着必须所有的数据都存在在一个数据库?

答案显然不是。

即使在传统多组织架构下你也可以看到，集团和子公司之间是有交互，比如全面预算管理，预算下达，财务的管控和统一财务报表。关键是项目的跨组织审批和确认。

但是你会看到实际上集团和各个子公司间的协同点并不多，大部分业务运作往往在子公司内部就可以完成。也就是集团和子公司本身就是一种松耦合关系。

那么在这种情况下日常业务运作并不需要数据大集中。数据大集中更多是为了后续的数据运营和数据分析，这个本身可以后续通过构建类似大数据平台，数据中台来解决。

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

比如集团构建一套SCM供应链系统。

传统集中化做法就是构建一套系统再微服务化拆分，然后统一部署，统一管理和运维。但是集中化本身也带来新问题。

那么能否既做到所有组织用一套系统，又让各套业务系统完全垂直化独立部署和管控。从应用，中间件，上层业务系统都形成一种分布式的单元模组。

也就是说20个组织。

那么我们开发的SCM系统就独立部署20套，每个组织使用一套独立的系统。当然如果存在小型组织，也可以多个组织使用一套独立系统。

组织和系统间形成一种松耦合，可配置的关系。

对于部署的20套系统又需要做到统一的发布和交付，统一的后续监控运维。在传统模式下你会发现这个很难做到。

但是在当前云原生架构下，基于DevOps的持续集成和持续交付能力完全可以做到。也就是说虽然业务系统有20套，但是整体的管控只有一套，还是能够做到集中化的管控。

在这种模式下，我们唯一需要解决的问题就是。

将涉及到集团和子公司协同交互的能力单独出来，构建一个独立的集中化系统来应对这种少量集成和交付。即使这样也可以看到，这个集中化系统本身不会有太重的业务数据产生，更多的是基于底层业务系统已有的API服务能力进行组合或组装编排。

业务系统按子组织拆分，也不再需要去考虑复杂的DaaS数据层和分布式事务问题。同时也建设了各个子组织之间的相互影响。

能按子组织拆分，坚决不进行微服务拆分

再回来谈下微服务。

从单体应用到微服务，一个重点就是解决传统单体应用的扩展性问题，解决业务系统后续的变更影响问题。同时也方便配合敏捷开发和团队管理思想的推进。

但是微服务带来的巨大问题就是集成和协同的困难，分布式事务等。

比如前面谈到集中化建设，当集中化建设后整个业务系统的并发量，数据量都急剧增加。这个时候你不得不将大的单体进行拆分，以解决扩展性和性能问题。

但是集中化建设完全可以是业务规范流程+IT管控的集中化。

而不是说业务系统一定只能够部署一套。

你完全可以按组织分别部署多套系统，再集中化进行管控。按子组织拆分，自然不会涉及到单个业务系统具体的并发量和性能问题。

当你按组织拆分解决了性能问题后，为何一定要继续拆分微服务呢?

实际上你也可以看到，按组织进行拆分，为每个组织分配一套系统，但是又对系统进行统一管控，这才是最佳的做法。这种成本投入远远小于拆分微服务方式。

统一纳管-DevOps和容器云

传统模式下，要部署和管理20套相同的系统是相对困难的事情。

但是在容器云和DevOps快速发展下，已经具备了持续集成和持续交付的能力，同时可以通过容器云来实现资源的快速扩展。

比如我们可以预留20台计算节点资源，在统一监控20套业务系统，如果发现有明显的性能问题后，可以动态的对某组应用进行资源扩展操作。而这些操作都可以通过k8s来快速完成动态调度和资源分配。

由于云原生下的不可变基础设施，也更加方便了确保多套系统使用同样一套部署版本和镜像，确保了业务系统本身的版本统一性。

当然，我们还可以基于这种分布式单元架构，实现各组系统之间的相互冗余和热备能力。比如将A组织对应的A套系统的数据，异步的准时候同步到B套系统。那么在A套系统发生系统故障的时候，可以快速的通过流量切换将A组织的全部访问切换到B系统上来满足A系统的高可用。

相关文章