微服务架构下ERP应用系统的优势及挑战

朱义方 徐易婕

摘 要：近年来互联网彻底改变了人们的生活方式，给人们的工作和生活带来了极大的方便。随着互联网技术的发展和业务的需求，传统的IT建设已经满足不了客户的需求，那么我们的IT架构也需要作出相应的改进，来支撑企业的数字化转型。而容器与微服务平台已是当今众多IT公司的主流技术，相关的云计算、虚拟化技术也已深入渗透到我们日常的开发运维中[1]。相比较而言，传统单体式架构下的ERP信息系統逐渐暴露出了诸多短板缺陷，如程序结构复杂，系统扩展性差，故障影响范围广等。随着移动互联时代的推进，ERP系统需要应对公司业务规模的日益扩张，单体架构已经很难适应或是满足应用系统对于扩展性、可用性、灵活性等方面的要求。继而，系统向新型微服务架构的转变应运而生。

关键词：微服务;ERP系统;软件架构

微服务构架可以看做是一种软件架构风格，能够以开发一组组小型服务来构建成一个大型应用系统。微服务之间彼此耦合度松散，每个服务都可独立放置、自我管理，且服务间调用编排灵活。由此构建的ERP系统内，各微服务模块即可保持彼此独立，亦可相互关联，也能对每个微服务进行单独部署、测试、和运转。在服务内部，服务模块只关心其关联业务的开展，负责ERP系统中的一个或者多个业务。

1.ERP应用系统的发展

典型的ERP系统是一个由多个模块例如销售管理、库存管理、物资采购、人资管控、财务管理等组成的企业信息资源管理系统。初期以IBM大型机为平台，主要开发语言为ABAP，之后推出SAP NetWeaver平台，配合单独的Oracle数据库，从而形成一个数据库层、应用层、展示层的SAP三层架构体系[2]。随着时间的推移，ERP系统业务在现代化技术的依托下发展越来越快，功能不断完善，流程日益增多，伴随着开发人员不断交替，代码质量参差不齐，单体式架构下的应用越来越复杂，系统的扩展性和可维护性的弊端逐渐暴露出来。尤其是在进入新时期之后，ERP系统急需一个全新的软件结构模式来支撑其庞大的架构体系和业务需求。而近年来逐渐成熟化的云计算和微服务等新兴技术架构，恰好能灵活的满足我们对系统的需求，而且具备更加独立的运营维护效率[3]。

2.微服务架构应用的优势

2.1 灵活性

首先我们根据微服务的架构思想，简单的将ERP系统划分为多个子系统，在这些子系统当中，开发环节、部署环节、测试环节都可以由不同的团队来完成，甚至可以由不同的技术栈来完成。子系统只需要运行系统相关业务服务，通过WebService或RFC形式的接口输出即可。同时，这些暴露的接口粒度开发人员可根据具体业务需求、系统扩展需求、灵活性需求来进行综合性设计。微服务的另一个重要特征是，与单一应用程序不同的是，单一程序根据应用程序的不同层级来定义团队：用户界面团队，服务器端团队，数据库团队等;微服务允许公司围绕特定业务功能来构建团队。这反过来又驱使团队具备了跨职能能力，从而拥有了一系列更强大的技能：用户体验、数据库管理、项目管理等[4]。这使我们进一步走进DevOps时代。最后在数据库层面，允许每个独立子系统有自己的单独数据库，可以是关系性数据库，或是新型键值等其他类型的数据库。

微服务架构的核心就是去中心化，不同的子系统以本身业务特征采取不同的业务手段来实现，从而降低了系统的技术债务现象，使系统不过分依赖某个框架或者是某种语言来实现应用。每个服务技术选型灵活，不受遗留系统的技术约束。即使是一个比较小型的微服务系统进行升级、重构，也不会对运维团队造成很大的困扰，这给软件的更新换代降低了多种风险[5]。

2.2 自治性

微服务有自己的逻辑和数据，能完全独立部署和运行在一个进程内，对领域内可进行自我管理和修复，且不对其他服务功能造成影响。作为单个独立的微服务，其职责也是单一的，即一个微服务解决一个业务需求。当某个子系统需要升级，或者是添加额外功能的情况下，只需要对单个子系统进行重构，不需要对整个应用进行编译和部署了。这种松耦合、自治的系统架构让应用系统的发布流程更为可靠，让发布更加高效便捷，同时也降低了对生产环境的风险，也相应缩短了应用的交付周期。

2.3 扩展性

传统单体架构下的应用系统扩展往往都是水平方向的，例如服务器的扩充，数据库的复制，这确实能够在一定程度上解决访问速度缓慢、访问失败等常见性问题，但无法解决根源上的问题，而且还会消耗大量资源，增加系统负荷，资源利用率大幅增长。而服务的分散管理使开发人员能够根据特定业务需求选用不同的编程语言，这取决于他们认为哪种语言才是围绕微服务构建的最佳选择。这也意味着他们可以使用独立的数据存储，从而获得这种架构的最大优势——几乎无限的可扩展性。在微服务多地部署完成后，您只需要调整所需的功能，而不是每次都创建整个应用程序的重复实例。这反过来又节省了时间和资源。如果将ERP系统拆分为一个个微型服务，通过业务流程对服务进行排列组合，就可以处理更多的工作，或者很容易地进行扩展。这些无状态的自治节点灵活地分布在整体系统中，自由地拓展伸缩，为系统提供了稳定且可靠的性能基础和更加清晰的业务划分。

3.微服务架构运用过程中面临的挑战

3.1 拆分粒度问题

在微服务构架设计的过程中首要任务就是对服务进行拆分，拆分的原则可以有很多种，但基本上都是围绕业务展开完成的，服务的拆分粒度实际上没有统一的标准。因此按照业务划分的各个微服务系统，应该在这个环节内做到高内聚，尽量减少分布式事务的存在。由于服务力度很难划分出统一的标准，当服务力度过于粗糙，内部代码就会产生耦合的现象，在具体的设计过程中，服务力度也不是以细为好，如果拆分过于细密，系统之间相互的依赖关系就会变得复杂，出现问题之后也很难找到问题的根源。对于服务的拆分粒度，应该尽量保证本身服务开展的独立性和完整性，尽量减少服务之间的依赖性，尽可能避免多层依赖、链式调用现象的存在[5]。

3.2 服务间通信问题

前面我们说到服务之间要尽量做到高内聚、低耦合，但无论怎样，一定不能避免系统中各服务之间的互相调用。所以当服务完成拆分后，就需要处理服务间互相通信的问题。如何使服务间进行最有效便捷的相互调用，是目前微服务架构下众说纷纭的热点[6]。当前，已有一些成熟开源的RPC框架调用使用較为广泛，如Dubbo、SpringCloud、gRPC等，都能够支持多种调用协议。这些框架能够帮助封装底层数据间的通信细节，让不同微服务之间的通信就像是本地通信一样简单快捷。另外，我们也能根据自身特性开发适合ERP系统的调用框架，或与其他技术框架结合使用，才是解决众多服务间调用交互的根本方法。

3.3 分布式事务问题

基于微服务的灵活性，每个服务都可以有自己的数据库。这对于开发人员来说大大提高了他们的发布效率，但如何实施跨服务的事务和查询以及保持整个系统的数据一致性却不是一件轻松的事，可以说是一把“双刃剑”。

假设我们将ERP系统中某大型业务分为多个子服务，那么在运行该业务时，服务与服务之间需彼此通信，远程协作后才能输出最终结果，即完成一整套分布式事务操作[7]。但是如果在服务调用过程中某一个服务突然不可用，或由于网络问题远程调用超时，那么服务之间就可能出现数据不一致甚至级联反应导致整个业务运行失败。比如采购管理系统，在采购入库时相应数据会写入库存管理系统;当库存管理系统中的产品完成入库之后，还需要更新采购系统中的具体数量。上面这些问题我们应该都遇到过，并且也会有一些解决方案，比如提供文档管理、服务治理、服务模拟的工具和框架; 实现统一认证、统一配置、统一日志框架、分布式汇总分析; 采用全局事务方案、采用异步模拟同步;搭建持续集成平台、统一监控平台等等。可见这一整套流程严格要求数据的一致性得到保证，一旦数据出现不一致，就会导致业务逻辑执行任务失败。

结语：综上，微服务架构的优势固然可见，与之而来的困难与挑战也是关卡重重。故无论是传统单体式还是新型微服务架构，我们在使用它之前都需要对其有全面深入的认知，在结合系统本身特性的基础上认清系统面临的变革与挑战，而不是为了追求技术而去微服务化。

参考文献：

[1]巢晟盛.基于SpringBoot微服务架构下前后端分离的MVVM模型浅析[J].电脑知识与技术，2021，17（23）：128-129+141.

[2]吴磊， 湛健， 宋丽华.微服务架构在智能家居网关系统中的应用研究[J].计算机技术与发展， 2019， 029（011）：200-205.

[3]周文坤， 乔运华， 侯佳佳， etal.微服务架构的ERP应用系统的优势及挑战[J].制造业自动化， 2020， 042（006）：123-124，132.

[4]张广鑫.基于微服务架构的智慧校园系统平台建设研究[J].辽宁高职学报， 2020， v.22;No.203（02）：85-89.

[5]桂俊，沈迎春.基于微服务架构的企业ERP设计与应用[J].计算机系统应用，2021，30（08）：81-88.

[6]池炜成，史立学，刘智琼，朱明英.微服务架构下规则平台方案与规则迁移方法[J].现代计算机，2021（18）：142-145.

[7]周艺伟，洪逸凡.基于微服务架构下题库系统智能组卷算法应用的研究[J].电脑知识与技术，2020，16（24）：183-184+190.