应用系统集成-概述

应用系统集成-概述

随着网络技术的发展和日益增长的软件复杂度，几乎已经不存在一个完全孤立的应用系统了，万物互联在应用层面就是系统互联，应用系统集成成为软件系统架构是需要考虑的核心问题之一。

基本介绍

应用系统集成面临的挑战

       所有的应用系统集成都将面对以下挑战。

1. 网络可靠性：应用数据共享或功能调用从进程内通讯转变为网络通讯，网络信息交换的每一个环节都可能带来延迟或中断。
2. 网络速度慢：网络交互速度的数量级远比本地的高。
3. 应用系统的实现不同：不同应用系统的实现语言、操作平台和数据模型都不一样。
4. 集成点（接口）需要持续改变。在进行系统集成时，需要考虑集成关系的变化多系统造成的影响。

应用系统集成考虑的问题

应用集成需要考虑的问题：

1. 系统功能：系统集成点是系统的不稳定点，尽量减少不必要的系统集成。
2. 系统耦合：系统集成方案应减少系统间耦合，比如引入组件作为中介减少系统之间的两两直接依赖。
3. 集成技术：不同的集成技术意味着不同的成本，包括硬件或软件以及人员的能力成本，应尽量使用简单的技术，减少系统集成对应用系统带来的代码修改。
4. 数据格式：系统集成的应用程序必须共享一致的数据格式。
5. 性能: 需要考虑集成带来的延迟。由此考虑选择的数据协议，如protoBuf或json, 轮询的请求模式或推送通知的模式; 应避免过度设计传递无用冗余数据等。
6. 数据或功能：应用的集成是共享数据还是发送请求，是否需要响应的。
7. 同步或是异步：系统集成采用同步模式或异步模式，同步模式编程简单、符合思维模式、保证实时，可能带来性能瓶颈和强依赖。异步则避免的堵塞等待，但又引入了编程复杂度。 建议先考虑同步，无法满足需求再采用异步模式。

应用系统集成的通用需求

       应用系统集成除了实现所需的业务逻辑之外，还需要额外的工作来保障集成的稳定可靠。至少包括以下内容：

1. 请求调用日志记录和监控：所有系统集成请求和响应必须得到记录，并提供后续查询的方法。集成的异常应及反馈给运营人员。
2. 请求重试。提供可配置性的自动重试，是否重试由调用测决定，如某些弱消息通知可以接受失败，最终一致性的设计失败允许本地事务成功，远程方法失败。
3. 接口服务高可用性。如：服务的扩容、负载均衡、降级。
4. 集成请求或交互数据的安全性。如：接口鉴权， SSL协议等。

这些通用需求通常由专门的平台（消息中间件、ESB）来提供，但总会涉及到比如不同组织的系统集成这种没有统一的集成中间件的情况，此时业务系统在实现集成功能的时候需要同时实现以上的通用需求。

注：系统集成应从业务模型中抽离出来以独立的层次构建，对业务系统提供统一的使用模式，以屏蔽复杂多样的集成方式。

        

图1： 应用系统中的系统集成层

主要的系统集成方式

目前主要有以下四种集成方式：

1. 文件传输：应用系统之间通过文件来共享信息。

优点：应用之间完全解耦; 技术实现简单。

缺点：实时性不足（缺乏通知），数据的一致性弱；需要考虑额外的问题：文件的并发操作、文件内容的过期、文件的清理等问题需要额外处理；文件传输缺乏结构化和校验,需要考虑内容异常的问题。

1. 共享数据库: 应用系统之间通过公共数据库来共享。

优点：数据的一致性，数据库的事务性，结构化数据校验。

缺点：难以设计共享的数据库schema；数据库可能成为性能瓶颈；并发操作可能带来死锁等问题。

注：在一些复杂度不是太高应用系统内服务之间的集成选择上，共享数据库带来的事务特性比起分布式事务更为简单和可靠。

1. 远程方法调用：服务提供者对外开发接口， 调用者执行远程调用，将对远程方法的调用和本地调用一样看待。比如CORBA, COM, Java RMI, Web Service等。

优点：远程方法调用避免了数据库模型的耦合，更加灵活；调用能得到实时响应。

缺点：系统之间需要共享接口数据类型；同步远程调用性能慢，可能造成阻塞。

1. 消息模式:应用系统通过消息中间件进行消息的发送和接收。

优点：异步解耦、实时通知、消息中间件提供的保证送达、持久化、单播广播的灵活模式等特性，业务系统无需关注集成的非功能性需求。

缺点：代码需要以异步模式去设计和实现。

消息模式

       消息模式在架构上引入了消息代理的中间件，将集成的非业务功能需求从业务系统中剥离出来，消息的异步特性实现了集成系统之间的解耦。消息中间件提供了完善的功能特性保障系统集成的稳定性和消息传递模式的灵活性，如持久化、消息保证送达、发布/订阅模式等；市场上有着成熟可靠、免费的开源中间件产品如RocketMq，Kafka等。消息模式是系统集成的推荐使用方式。

图2: 应用通过消息系统中的消息通道进行消息传递。

远程方法调用

模式一：是集成应用之间直接进行方法调用。

图3：系统间直接依赖的远程调用

模式二：存在总线或网关之类的中介负责集成协调。这种模式就类似于一个同步的消息模式了。

图4： 存在调用总线或网关作为中介的远程调用模式

同步模式在编程实现上比异步模式显得直观和简单，比如在一个业务操作需要进行远程服务请求时，同步远程调用只需要进行一次方法调用并等待结果，而异步模式需要在发送完异步请求后，进行额外的等待响应工作，如轮询回复消息或等待回复消息的通知。

模式二的远程方法调用下有商业ESB产品可以提供集成中间件。而大型企业在系统规划时可能有专门的接口网关产品来提供对远程调用模式的支持。

微服务框架下的服务调用框架网关组件提供的集成功能， 如服务注册、发现、负载均衡、重试和超时配置等功能，在网关层补充所需的日记，鉴权等功能则完成了微服务架构下的服务集成。

应用系统还需要考虑的问题

幂等性

无论是服务的提供方还是调用方在进行系统集成时都应意识网络的不稳定和延迟，请求/响应超时、回复丢失等异常场景是客观存在的，因此在服务的设计上需要应对请求的重复发送问题。

幂等性:就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而产生了副作用。

所有操作型集成接口都应该考虑幂等性：

1. 请求的唯一性判定

如何判断多个请求实际是同一请求的， 推荐使用通用的请求ID、也可以指定有业务含义的唯一编号作为请求ID，另外在不具备唯一标识的情况下， 可以通过请求的hash来判断请求是否在一个时间窗口内完全相同的重复请求。

1. 重复请求的处理

当认定是重复请求，需要考虑是给调用方直接返回成功或异常，如果存在请求唯一性ID, 因双方都可以识别唯一性，可以返回成功。而当使用业务或其他方式时，需要在接口协议中明确自己的决策规则，避免造成系统的不一致性，比如调用方两次调用产生了多次执行的相关单据，而服务提供方产生了一次相同的结果。

1. 如果旧有的服务提供方没有保障幂等性，则需要在调用方（通常是新的集成需求）侧保证请求的幂等性。

分布式事务

       系统集成带来的最大挑战是分布式事务。在微服务并且使用统一技术框架的情况下，可以使用分布式事务的框架来实现，如Seata, Saga等。但在系统集成场景下， 由于不同的产品设计、不同的技术架构， 不同的网络环境， 不同的组织， 使用统一的事务框架几乎不可能，当然也有阿里的GTS 全局事务服务这样的第三方服务。

那在没有事务框架的的场景下， 需要在业务架构和编码上进行调整，业务上尽量将长事务拆分成小事务，保证一个事务只牵扯本地事务和一个远程调用，再在编码上将远程调用的异常作为本地事务的异常，保证本地事务的回滚。而本地事务只有在远程调用成功的情况下才完成提交。

       即使是做到了上面描述的效果，依然会出现将远程执行的响应因网络造成的丢失或超时错误判断为远程调用失败的情况。依然要结合具体业务场景，重试+幂等性或远程事务的确认等方法来对本地事务进行正确的提交或回滚。

系统可用性

在一个业务中对多个系统的依赖会带来系统可用性指数级的下降，如本系统保证99.99%的可用性，如一个业务依赖了n个接口，如果都是同步性的依赖，则可用性会下降为99.99%的n次方。

       因此在对可用性有极高要求的系统中， 系统集成要尽量使用消息集成方式来进行系统解耦提高可用性，对集成接口的调用需要考虑集成接口的性能、稳定性等需求，采取必要的措施：

1. 服务限流：对依赖接口调用应考虑限流，如Guava RateLimiter限流器， Feign+Sentinal。
2. 服务降级：当集成调用出现大量异常时，应进行降级。如Feign的Fallback，同时也可以考虑对依赖异常集成的自身业务进行降级。
3. 缓存：对于信息查询集成，可以考虑将集成响应缓存在本系统来在作为集成异常的替代方案或提升性能。缓存具体的使用依赖于业务对数据实时性的要求。

服务提供方同样因为对外暴露了服务面临未知的挑战，如恶意攻击或业务爆发是增长带来的请求风暴，应采取以下必要措施进行应对：

1. 服务限流：自身对外服务需要根据系统性能压测和性能指标进行限流配置，防御DDOS攻击或应对业务带来的请求意外增长。
2. 服务扩容：应考虑扩容方案来应对业务猛增所带来请求压力。如服务的横向扩容方案或纵向扩容方案。
3. 服务降级：对外提供服务异常时，应进行服务降级，避免造成请求的大量积压。
4. 服务隔离：可以考虑将系统集成的相关服务或模块和系统其他模块进行拆分隔离，避免因集成异常对其他业务造成影响。