企业应用程序的集成架构最佳实践

Question

我们的应用程序将像消费者一样集成到一堆外部系统中。

大多数此类集成不仅仅是消息处理和路由。有很多复杂的逻辑，比如存储当前状态，计划执行和其他东西。

此外，每个集成都没有共享很多共同的逻辑。

构建此类系统的最佳做法是什么？

我应该构建一体化集成层吗？它可以是一个单一的应用程序，每个集成具有不同的apache camel路由和处理器：

或者我应该将它拆分成一堆小而简单的独立应用程序，以便它们可以独立扩展和部署？

每种解决方案可以带来哪些好处和缺点？

Answer 1

有很多标准需要考虑：

• 经济：项目成本，运营成本
• 吞吐量：每次数据量
• 延迟：邮件的旅行时间
• 安全：数据保护
• 可靠性：失败的可能性
• 灵活性：轻松应对不断变化的需求
• 流程支持：控制数据流，事件/错误处理

良好解决方案架构的选择取决于此类标准对给定IT环境的重要性。对于企业应用程序，使用集成平台而不是在应用程序中构建集成逻辑是很常见的。此类平台通常包括用于连接，消息映射，路由，监视/警报，日志记录，会计，变更管理等的组件。

向您最喜爱的搜索引擎询问 Integration Patterns 或 Enterprise Application Integration 。

Answer 2

让我分享一下我的观点。 一般来说，Axel Kemper表示有很多因素可以影响你的决定，而且这里没有一个银弹解决方案。

我会尽力保持技术性，所以：

单片应用程序：

• 更易于部署。通常，您只需要一个/几个服务器。从开发人员的角度来看，差异可能并不那么明显，但与您的开发团队交谈，他们会立即说部署一个应用程序对他们来说更容易

• 更容易监控。基本上与上述原因相同。也请询问devOps：）

• 它可以更快。如果不同的集成应用程序应该以某种方式互连（虽然在您的方案中没有说明），那么它们可能会受到缓慢的“过度网络”协议的影响。在单一应用程序中，所有内容都在同一个JVM中。

• 可能需要更少的服务器。如果您在私有云/某些过时的环境中运行，那么插入新服务器会非常麻烦。您可以为您的应用程序获得2-3台服务器，就是这样:)

“多集成应用程序”架构（根据我的理解，它实际上类似于集成域中的微服务架构）具有以下优势：

• 更容易升级它的不同部分。如果你有一个单一的应用程序，没有正常的方法只升级部分API，整个应用程序应该有一个大的升级。如果不同的团队开发了不同的“集成点”，那么在版本之间进行协调并不明显。

• 由于之前的子弹，可能需要更少的时间来修复集成点中的错误（从检测到错误的时间到修复程序在生产中部署的时间）。只需修复一个特定的集成点并重新部署即可。它更轻巧。

• 更好地“缩小”。如果您经历了某些特定集成点的密集使用，您可以轻松地在不同的服务器上添加另一个（或更多）。 在单片方法中，您必须安装整个应用程序才能实现类似的效果。另一个用例是，如果您部署在云中，并且您有一个客户愿意为特定集成点的独占访问付费。

• 更容易测试（可以说）。如果您正在运行集成/系统测试以检查集成点，那么您可以组织CI流，以便系统将并行运行。再添加一个更轻量级的启动，您将获得更灵活的流程。

我可能错过了比较的某些方面（当然），但那是IMO的方向。

希望这有帮助