我们的应用程序将像消费者一样集成到一系列外部系统中。企业应用程序集成架构最佳实践
大部分此集成不仅仅是消息处理和路由。有很多复杂的逻辑，比如存储当前状态，计划执行和其他内容。
此外，每个集成不共享太多的通用逻辑。
构建这种系统的最佳实践是什么？
我应该建立一体化整合层吗？它可以与不同Apache的骆驼路线和处理器的整体应用系统针对每个积分： 
或者我应该把它拆分了一堆微小和简单的独立应用程序，使他们可以缩放和独立部署？
可我与每个解决方案有什么优点和缺点？
有相当多的标准有几点：
一个良好的选择解决方案体系结构取决于此类标准对于给定IT环境的重要性。对于企业应用程序而言，使用集成平台相当普遍，而不是将集成逻辑构建到应用程序中。这样的平台通常包括用于连接，消息映射，路由，监控/告警，记录，核算，变更管理等组件
询问Integration Patterns或Enterprise Application Integration自己喜欢的搜索引擎。
谢谢你的回答。但我仍然无法找到第一个（全集成应用程序）方法的好处。以Spring Boot为例，启动，构建和部署新的小型应用程序没有大问题。测试这些小应用程序非常方便，可以独立修改其逻辑，扩展和部署。那么，第一种方法的好处可能是什么？ –
如果您将all-in-one-integrations-app翻译为“中央集成平台”，您将获得相当多的好处：支持市场上的友好性，质量，文档，技术顾问，监控，日志记录，警报，灵活性，流程处理。要使用和操作一堆不同的集成应用程序会更困难，更容易出错。 –
让我分享我的意见。 一般而言，Axel Kemper表示有很多因素会影响您的决定，因此这里没有银弹解决方案。
我会尽力保持它的技术，所以：
单片应用：
更容易部署。一般来说，你只需要一个/几个服务器。从开发人员的角度来看，差异可能并不那么明显，但与您的开发团队交谈后，他们会立即说部署一个应用程序对他们来说要容易得多
它更易于监控。基本上与上述相同。向devOps询问这个以及:)
它可以更快。如果不同的集成应用程序应该以某种方式互连（虽然它在您的方案中没有说明），那么他们可能会遭受慢速“过网络”协议的影响。在单一应用程序中，所有内容都在同一个JVM中。
可能需要更少的服务器。如果您在私有云/某个过时的环境中运行，那么插入新服务器可能会非常麻烦。你可以得到2-3服务器可为您的应用程序，这就是它:)
“多集成应用程序”架构（在我的理解它确实类似于微服务架构在整合域）具有以下优点：
更容易升级它的不同部分。如果你有一个单一的应用程序，没有正常的方法来升级只有部分的API，应该有一个大的升级整个应用程序。如果不同的“整合点”由不同的团队开发，那么它们之间的协调并不明显。
由于之前的项目符号，它可能会花费更少的时间来修复集成点中的错误（从检测到错误到生产部署修复时间）。只需修复一个特定的集成点并重新部署即可。它更轻巧。
缩放“更好”。如果您经历了某个特定集成点的大量使用，则可以轻松地在另一台服务器上添加另一个（或更多）集成点。 在一个单一的方法，你将不得不安装整个应用程序来实现类似的效果。另一个用例是，如果您部署在云中，并且您有客户愿意支付对特定集成点的独占访问权限。
更容易测试（可以说）。如果您正在运行集成/系统测试来检查集成点，那么您可以组织CI流程，以便系统能够并行运行。再加上一个更轻量级的启动，你会得到更灵活的流程。
我可能错过了比较的一些方面（当然），但这是IMO的方向。
希望这有助于
对于我来说，一个ESB或骆驼基本应用的目标是可重用性和独特之处寻找资源，你的情况：主要应用程序访问，安全性和日志。即使有不同的逻辑为每个外部系统提供服务。因此，我的方式单一的应用程序。 –