本文转载自微信公众号《谈IT》，作者何明禄。转载本文请联系悦潮IT公众号。从2009年开始，个人开始参与电信运营商ERP的集中建设，简单来说，就是将各省、分公司原有的IT系统全部抛弃，采用全新建设的集中系统，满足各省的需求。集团公司和专业公司。目前这样建设的好处是显而易见的，即建设成本、运维成本、业务尤其是财务管控能力等各方面都得到了显着提升。集约化意味着集约化，不仅是成本的降低，更重要的是集团的整体管控能力得到了极大的提升。2009年的大规模中心化建设，基本上还是传统的单体应用架构，是IOE模式。即采用EMC集中存储、Oracle数据库、小型机完成IT基础设施建设。这些IT硬件设备虽然价格不菲，但最大的好处就是高可用性和高可靠性，保证IT基础设施层足够稳定。但是，集中构建系统仍然面临着可扩展性的问题。也就是说，从5到10年的长远来看，原有的IT基础架构能否顺利扩展和支撑是一个关键问题。尤其是之前文章经常讲到的DB数据库能力。DB数据库集群，包括OracleRAC集群本身，很难实现完全的水平弹性扩展。限制。因此，2012年启动私有云PaaS平台建设，提出平台+应用的建设模式，并参照互联网实践去掉IOE，开源软件和X86服务器用来代替它。这在当前的集团信息化建设中是相当先进的。不仅仅是去掉IOE和开源软件应用，更重要的是拆分成组件，这和现在的微服务是一样的。组件拆分最重要的是数据库拆分。单体应用程序首先被组件模块拆分成多个数据库。同时，为了满足各省各组织的需求，对数据库进行了水平拆分和分片操作。可以看出，引入了以下复杂性。开源去IOE，从IaaS层过渡到PaaS层，横向整合消息、缓存等技术服务，纵向整合数据库拆分，包括在DaaS层引入这么多分布式事务的复杂性，相对要做好困难的事情。所以，整个私有云PaaS平台的建设和推广其实并不是很成功。这不仅仅是一个技术问题，还涉及商业、组织控制、厂商合作等方面。这再次印证了在正确的时间采用正确的技术的道理。好了，今天的问题就抛到这里了。即使在集中式构建模式下，为了应对高可用和可扩展性，也会对单体应用进行微服务拆分，对数据库进行横向拆分和纵向拆分，以满足性能和扩展性需求。但是，由于微服务和数据库的拆分，在集成协作和分布式事务处理方面引入了大量问题。有没有更好的方法来解决这个问题？集团的多组织架构说到一个集团可能有很多子公司，集中建设的思路就是实行一套制度，方便管控。系统代表了一套固化的标准业务流程和规则，这个想法本身并没有错。但是以前的系统是不是意味着所有的数据都必须存在于一个数据库中呢？答案显然不是。即使在传统的多组织架构下，也可以看到集团与子公司之间存在着互动，如全面预算管理、预算分配、财务控制、统一财务报表等。关键是项目的跨组织批准和验证。但是你会看到，其实集团和各个子公司之间并没有多少协同效应，大部分的业务运作往往都可以在子公司内部完成。也就是说，集团与其子公司本身就是一种松耦合关系。那么在这种情况下，日常的业务运营不需要大数据集中。数据去中心化更多是为了后续的数据操作和数据分析，这本身可以通过搭建类似的大数据平台和数据中台来解决。多个系统能否集中管理和控制？例如，集团构建SCM供应链系统。传统的中心化方式是搭建一套系统拆分成微服务，然后统一部署，统一管理，统一维护。但是集中化本身也带来了新的问题。一是后面谈扩容很麻烦，或者无法实现弹性扩容。二是一旦系统宕机或出现故障，往往会影响到所有组织的业务运营。那么能否让所有组织都使用一个系统，让各个业务系统完全垂直，独立部署和控制。应用程序、中间件和上层业务系统都构成一个分布式单元模块。那是20个组织。然后我们会独立部署20套SCM系统，每个组织使用独立的系统。当然，如果有小机构，多个机构可以使用一个独立的系统。组织和系统之间形成松散耦合和可配置的关系。对于部署的20个系统，需要统一发布交付，统一后续监控和运维。在传统模式下，您会发现这很难做到。但是在目前的云原生架构下，基于DevOps的持续集成和持续交付能力是完全可以实现的。也就是说，虽然有20套业务系统，但只有一套统筹管控，仍然可以做到集中管控。在这种模式下，我们唯一需要解决的问题是。与集团和子公司的协同交互能力是分离的，建立一个独立的中心化系统来处理这个小量的集成和交付。即便如此，可以看出，这个中心化系统本身并没有产生过多的业务数据，更多的是基于底层业务系统已有的API服务能力进行组合或组装而成。业务系统按子组织拆分，不再需要考虑复杂的DaaS数据层和分布式事务问题。同时，各个子组织之间的相互影响也建立起来。可以按照分组织拆分，坚决不拆分微服务再回来谈微服务。从单体应用到微服务，其中一个关键点就是要解决传统单体应用的扩展性问题，解决业务系统后续变更的影响。同时也方便配合敏捷开发和团队管理思想的进步。但是微服务带来的巨大问题是集成协作困难、分布式事务等，比如我们前面提到的集中式建设。集中建设后，整个业务系统的并发量和数据量都会急剧增加。这时候就得把大单体拆分出来解决扩展性和性能问题。而集中建设完全可以是业务规范流程+IT管控的集中。并不是说只能部署一套业务系统。您可以按组织分别部署多个系统，然后集中管理和控制。分组织拆分自然不涉及单个业务系统具体的并发和性能问题。你通过组织拆分解决了性能问题之后，为什么还要继续拆分微服务？其实大家也可以看到，按组织拆分，就是给每个组织分配一个系统，但是系统统一管控是最好的方式。这个成本投入远小于拆分微服务。统一管理——在DevOps和容器云的传统模式下，部署和管理20套同一个系统是比较困难的。但是在容器云和DevOps的快速发展下，已经具备了持续集成和持续交付的能力，可以通过容器云实现资源的快速扩展。比如我们可以预留20个计算节点资源，统一监控20套业务系统，如果发现明显的性能问题，可以针对某一组应用动态扩容资源。而这些操作可以通过k8s快速完成动态调度和资源分配。由于CloudNative下的不可变基础设施，也更方便保证多个系统使用同一套部署版本和镜像，保证业务系统本身的版本统一性。当然，基于这种分布式单元架构，我们还可以实现各组系统之间的相互冗余和热备份能力。例如，机构A对应的系统A的数据异步同步到系统B。那么当A系统出现故障时，机构A的所有访问都可以通过流量切换快速切换到B系统，满足A系统的高可用。
