View a markdown version of this page

依抽象模式分支 - AWS 方案指引

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

依抽象模式分支

當您可以在整體周邊攔截呼叫時，strangler fig 模式運作良好。不過，如果您想要將存在於舊版應用程式堆疊中更深且具有上游相依性的元件現代化，建議您依抽象模式來分支。此模式可讓您變更現有的程式碼基礎，讓現代化版本與舊版安全地共存，而不會造成中斷。

若要透過抽象模式成功使用分支，請遵循此程序：

  1. 識別具有上游相依性的整合元件。

  2. 建立抽象層，代表要現代化之程式碼與其用戶端之間的互動。

  3. 當抽象化就位時，請將現有的用戶端變更為使用新的抽象化。

  4. 使用整合之外的重做功能建立新的抽象實作。

  5. 準備好時，將抽象概念切換到新實作。

  6. 當新實作提供所有必要功能給使用者，且整體不再使用時，請清除較舊的實作。

依抽象模式劃分的分支通常與功能切換混淆，這也可讓您逐步變更系統。差別在於功能切換旨在允許開發新功能，並在系統執行時讓使用者看不到這些功能。因此，功能切換會在部署時間或執行時間使用，以選擇應用程式中是否顯示特定功能或一組功能。依抽象分割是一種開發技術，可與功能切換結合，以在舊實作和新實作之間切換。

下表說明依抽象模式使用分支的優點和缺點。

優點 缺點

  • 允許在發生錯誤 （回溯相容） 時可還原的增量變更。

  • 當您無法在單體邊緣攔截對單體的呼叫時，可讓您擷取在單體內部深處的功能。

  • 允許多個實作在軟體系統中共存。

  • 透過使用中繼驗證步驟來呼叫新的和舊的功能，提供簡單的方法來實作備用機制。

  • 支援持續交付，因為您的程式碼在整個重組階段一直運作。

  • 如果涉及資料一致性，則不適用。

  • 需要變更現有系統。

  • 可能會為開發程序增加更多額外負荷，特別是在程式碼基底結構不良時。（在許多情況下，上行值得額外的努力，而重組越大，考慮透過抽象模式使用分支就越重要。)

下圖顯示保險體中通知元件的分支抽象模式。首先建立通知功能的摘要或界面。以小幅度遞增，現有用戶端會變更為使用新的抽象。這可能需要搜尋程式碼基底，以呼叫與通知元件相關的 APIs。您會建立通知功能的新實作，做為整體外部的微服務，並將其託管在現代化架構中。在整體中，您新建立的抽象界面充當中介裝置，並呼叫新的實作。以小幅度遞增，您可以將通知功能移植到新實作，直到完全測試並就緒為止，都會保持非作用中狀態。當新實作準備就緒時，您可以切換抽象以使用它。建議您使用可輕鬆翻轉的切換機制 （例如功能切換），以便在遇到任何問題時輕鬆切換回舊功能。當新的實作開始為您的使用者提供所有通知功能，且不再使用整體時，您可以清除舊的實作，並移除您可能已實作的任何切換功能旗標

透過抽象模式使用分支將整體分解為微服務