很多軟件開發人員構建分布式應用時都離不開中間件的支撐，不過要在什么架構和中間件是最好的這個問題上達成共識就更困難了。本文探討為什么組件耦合會帶來特別的挑戰，以及云計算是如何通過微服務等來引入這一系列變化的。
驅動分布式應用的應用或架構需要能夠同時控制組件耦合和中間件。這意味著確定主要耦合模型，從云角度考慮組件耦合模型和趨勢，在開發中將耦合模型分類，以及將組件耦合和中間件架構關聯起來。
在應用組件之間傳遞工作是分布式開發的核心需求，也是軟件組件重用策略的基準。云所具有的關聯組件化和耦合效率帶來資源的高效和敏捷，這決定性得揭示了耦合組件以及開發分布式軟件的最佳方式。理解基礎中間件耦合方案至關重要。
中間件耦合的最基本問題是被調和調用進程是否是實時同步的。這意味著所要求的服務只在其可以被接受的時候才會被分發，這在耦合中加入了多線程限制，除非整個應用程序是單線程的。如今，傳遞消息的接口支持實時耦合，基于消息的中間件支持基于隊列的解耦合，從而在有多個請求并且目的地組件不在線時，能夠允許處理消息的組件將消息聚合。
中間件耦合領域需要解決的第二個問題是服務請求是阻隔的還是非阻隔的。當消息發送后，理論上說，發送方可以等待回復（阻隔）或者繼續做其他事情（非阻隔）——接受組件也與之類似。其他組件的阻隔調用會在服務完成并且返回結果前將調用進程停止，這很容易實現。當使用非阻隔耦合時，應用程序需要識別發送到別處處理的消息回復，這要求更精細的應用程序實現。該模型通常稱為事件處理器，因為它要求組件處理異步呈現的工作。
讓我們轉向云開發。云推動了RESTful模型的流行。該模型下，消息傳遞給無狀態組件處理。在無狀態模型里，每個消息作為一個完整的實體處理，RESTful組件的調用者負責在一系列工作請求鏈里維護上下文或者狀態——比如在事務處理里會發生什么。
針對組件間工作流管理的RESTful方案，和更為傳統的通常和CORBA以及SOA一起使用的遠程過程調用（RPC）模型相對比。使用RPC方案，應用程序組件通過把遠程組件當做本地調用而對其做操作。因此，調用組件的上下文和狀態和被調用組件是緊耦合的。
使用合適的組件設計方案，RPC模型能夠支持時間同步和異步兩種方式，以及阻隔和非阻隔消息處理。主要由支持大量并發事件的Web服務器應用程序設計的RESTful接口，自然會更偏向于異步。良好的云組件設計傾向于鼓勵使用事件處理器，和非阻隔應用程序設計模式。
中間件耦合的最后一點和方向性相關。在傳統中間件架構里，開發人員可以構建雙向（請求/響應）流，或者可以構建單向（一個方向）流，這里請求和響應是單獨事件，通過消息內容，而不是流程狀態相關聯。消息處理接口通常用于雙向流，基于消息的中間件內容（MOM）的概念通常用于單向流。
中間件耦合問題，特別隨著向云技術的演進，將應用當作一系列進程而不是一系列組件可以很好得控制這個問題。一個Web應用程序線程在客戶端形態各異，在服務器端差異不大。大多數情況下，展示給用戶的客戶端天然是單線程和阻隔的。如果你的應用程序可以使用該模型，那么設計本質上就是一個Web應用，并且主要遵循RESTful原則。這時，必須為耦合使用最小的中間件支持，并且在Web兼容性上關注于中間件的選擇。
真正分布式處理中的事務線程是工作流事件鏈。通常最好使用服務或者消息總線以及流程語言引擎來緩解這樣的耦合。將這樣的方案應用到云環境里會創建出比很多應用程序規劃師和架構師想要的更為嚴格的耦合性，但是避免這樣的方案則要求每個事務一個線程，這在很多場景下可實現，但是要求特別的設計。消息里的狀態管理，和基于消息的中間件以及RESTful接口，能夠創造出適合云的框架。
中間件耦合的三大主要問題可以通過云上的實踐，比如微服務，來加以解決，但是不可否認MOM模型更容易實現。但是，組件可以聚合起來，在其內部使用不同的機制解決耦合問題。在Web應用程序里，這樣的方案很常見，在前端使用RESTful耦合客戶端線程，然后后臺實現基于MOM的事務處理。
重點是耦合組件必須首先基于應用作優化，然后選擇中間件和接口來支持這個優化過的模型。當這么做時，使用最簡單的中間件架構和最開放的實現。這樣會讓你的方案盡可能得開放。
京公網安備 11010502049343號