多區域基礎 3：瞭解您的工作負載相依性

特定工作負載在一個區域中可能有多個相依性，例如使用的AWS服務、內部相依性、協力廠商相依性、網路相依性、憑證、金鑰、密鑰和參數。為了確保工作負載在失敗情況下的操作，主要區域和待命區域之間應該沒有相依性；每個區域都應該能夠彼此獨立運作。為了實現這一目標，必須仔細檢查工作負載中的所有相依性，以確保它們在每個區域中都可用。這是必要的，因為主要區域中的故障不應該對待命區域產生影響。此外，當相依性處於降級狀態或完全無法使用時，工作負載如何運作的知識是必要的，因此可以設計解決方案以適當處理此問題。

3a：AWS服務項目 

在設計多區域架構時，需要了解將要使用的特定AWS服務。第一個方面是了解該服務具有哪些功能才能實現多區域，以及是否必須設計解決方案才能實現多區域目標。例如，使用 Amazon Aurora 和 Amazon DynamoDB 時，您可以將資料以非同步方式複寫到待命區域的功能。任何AWS服務相依性都必須在要執行工作負載的所有區域中提供使用。為了確保將使用的服務在所需的地區可用，請查看 AWS 區域al 服務清單。 

3b：內部和第三方相依性

對於工作負載具有的任何內部相依性，請確保工作負載將在其中運作的區域中可用。例如，如果工作負載是由許多微型服務組成，請瞭解構成商業能力的所有微服務。從那裡，確保所有這些微服務都部署在工作負載將運行出來的每個區域中。

不建議在工作負載內的微服務之間進行跨區域呼叫，並且應該保持區域隔離。 這是因為建立跨區域相依性會增加相關失敗的風險，這會否定您嘗試透過工作負載的隔離區域實作來達成的好處。內部部署相依性也可能是工作負載的一部分，因此必須瞭解這些整合的特性在主要區域變更時會如何變更。例如，如果待命區域位於離內部部署環境更遠，則延遲增加將產生負面影響。

瞭解軟體即服務 (SaaS) 解決方案、軟體開發套件 (SDK) 及其他協力廠商產品相依性，並能夠執行這些相依性降級或無法使用的情境，將提供更深入的瞭解系統鏈在不同故障模式下的運作和行為。這些相依性可能位於應用程式程式碼中，從使用 AWS Secrets Manager 或第三方保存庫解決方案 (例如 Hashicorp) 進行外部管理的密碼，再到依賴 IAM 身分中心以進行聯合登入的身份驗證系統。

在依賴關係方面具有冗餘可以幫助提高彈性。SaaS 解決方案或協力廠商相依性也可能使用與工作負載相同的主要AWS 區域項目。在這種情況下，您應該與廠商合作，以確定其彈性狀態是否符合工作負載的需求。

此外，請注意工作負載及其相依性之間的共同命運，例如第三方應用程式。如果在容錯移轉之後，次要區域中 (或從) 無法使用相依性，則工作負載可能無法完全復原。

3c：故障轉移機制

網域名稱系統 (DNS) 通常用作容錯移轉機制，將流量從主要區域轉移到待命區域。仔細檢閱和審查容錯移轉機制採用的所有相依性。例如，如果您的工作負載使用 Amazon Route 53，瞭解控制平面託管在 US-EAST-1 中，表示您正在依賴該特定區域中的控制平面。如果主要區域也是 US-EAS-1，則不建議將其作為容錯移轉機制的一部分。如果使用另一種容錯移轉機制，則需要深入瞭解無法如預期運作的任何案例。一旦建立了這種理解，計劃應變或發展一個新的機制，如果需要的話。請參閱使用 Amazon Route 53 建立災難復原機制，以了解可用於成功容錯移轉的方法。

如內部相依性一節所述，屬於商務功能一部分的所有微服務都必須在部署工作負載的每個區域中提供使用。作為容錯移轉策略的一部分，業務功能需要同時進行容錯移轉，以消除跨區域呼叫的機會。或者，如果微服務容錯移轉獨立，這會導致微服務可能進行跨區域呼叫的不良行為的可能性，這會導致延遲，並可能導致工作負載在用戶端逾時的情況下無法使用。

3d：配置依賴關係

憑證、金鑰、機密和參數是針對多區域進行設計時所需的相依性分析的一部分。如果可能的話，最好在每個區域內本地化這些元件，這樣它們就不會因為這些相依性在區域之間有共同命運。對於憑證，憑證的到期應該會有所不同，如果可能的話，在每個區域中，以避免憑證過期 (設定為預先通知的警示) 影響多個區域的情況。

加密金鑰和密碼也應該是特定於區域的。如此一來，如果金鑰或機密的輪換發生錯誤，則影響僅限於特定區域。

最後，任何工作負載參數都應儲存在本機，以便在特定區域擷取工作負載。

關鍵指引

• 多區域架構受益於區域之間的實體和邏輯區隔。在應用程式層引入跨區域相依性可打破這項優勢。避免這種依賴關係。

• 容錯移轉控制應在主要區域上沒有相依性的情況下運作。

• 需要完成業務功能的協調容錯移轉，以消除跨區域呼叫延遲增加和依賴性的可能性。