无论我们在哪个行业工作,系统集成都是软件工程师的常见任务,我们需要处理系统与系统之间的集成问题。为了实现这一点,我们需要遵循不同类型的系统集成模式,在这里,我们将介绍常见的集成模式:文件传输、共享数据库、远程过程调用和消息传递。
常见系统集成模式
优点
- 生成文件的生产者组件和使用它们的消费者组件是分开的,因为消费者不需要知道生产者的内部是如何工作的。但是,我们需要共同维护文件的内部结构,因为这是两个组件的共同约定,如果不小心改变它,可能会导致集成问题。
缺点
- 因为在生成文件和使用文件之间可能有一段时间,所以组件数据可能会不是实时同步,而且可能会影响业务流程,因为数据可能是陈旧的。
- 我们可以更频繁地生成文件;然而,这需要大量的资源,我们需要确保使用这些资源的组件不会丢失任何文件。
- 由一个组件产生的数据可能对另一个组件具有不同的含义,这可能导致信息不一致。
考虑的中立点
- 使用这些文件的组件通常需要进行一些格式处理和转换。
- 组件需要就文件命名约定和存储文件的文件夹结构达成一致。
- 有时,我们希望定义一个时间间隔,即何时生成文件以及何时使用它们,因为生成文件可能需要时间,需要考虑哪些业务。
- 需要一个锁定机制来避免消费者组件在生产者组件写入文件时读取它。
- 我们需要一个删除策略和机制来删除不再需要的文件。
优点
- 事务管理由数据库提供,数据库维护数据的一致性、完整性和持久性。
- 数据格式和结构是一致的,因为我们使用的数据库清楚地定义了这些方面。
- 数据没有不同的含义,因为我们需要对不同组件之间的数据含义达成一致。
缺点
- 一个SQL共享数据库可能成为一个瓶颈,因为多个组件将写入/读取同一个数据库。通常,我们会将我们的组件分布在不同的地方。这意味着我们将需要复制数据库并使用分布式锁定,这很容易导致性能问题。这在NoSQL数据库中不再是一个问题;然而,当某些事务需要ACID属性时,关系数据库仍然被广泛使用。
- 定义一个对所有组件都有用的模式并不总是一件容易的任务,因为每个组件通常都有自己的需求。NoSQL数据库允许我们动态改变模式;然而,在实际中,如果我们有多个组件使用同一个NoSQL数据库,还需要定义一个适用于所有组件的模式。
- 由于数据没有封装,任何组件都可以更改数据而无需另行通知,这可能会导致使用相同数据的其他组件出现问题。
- 将所有组件耦合到一个数据库是很重要的。
优点
- 我们可以实现微服务架构及其所有优点:
- 由于更短的开发时间而增加了敏捷性。
- 更快、更可靠的自动化部署。
- 更好的可测试性,因为每个服务的逻辑都可以独立测试。
- 高可伸缩性。
- 数据和处理数据的逻辑封装在远程方法中。
- 每个组件都在不影响其他组件的情况下更改自己的数据,这也帮助我们避免了相同数据的不同含义。
缺点
- 耦合之所以存在,是因为要调用远程过程,调用方需要知道被调用方的契约,而被调用方需要在过程中可用。
- 由于这一切都是远程完成的,可能会出现一些网络故障或延迟,我们需要设计组件来处理这些场景。
- 由于逻辑和数据分布在多个组件之间,集成和操作复杂性可能会增加。
- 如果存在网络延迟,或者流调用中的某个组件存在性能问题,那么性能就会下降。
优点
- 消息传递允许我们实现一个事件驱动的体系结构,它具有所有的优点:
- 敏捷性,因为我们可以让不同的团队独立构建生产者/消费者组件。
- 更好的部署,因为每个生产者/消费者组件都可以独立部署和操作。
- 高性能,因为生产者/消费者组件是异步运行的。
- 高可伸缩性,因为我们可以部署生产者和消费者的额外实例来分配处理负载。
- 在生成消息的组件和使用消息的组件之间没有耦合。它们不需要知道彼此的内部细节,也不需要同时可用。
- 数据过时的问题可以得到缓解,因为当发生变化时,生产者组件可以快速生成消息,消费者将立即得到通知和处理。
缺点
- 跨不同生产者/消费者组件的消息流的可测试性可能很困难,因为多个组件可能同时处理同一消息。
- 由于数据的异步处理分布在多个生产者/消费者组件之间,复杂性可能会增加,这可能会使理解完整的数据流变得困难。我们还需要处理消息处理错误和编程学习曲线。