本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 方法 3：使用訊息佇列進行解耦
<a name="queue"></a>

在此方法中，共享程式 AB.1 會轉換為 Java 程式，並遷移至雲端做為應用程式 A 的一部分。訊息佇列會用作雲端中重構應用程式與內部部署中舊版應用程式之間的界面。透過使用此方法，您可以將緊密聯結的大型主機應用程式分解為生產者和消費者，使它們更模組化，以便它們可以獨立運作。其他優點是您可以在不同的波中遷移應用程式。

我們建議您在下列情況下使用此方法：
+ 位於大型主機上的應用程式可以透過訊息佇列與雲端中的遷移應用程式進行通訊。
+ 無法維護程式 AB.1 的多個複本 （例如，內部部署複本和雲端複本，如先前兩種方法所示）。
+ 佇列架構模式符合大型主機上應用程式的商業需求，因為它涉及重新架構現有應用程式。
+ 不屬於第一波的應用程式需要更長的時間 (6 個月或更久） 才能遷移至雲端。

## 在不同的波中遷移應用程式
<a name="queue-multi-wave"></a>

當應用程式太大而無法分組到相同的遷移波時，您可以多個波遷移它們，如下圖所示，並在遷移期間保持服務連續性。透過此方法，您可以分階段現代化您的應用程式，而無需綁定在一起。

 ![\[Migrating mainframe applications that share programs: using a message queue and multiple migration waves\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-3-diff.png) 

如果您使用這種方法，請遵循下列步驟：

1. 將應用程式 A 及其相關聯的程式遷移 （重構） 至雲端，同時應用程式 B 繼續駐留在內部部署。

1. 重構應用程式 A （在雲端），透過訊息佇列與應用程式 B （內部部署） 通訊。

1. 重構現場部署的應用程式 B，將共用程式 AB.1 取代為透過訊息佇列傳送訊息至應用程式 A 並從中接收訊息的代理程式。

1. 成功遷移應用程式 A 後，請淘汰內部部署應用程式 A 及其元件 （包括共用程式）。應用程式 B 及其元件會繼續駐留在內部部署。

1. 在下一組遷移波中，遷移應用程式 B 及其元件。鬆散耦合的佇列架構會繼續做為雲端應用程式 A 和 B 之間的界面。這可減少應用程式 B 的重構工作，而不會影響應用程式 A。