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

朱义方

（国网上海市电力公司信息通信公司，上海 200072）

0 引言

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

1 ERP 应用系统的发展

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

2 微服务架构下ERP 应用系统的优势

2.1 灵活性

根据微服务的架构思想，简单的将ERP 系统划分为多个子系统，在这些子系统当中，开发环节、部署环节、测试环节都可以通过不同的团队来完成，甚至可以由不同的技术栈来完成。这些团队有不同的技术支撑，子系统只需要完成相关业务服务，通过Web Service 或RFC 形式的接口输出即可。同时，这些暴露的接口粒度开发人员可根据具体业务需求、系统扩展需求、灵活性需求来进行综合性设计。微服务还有另外一个显著特征，即与单一应用程序的服务方向不同，单一程序根据层级来定义不同的团队，如用户界面、服务器、数据团队等，而微服务是为公司全业务而服务，不受任何类型局限，这种方式让团队具备了跨职的可能，因此，微服务的功能更全面，如用户体验、数据库管理、项目管理等[4]。这些功能的出现让微服务更快融入了生活，使我们进一步走进Dev Ops 时代。此外，在数据库层面，独立的子系统均具备单独数据库，数据库的具体设计根据系统具体需求而定义，可以是关系型数据库，也可以是其他类型的数据库。

微服务架构的核心就是去中心化，集合大量不同的子系统，围绕企业的需求开展本身业务以外的其他业务实现，这其中采取的手段不同，实现结果也不同，降低了系统的债务情况，让系统功能的实现不再依赖某一个框架或者是语言。每个服务技术选型灵活，不受遗留系统的技术约束。即使是一个比较小型微服务系统的升级、重构，也不会对系统的运行产生影响，这给软件的更新换代降低了多种风险[5]。

2.2 自治性

微服务有自己的逻辑和数据，能完全独立部署和运行在一个进程内，通过REST API 架构或RPC 架构，将事件流程与报文代理结合起来，以达到相互协同的轻量级通信机制。在微服务体系结构中，各个服务是独立的业务单位，对领域内可进行自我管理和修复，且不对其他服务功能造成影响。微服务体系中的应用系统包含了许多具有高度自主性的、独立的商业实体，能够在各自的系统中运行，并且能够很方便地将各种服务配置到不同的主机上，从而达到高度自治和高度分离性。作为单个独立的微服务，其职责也是单一的，即一个微服务解决一个业务需求。当某个子系统需要升级，或者是添加额外功能的情况下，只需要对单个子系统进行重构，不需要对整个应用进行编译和部署了。这种松耦合、自治的系统架构让应用系统的发布流程更为可靠、便捷，同时也能降低对系统产生的各类风险，进一步缩短应用的交付周期。

2.3 扩展性

传统单体架构下的应用系统扩展往往都是水平方向的，例如服务器的扩充，数据库的复制，这确实能够在一定程度上解决访问速度缓慢、访问失败等故障，但是无法解决根源上存在的问题。在这个过程中会消耗大量资源，系统负荷量也会显著增加，资源消耗量大幅提升。如果将ERP 系统拆分为一个个微型服务，通过业务流程对服务进行排列组合，就可以处理更多的工作，或者很容易地进行扩展。这些无状态的自治节点灵活地分布在整体系统中，自由地拓展伸缩，为系统提供了稳定且可靠的性能基础和更加清晰的业务划分。

从开发角度来看，我们还可以尝试分散服务来扩大服务范围，管理人员与开发人员通过业务需求来确定使用哪种程序语言，而其决定因素是围绕微服务架构更适合哪一种语言。这也意味着开发与管理人员可能选择彼此独立的数据库，但这也是微服务架构具备的最大优势，即无限拓展性。开发人员可在微服务部署结束之后根据自己需要的功能调整即可，而不是每次都要创建语言，节省了大量的时间和成本。

3 微服务架构下ERP 应用系统运用过程中面临的挑战

3.1 拆分粒度问题

微服务构架设计的过程中首要任务就是对服务进行拆分，拆分原则多种多样，但是基本均是围绕业务开展的。服务拆分粒度目前并没有可以借鉴的标准，实际上也没有统一的标准。因此按照业务划分的各个微服务，应该在这个环节做到向内聚集，从而减少分布式事务的存在。由于系统的服务力度标准不统一，当服务力度过于粗糙，就会产生耦合的现象，在具体的设计过程中，服务力度也不是以细为好，如果拆分过于细密，系统内部交错复杂的关系就会增加使用的隐患，而问题发生后也很难找到根源，增加了系统的不稳定性。因此在服务的拆分粒度方面应尽可能保证服务本身的独立与完整，避免错综复杂的交错现象存在，减少系统之间的依赖性，尽可能避免多层依赖、链式调用现象的存在[5]。

3.2 服务间通信问题

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

3.3 分布式事务问题

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

假设将ERP 系统中某大型业务分为多个子服务，那么在运行该业务时，服务与服务之间需彼此通信，远程协作后才能输出最终结果，即完成一整套分布式事务操作[7]。但是如果在服务调用过程中某一个服务突然不可用，或由于网络问题远程调用超时，那么服务之间就可能出现数据不一致甚至级联反应导致整个业务运行失败。例如，采购管理系统的业务实现，在材料采购入库时相应数据会写入库存管理系统内，系统当前的数据为库存数据，当材料完成入库之后，库存管理系统中的材料数量就应同步更新。如果在这一整套流程中发生了某一个节点的卡顿或夯死，就会造成数据链断裂，一旦数据出现不一致，就会导致整个业务逻辑执行任务失败。为保证业务流程顺利进行，我们需要提供更多的服务，如文档管理、服务治理、服务模拟的工具和框架；实现统一认证、统一配置、统一日志框架、分布式汇总分析；采用全局事务方案、异步模拟同步或搭建持续集成平台、统一监控平台等。

4 微服务架构下ERP 应用系统设计

4.1 ERP 系统的总体需求

ERP 系统的一个主要功能就是使企业的业务过程自动化。例如，在客户发出订单后，销售部会根据企业的存货和生产能力，对客户的订单进行审核，如果存货和生产能力都能满足，那么就对客户的定单进行确认，然后按照定单上的产品，向仓库部提出出货要求，如果存货达到了要求，则直接出库。如果存货不够，则由生产部根据订单确定生产任务，待产品生产出来后再提交仓库。

4.2 基于微服务的ERP 系统架构设计

基于微服务的ERP 系统架构可以分为四层，从底层到顶层分别是基础设施层、微服务层、服务网关层、应用交互层。其中基础设施层的主要作用是数据存储，由Redis 数据库来提供缓存服务和关系型数据库资源；微服务层的主要作用是为ERP 系统的应用提供聚合微服务和基础业务服务，包括销售管理、生产管理、库存管理、采购管理、财务管理、订单服务、支付服务等；服务网关层则主要为ERP 系统的正常运行提供Gateway服务网关和Nginx 反向代理；应用交互层可为用户和管理人员提供信息数据交互使用的功能，如Web View、Web APP、第三方OA 或者是CRM 系统。

4.3 协作接口设计

设计协作接口的本质是定义各个衔接上下文的应用服务接口，保证企业对ERP 系统使用的需求。在微服务框架下，ERP 系统协作接口可采用事件机制，协作接口可按照之前确定的上下文映射来获得。由于每个协作关系都有一个接口，不同的上下文映射模式可能会影响到接口的设计效果。比如：生产订单上下文映射时，需要将订单和系统集成之间的协作改为事件机制，并详细记录和订单上下文相关的协作接口。

有时一个服务会对应多个接口，而每个接口所担任的职责功能可能会有关联，所以开发一套简单又便捷的协作服务接口是很重要的。我们在设计时应尽可能地减少依赖性，以降低故障发生的可能，提高服务可靠性。还可以尝试将一个功能下的接口根据主次拆分到不同的服务中去，优先级高的放在一个服务中，优先级低的放在另一个服务中，以减少一个服务不可用导致其所有接口均不可用的情况。

4.4 微服务网关设计

网关是ERP 系统的上层服务，它隔绝了微服务与客户端的直接通信，所有的外部请求都会先经过网关这一层。传统单体式架构的ERP 系统通常只开放一个服务给客户端调用，而微服务架构中服务都是独立拆分的。当客户端访问某个服务时，需要先在本地记录该微服务的调用地址，如需访问多个服务，则需要记录每个微服务的接口地址，这无疑增加了系统的负担。这时就需要由网关来统一系统入口，即将微服务进行封装，所有请求经网关合理分配至各微服务，使客户端只需与网关通信，不必再一一调用其他服务。另外，网关系统还能收集相关监控数据，对访问请求进行统一认证，控制并发流量等，为系统的安全加上一把“锁”。目前市场上使用较多的网关有Zuul、Spring Cloud Gateway、Kong 等，其性能较好，可维护性强，可实现身份认证、内部负载均衡、限流等主要功能。

5 结语

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