代理模式-常用的架構設計原則

建立代理客戶服務或應用程式發送網絡請求的協助程式服務。 代理服務可以看作是與用戶端置位于同一位置的程序外代理。

此模式可用于以一種與語言無關的方式承載常見用戶端連接配接任務，如監視、記錄、路由、安全（如 TLS）和複原模式。 它通常用于舊版應用程式或其他很難修改的應用程式，以擴充其網絡功能。 它還可以使一個專業團隊能夠實作這些功能。

上下文和問題

基于雲的可複原應用程式需要斷路、路由、計量和監視等功能，以及能夠進行與網絡相關的配置更新。 要更新舊版應用程式或現有代碼庫來添加這些功能可能比較困難，或者根本不可能，因為開發團隊已不再維護或不能輕易修改代碼。

網絡調用可能也需要大量連接配接、授權和認證配置。 如果這些調用跨多個應用程式使用，并且是使用多種語言和架構建構的，則必須分别每個執行個體配置調用。 此外，網絡和安全功能可能需要組織中的中心團隊來管理。 由于代碼庫很大，團隊更新不熟悉的應用程式代碼時可能會有風險。

解決方案

将用戶端架構和庫放到一個外部程序中，該程序充當應用程式和外部服務之間的代理。 将代理部署在與應用程式相同的主機環境中，以允許對路由、複原能力、安全功能進行控制，并避免出現與主機相關的通路限制。 還可以使用代理模式标準化和擴充檢測。 代理可以監視性能名額（如延遲或資源使用狀況），且在與應用程式相同的主機環境中執行此監視。

放到代理的功能可獨立于應用程式進行管理。 可以更新和修改代理，而不影響應用程式的舊功能。 單獨、專業的團隊還可以實施和維護已轉移給代理的安全、網絡或身份驗證功能。

代理服務可部署為 sidecar 以伴随使用應用程式或服務的生命周期。 或者，如果代理由公共主機上的多個單獨程序所共享，則可将其部署為守護程式或 Windows 服務。 如果使用服務進行了容器化，那麼代理應該建立為同一個主機上的單獨容器，并且配置适當的連結用于通信。

問題和注意事項

• 代理會添加一些延遲開銷。 請考慮使用應用程式直接調用的用戶端庫是否是更好的方法。
• 請考慮在代理中包含通用功能可能帶來的影響。 例如，代理可以處理重試操作，但這可能不安全，除非所有操作都是幂等的。
• 請考慮一種允許用戶端将一些上下文傳遞到代理，同時也可傳遞回用戶端的機制。 例如，包含 HTTP 請求标頭以選擇退出重試，或指定最大重試次數。
• 請考慮如何打包和部署代理。
• 考慮是讓所有用戶端使用一個共享執行個體還是讓每個用戶端單獨使用一個執行個體。

何時使用此模式

在以下情況中使用此模式：

• 需要為多種語言或架構建構一組通用的用戶端連接配接功能。
• 需要将跨領域用戶端連接配接性問題轉移給基礎結構開發人員或其他更專業化的團隊。
• 需要在舊版應用程式或難以修改的應用程式中支援雲或群集連接配接需求。

此模式可能不适用于以下情況：

• 網絡請求延遲嚴重。 代理将産生一些開銷，雖然是最小開銷，但在某些情況下，仍然可能會影響應用程式。
• 用戶端連接配接功能僅用于一種語言。 在這種情況下，最好以包的形式将用戶端庫分發給開發團隊。
• 連接配接功能無法通用化，且需要與用戶端應用程式進行更深層的內建。