我來講講實務面 原PO可以先用看看Open Source ActiveMQ當做middleware http://activemq.apache.org/ 畢竟用IBM MQ或Tibco RV都不是一般小公司付得起 原PO如果理解鬆散耦合的概念，應該也認同"針對interface定義" 所以要定義spec，雖然說沒有規定什麼格式，但用XML好處還蠻多的 每個XML定義一個功能，也就是message，這些message透過middleware 在新舊系統之間傳送 新舊系統需要針對端口增加adapter功能，主要就是處理interface的轉換 這當中可能會有一些business model要做細部處理 例如A系統把message丟到B系統傳送一份詢價單，丟到C系統確認庫存 A系統要等到B、C回傳結果message才能做後續處理 另外因為採用了middleware，各系統間的通訊由middleware管理 就不用各系統互相建立連線，降低了管理上的難度 管理上就要確保middleware不要掛點 當然如果連一個messsage也不漏失、具有failover、load balancing與跨router 功能，IBM MQ或Tibco RV或許是更好的選擇 ※ 引述《fayhong (恰似飛鴻踏雪泥)》之銘言： : 最近碰到客戶對 ESB (Enterprise Service Bus) 這種架構情有獨鍾， : 不知道諸位 300W 年薪的大師們，對這個產品在導入時有什麼經驗， : 可以分享給我漲姿勢一下嗎？ : 文有點短，好，我先說我的想法。 : 首先，我沒有使用 ESB 的經驗，所以不能說好或壞，所幸我走過 Java : 的黃金歲月，卻沒有使用過 ESB，不知這是好還是不好。 : 然而，在 legacy 系統較多的企業環境裡，需要 ESB 做一個抽象層整合， : 好讓舊系統間盤根錯節的串接關係可以進行解耦，增加後續系統的維護度 : 以及未來新系統的建置彈性。 : 以上，是我對 ESB 的使用場景的想法，必須存在在幾個前提之下得以發揮： : 1. 有很多 legacy 系統與封閉架構的套裝軟體 : 2. 系統間相依性複雜，缺乏清楚明確分界，內部關係與資料串接紊亂 : 3. 公司對於私有雲缺乏管理能力，故需再買一套套裝軟體來管理其他的套 : 裝軟體，而不是叫大家都上私有雲 : 4. 特定軟體對硬體要求高，使用場景特殊(例，安全需求)，因此無法輕易 : 放上雲端 : 以上是我自己的淺見，不知各位有什麼經驗與想法呢？ --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.166.181.99 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1535155508.A.EB0.html