-
星空下载：企业信息化大集中化建设应重回分布式单元架构
- 时间：2024-07-26 来源：zoc7RcITctunhMtq7EzA 人气：
本文转载自微信公众号「人月聊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层 微服务拆分后的横向集成 消息，缓存等技术服务纵向集成
如此多的复杂性引入，要做好是相对困难的事情。因此整个私有云PaaS平台建设和推进实际并不算太成功。这个不仅仅是技术的问题，还是涉及到业务，组织管控，厂商配合度各个方面的问题需要去解决。
这也再次印证了在合适的时间采用合适的技术的道理。
好了，在这里抛出今天的问题。
即使在集中化建设模式下，为了应对高可用性和扩展性，也会对单体应用进行微服务拆分，同时对数据库进行水平和垂直拆分来满足性能和扩展性要求星空入口。但是由于微服务和数据库的拆分，在集成协同，分布式事务处理方面引入大量问题。是否有更好的思路去解决这个问题?
集团的多组织架构谈起一个集团可能有很多的子公司，集中化建设的思路就是全部上一套系统以方便管控。一套系统就代表固化了一套标准的业务流程和规则，这个思路本身没有错。
但是上一套系统难道就意味着必须所有的数据都存在在一个数据库?
答案显然不是。
即使在传统多组织架构下你也可以看到，集团和子公司之间是有交互，比如全面预算管理，预算下达，财务的管控和统一财务报表。关键是项目的跨组织审批和确认。星空官网
但是你会看到实际上集团和各个子公司间的协同点并不多，大部分业务运作往往在子公司内部就可以完成。也就是集团和子公司本身就是一种松耦合关系。
那么在这种情况下日常业务运作并不需要数据大集中。数据大集中更多是为了后续的数据运营和数据分析，这个本身可以后续通过构建类似大数据平台，数据中台来解决。
多套系统能否统一集中管控?比如集团构建一套SCM供应链系统。
传统集中化做法就是构建一套系统再微服务化拆分，然后统一部署，统一管理和运维。但是集中化本身也带来新问题。星空app
其一是后续谈下扩展很麻烦，或者无法做到弹性扩展。 其二是系统一旦宕机或故障，往往会影响所有组织的业务运作那么能否既做到所有组织用一套系统，又让各套业务系统完全垂直化独立部署和管控。从应用，中间件，上层业务系统都形成一种分布式的单元模组。
也就是说20个组织。
那么我们开发的SCM系统就独立部署20套，每个组织使用一套独立的系统。当然如果存在小型组织，也可以多个组织使用一套独立系统。
组织和系统间形成一种松耦合，可配置的关系。
对于部署的20套系统又需要做到统一的发布和交付，统一的后续监控运维。在传统模式下你会发现这个很难做到。
但是在当前云原生架构下，基于DevOps的持续集成和持续交付能力完全可以做到。也就是说虽然业务系统有20套，但是整体的管控只有一套，还是能够做到集中化的管控。
在这种模式下，我们唯一需要解决的问题就是。
将涉及到集团和子公司协同交互的能力单独出来，构建一个独立的集中化系统来应对这种少量集成和交付。即使这样也可以看到，这个集中化系统本身不会有太重的业务数据产生，更多的是基于底层业务系统已有的API服务能力进行组合或组装编排。
业务系统按子组织拆分，也不再需要去考虑复杂的DaaS数据层和分布式事务问题。同时也建设了各个子组织之间的相互影响。
再回来谈下微服务。
从单体应用到微服务，一个重点就是解决传统单体应用的扩展性问题，解决业务系统后续的变更影响问题。同时也方便配合敏捷开发和团队管理思想的推进。
但是微服务带来的巨大问题就是集成和协同的困难，分布式事务等。
比如前面谈到集中化建设，当集中化建设后整个业务系统的并发量，数据量都急剧增加。这个时候你不得不将大的单体进行拆分，以解决扩展性和性能问题。
但是集中化建设完全可以是业务规范流程+IT管控的集中化。
而不是说业务系统一定只能够部署一套。星空下载
你完全可以按组织分别部署多套系统，再集中化进行管控。按子组织拆分，自然不会涉及到单个业务系统具体的并发量和性能问题星空体育。
当你按组织拆分解决了性能问题后，为何一定要继续拆分微服务呢?
实际上你也可以看到，按组织进行拆分，为每个组织分配一套系统，但是又对系统进行统一管控，这才是最佳的做法。这种成本投入远远小于拆分微服务方式。
统一纳管-DevOps和容器云传统模式下，要部署和管理20套相同的系统是相对困难的事情。
但是在容器云和DevOps快速发展下，已经具备了持续集成和持续交付的能力，同时可以通过容器云来实现资源的快速扩展。
比如我们可以预留20台计算节点资源，在统一监控20套业务系统，如果发现有明显的性能问题后，可以动态的对某组应用进行资源扩展操作。而这些操作都可以通过k8s来快速完成动态调度和资源分配。
由于云原生下的不可变基础设施，也更加方便了确保多套系统使用同样一套部署版本和镜像，确保了业务系统本身的版本统一性。
当然，我们还可以基于这种分布式单元架构，实现各组系统之间的相互冗余和热备能力。比如将A组织对应的A套系统的数据，异步的准时候同步到B套系统。那么在A套系统发生系统故障的时候，可以快速的通过流量切换将A组织的全部访问切换到B系统上来满足A系统的高可用。
星空平台
