我們的應用程序將像消費者一樣集成到一系列外部系統中。企業應用程序集成架構最佳實踐
大部分此集成不僅僅是消息處理和路由。有很多複雜的邏輯，比如存儲當前狀態，計劃執行和其他內容。
此外，每個集成不共享太多的通用邏輯。
構建這種系統的最佳實踐是什麼？
我應該建立一體化整合層嗎？它可以與不同Apache的駱駝路線和處理器的整體應用系統針對每個積分： 
或者我應該把它拆分了一堆微小和簡單的獨立應用程序，使他們可以縮放和獨立部署？
可我與每個解決方案有什麼優點和缺點？
有相當多的標準有幾點：
一個良好的選擇解決方案體系結構取決於此類標準對於給定IT環境的重要性。對於企業應用程序而言，使用集成平臺相當普遍，而不是將集成邏輯構建到應用程序中。這樣的平臺通常包括用於連接，消息映射，路由，監控/告警，記錄，覈算，變更管理等組件
詢問Integration Patterns或Enterprise Application Integration自己喜歡的搜索引擎。
謝謝你的回答。但我仍然無法找到第一個（全集成應用程序）方法的好處。以Spring Boot爲例，啓動，構建和部署新的小型應用程序沒有大問題。測試這些小應用程序非常方便，可以獨立修改其邏輯，擴展和部署。那麼，第一種方法的好處可能是什麼？ –
如果您將all-in-one-integrations-app翻譯爲「中央集成平臺」，您將獲得相當多的好處：支持市場上的友好性，質量，文檔，技術顧問，監控，日誌記錄，警報，靈活性，流程處理。要使用和操作一堆不同的集成應用程序會更困難，更容易出錯。 –
讓我分享我的意見。 一般而言，Axel Kemper表示有很多因素會影響您的決定，因此這裏沒有銀彈解決方案。
我會盡力保持它的技術，所以：
單片應用：
更容易部署。一般來說，你只需要一個/幾個服務器。從開發人員的角度來看，差異可能並不那麼明顯，但與您的開發團隊交談後，他們會立即說部署一個應用程序對他們來說要容易得多
它更易於監控。基本上與上述相同。向devOps詢問這個以及:)
它可以更快。如果不同的集成應用程序應該以某種方式互連（雖然它在您的方案中沒有說明），那麼他們可能會遭受慢速「過網絡」協議的影響。在單一應用程序中，所有內容都在同一個JVM中。
可能需要更少的服務器。如果您在私有云/某個過時的環境中運行，那麼插入新服務器可能會非常麻煩。你可以得到2-3服務器可爲您的應用程序，這就是它:)
「多集成應用程序」架構（在我的理解它確實類似於微服務架構在整合域）具有以下優點：
更容易升級它的不同部分。如果你有一個單一的應用程序，沒有正常的方法來升級只有部分的API，應該有一個大的升級整個應用程序。如果不同的「整合點」由不同的團隊開發，那麼它們之間的協調並不明顯。
由於之前的項目符號，它可能會花費更少的時間來修復集成點中的錯誤（從檢測到錯誤到生產部署修復時間）。只需修復一個特定的集成點並重新部署即可。它更輕巧。
縮放「更好」。如果您經歷了某個特定集成點的大量使用，則可以輕鬆地在另一臺服務器上添加另一個（或更多）集成點。 在一個單一的方法，你將不得不安裝整個應用程序來實現類似的效果。另一個用例是，如果您部署在雲中，並且您有客戶願意支付對特定集成點的獨佔訪問權限。
更容易測試（可以說）。如果您正在運行集成/系統測試來檢查集成點，那麼您可以組織CI流程，以便系統能夠並行運行。再加上一個更輕量級的啓動，你會得到更靈活的流程。
我可能錯過了比較的一些方面（當然），但這是IMO的方向。
希望這有助於
對於我來說，一個ESB或駱駝基本應用的目標是可重用性和獨特之處尋找資源，你的情況：主要應用程序訪問，安全性和日誌。即使有不同的邏輯爲每個外部系統提供服務。因此，我的方式單一的應用程序。 –