论 SOA 在企业集成架构设计中的应用

题目要求

企业应用集成（Enterprise Application Integration，EAI）是每个企业都必须要面对的实际问题。面向服务的企业应用集成是一种基于面向服务体系结构（Service-Oriented Architecture，SOA）的新型企业应用集成技术，强调将企业和组织内部的资源和业务功能暴露为服务，实现资源共享和系统之间的互操作性，并支持快速地将新的应用以服务的形式加入到已有的集成环境中，增强企业 IT 环境的灵活性。
请围绕“SOA 在企业集成架构设计中的应用”论题，依次从以下 3 个方面进行论述。

1、概要叙述你参与管理和实施的企业应用集成项目及你在其中所担任的主要工作。

2、具体论述 SOA 架构的内容、特点，以及你熟悉的工具和环境对 SOA 的支持，在应用中重点解决了哪些问题。

3、通过你的切身实践详细论述 SOA 在企业应用集成中发挥的作用和优势。

摘要

2021 年 10 月，本人在公司参加了多人在线网络游戏系统的开发，该系统要支持频繁的用户交互，有个人用户的功能模块，也有多人交互的功能模块，并要求要有较良好的服务伸缩能力，支持后期功能的迭代和架构的更改。我在该项目中担任该项目的技术负责人，主要负责整体的架构设计和组件选型。本文结合本人的实践，以该系统为例，主要论述了 SOA 在企业集成架构设计中的具体应用。玩家登录服务，游戏内业务服务，用户聊天服务等服务为服务提供者；redis 是服务注册中心，保证系统各个模块的松耦合喝独立性；网关是服务总线，隔离玩家用户与服务提供者的直接交互。实践证明，通过以上的技术应用有效增强了系统的可扩展性，伸缩性和可修改性，最终系统上线后，维护运维都非常容易。

正文

公司原来都是开发小服游戏，为着战略目标，全球通服的游戏越来越流行，因此需要搭建全新的架构，能保证大量玩家用户同时在线，要具备良好的扩展性和弹性伸缩能力，在用户数量剧增，请求变多的时候，系统不用做出代码的变更，只需要加机器就可以应付，当性能需求量不高的时候，可以借助云的监控可以自动减少机器，并且因为是初步的通服架构，后期可能会修改，所以需要一个服务总线，这样在服务提供方改一些架构代码，服务的请求方就没有感知。因此，新的通服游戏架构就因此开发了。

2021 年 10 月，我参加了我们公司全球通服类游戏的开发工作，担任该项目的技术负责人，主要负责该系统的技术方案制定及技术指导。该系统需要实现的功能性需求有：用户注册登录，玩家个人数据业务，公共游戏业务，大厅聊天业务，游戏任务系统等等；非功能需求：支持修改服务端架构对客户端无感知，支持用户量增减的过程可以动态伸缩服务器数量，服务间方法调用，后续开发人员的维护等。因此，要满足该系统的需求，选择一种合适的架构技术至关重要。

SOA 是一种面向服务的架构，它将应用程序拆分成多个独立的组件，这些组件通过特定的通信协议进行交互，协作完成任务。SOA 包括服务提供者，服务注册表，服务总线，服务消费者。服务提供者可以提供服务，这些服务可以是无状态，多节点的，启动服务时，将自己的信息通过服务总线发送给服务注册表。服务注册表收到服务注册后，就绑定对应的服务地址。服务消费者可以根据服务注册表找到对于的服务提供者的地址，然后通过服务总线调用服务。服务总线是它们通信交互的凭借，并且使各实体之间松耦合的关系。服务的提供者可以是无服务，多节点，非常适合弹性伸缩的需求，高负载的适合就多节点，低负载就减少节点。服务总线可以分离服务消费者和服务提供者之间的直接耦合关系，对于系统架构的可修改性和扩展性都有很大的帮助。

该系统要求一定的扩展性和服务高伸缩性，结合 SOA 的特点，我们最终采用了面向服务的，基于 SOA 的企业应用集成。下面具体论述 SOA 的应用过程。

服务提供者实现的功能有用户注册登录，玩家个人数据业务，公共游戏业务，大厅聊天业务，游戏任务系统等等。里面的服务有有状态的和无状态的：无状态的服务比较简单，比如用户注册登录，获取用户游戏中所有的数据等，可以直接做服务伸缩；有状态的服务因为自己需要保留一下数据存在本地，比如多人在线对弈的房间制业务，存在多端异步请求，需要有个状态，使得最终命令需要同步执行，所以在实现上我通过业务垂直划分切片的方式，以一定数量的房间为单位切片，使有状态的服务也能弹性伸缩。主要服务的性能消耗都是在服务提供者这一边，我们将服务提供者做成可拆分，且能弹性伸缩后，可以在高负载与低负载的两种情况下实现硬件的成本最佳实践。

服务注册中心是通过 redis 实现。redis 本身有发布订阅的功能，而且在考虑开发工具使用上，redis 本身作为缓存中间件就已经在使用了，可以节约开发人员的学习成本。服务提供者在启动服务的时候发布自己的信息（自己的地址和服务内容），发布到 redis，其他服务消费者若是已经订阅了这个通道，既可以获取此服务的注册信息，然后记录服务提供者信息，同时如果服务消费者在还没有订阅之前就发布服务了，也可以在 redis 的缓存中获取到已经存在的服务。服务提供者的数量没有确定的值，根据当前供需的要求动态的增加或减少服务，在服务注册中心实时的反应出来，加强了整个系统的弹性伸缩能力。

服务总线有内部服务交互的服务总线，还有玩家请求服务的微服务总线（网关）。内部服务总线，由单独的一个服做消息分发，一个组件若需要另一个组件的服务，需要先需要的服务请求发送到内部消息服务，内部消息服务根据内部路由发送对应的组件，对应组件处理完之后经由内部消息服务再返回原内部服务消费者，因为有专门的内部消息服务总线，可以在这个服有更多的处理操作，加强了消息处理的易用性，每个服也不需要单独做路由查找的事情，使得功能内聚更强，降低组件间的耦合度。外部微服务总线，也就是游戏网关，玩家用户通过客户端连接游戏网关，通过网关对内部游戏服务提供者进行调用，因为我们是初步的实现这个通服架构，所以后面如果在内部架构有修改的情况下，只要保持客户端与网关的交互协议内不变，对于客户端来说是透明修改，极大的增强了可修改性和扩展性。

整个项目历时 6 个月的开发，于 2022 年 4 月完成交付上线，目前还在线上稳定运营维护，且受到了公司高层领导和运维等多方的认可和赞赏。项目在大量负载时（游戏开服，活动高峰期），配合云服务的弹性伸缩服务，可以将服务提供者动态增加，当降低负载时（凌晨），会自动回收多余的机器，在这个过程里，运维只需要打包组件到容器中，结合 Paas 就可以托管运营。也因为服务的拆分，线上在一台服务提供者出现设备故障时，不影响其他服务的运行，展现了系统一定的可靠性，但是因为系统中还是有一些单点服务，我们后期将单点服务改成集群服务，这时服务注册中心和服务总线的作用体现的非常明显，服务注册中心可以对服务的单点和集群部署可以完全的兼容，而在我们修改内部服务结构时，只需要简单的在服务总线做简单的修改，服务消费者对此毫无感知，体现了内部服务可修改性。

实践证明，SOA 架构适用于通服游戏架构，在可修改性，扩展性和可用性都得到了保证，另外服务具备良好的伸缩性，节省了线上运营成本。达到了项目的预期。