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

使用 DynamoDB 全域資料表請求路由

也許，全域資料表部署中最複雜的部分是管理請求路由。請求必須首先從終端使用者以某種方式選擇和路由到區域。請求在該區域中會遇到一些服務堆疊，包括運算層，該層可能由 AWS Lambda函數、容器或 Amazon Elastic Compute Cloud （AmazonEC2） 節點支援的負載平衡器組成，也可能由其他服務組成，包括另一個資料庫。該運算層與 DynamoDB 通訊應該使用該區域的本機端點來執行此操作。全域資料表中的資料會複寫到所有其他參與的區域，而且每個區域在其 DynamoDB 資料表周圍都有類似的服務堆疊。

全域資料表會為不同區域中的每個堆疊提供相同資料的本機複本。如果本機 DynamoDB 資料表發生問題，您可以考慮為單一區域中的單一堆疊進行設計，並預期會對次要區域的 DynamoDB 端點進行遠端呼叫。這不是最佳實務。跨區域相關的延遲可能比本機存取高 100 倍。在 back-and-forth本機執行 5 個請求的序列可能需要幾毫秒，但在跨越地球時可能需要幾秒鐘。建議最好將終端使用者路由到另一個區域進行處理。為了確保彈性，您需要跨越多個區域進行複寫，複寫運算層和資料層。

有許多替代技術可將終端使用者請求路由到區域進行處理。最佳選擇取決於您的寫入模式和容錯移轉的考量。本節討論四個選項：用戶端驅動、運算層、Route 53 和 Global Accelerator。

用戶端驅動的請求路由

使用用戶端驅動的請求路由，例如應用程式、具有 JavaScript 另一個用戶端的網頁等最終使用者用戶端將追蹤有效的應用程式端點。在這種情況下，這將是應用程式端點，例如 Amazon API Gateway，而不是常值 DynamoDB 端點。最終使用者用戶端使用自己的內嵌邏輯來選擇要與哪個區域通訊。它可以根據隨機選擇、觀察到的最低延遲、觀察到的最高頻寬測量或本機執行的運作狀態檢查來選擇。

用戶端驅動的請求路由優點在於，它可以適應現實世界的公共網際網路流量狀況等情況，以便在發現任何性能下降時切換區域。用戶端必須瞭解所有可用端點，但啟動新的區域端點並不常見。

透過寫入任何區域模式，用戶端可以單方面選取其偏好的端點。如果對某個區域的存取受損，用戶端可以路由到另一個端點。

透過寫入單一區域模式，用戶端需要一種機制，將寫入路由到目前使用中的區域。這可以像實證測試哪個區域目前接受寫入 （注意任何寫入拒絕並返回替代） 一樣基本，或像呼叫全域協調器來查詢目前應用程式狀態一樣複雜 （可能是建置在 Route 53 應用程式復原控制器 （ARC） 路由控制上，該控制提供 5 區域以法定人數驅動的系統，以維持全域狀態，滿足此類需求）。用戶端可以決定讀取是否可以移轉到任何區域以取得最終一致性，還是必須路由到使用中的區域以取得高度一致性。如需進一步資訊，請參閱 Route 53 的運作方式。

使用寫入您的區域模式時，用戶端必須確定其處理之資料集的主區域。例如，如果用戶端對應一個使用者帳戶，且每個使用者帳戶都連結至一個區域，則用戶端可以從全域登入系統要求適當的端點。

例如，透過網路協助使用者管理其業務金融的金融服務公司，可以使用全域資料表和寫入您的區域模式。每個使用者都必須登入中央服務。該服務會傳回憑證，以及這些憑證將在該區域使用的端點。憑證僅在短時間內有效。之後，網頁會自動協商一個新的登入，提供一個可能將使用者活動重定導向新區域的機會。

運算層請求路由

透過運算層請求路由，在運算層中執行的程式碼會決定是否要在本機處理請求，或將它傳遞給在另一個區域中執行的自身複本。當您使用寫入單一區域模式時，運算層可能會偵測到它不是使用中的區域，並允許本機讀取操作，同時將所有寫入操作轉送至另一個區域。此運算層程式碼必須知道資料拓撲和路由規則，並根據指定哪些區域為哪些資料使用中的最新設定，強制可靠的執行這些規則。區域內的外部軟體堆疊不需要知道微服務如何路由讀取和寫入請求。在穩健的設計中，接收區域會驗證其是否為寫入操作的目前主要項目。如果不是，則會產生錯誤，指出需要全域狀態需要修改。如果主要區域正在變更，則接收區域也可能會緩衝寫入操作一段時間。在所有情況下，區域中的運算堆疊只會寫入其本機 DynamoDB 端點，但運算堆疊可能會彼此通訊。

在此案例中，假設金融服務公司使用單一 follow-the-sun主要模型。他們使用系統和程式庫來進行此路由程序。其整體系統會維護全域狀態，類似於 AWS的ARC路由控制。他們使用全域資料表來追蹤哪個區域是主要區域，以及排定下一個主要交換器的時間。所有的讀取和寫入操作都經過程式庫，該程式庫與它們的系統進行協調。該程式庫允許在本機上以低延遲執行讀取操作。對於寫入操作，應用程式會檢查本機區域是否為目前的主要區域。如果是，則寫入操作會直接完成。如果沒有，則程式庫會將寫入任務轉送至目前主要區域中的程式庫。接收程式庫會確認它也會將自己視為主要區域，如果不是，則會引發錯誤，表示全域狀態的傳播延遲。此方法不直接寫入遠端 DynamoDB 端點，進而提供驗證優勢。

Route 53 請求路由

Amazon Application Recovery Controller （ARC） 是一種網域名稱服務 （DNS） 技術。使用 Route 53 時，用戶端會尋找知名的DNS網域名稱來請求其端點，而 Route 53 會傳回對應於其認為最適當的區域端點的 IP 地址 （IP）。Route 53 有一份用於決定適當區域的路由政策的清單。Route 53 也可以執行容錯移轉路由，以將流量路由傳送出運作狀態檢查失敗的區域。

Global Accelerator 請求路由

用戶端使用 AWS Global Accelerator 在 Route 53 中查詢已知的網域名稱。不過，用戶端不會傳回對應至區域端點的 IP 地址，而是收到路由至最近 AWS 邊緣位置的任何廣播靜態 IP 地址。從該邊緣位置開始，所有流量都會在私有 AWS 網路上路由至 Global Accelerator 中維護的路由規則所選擇的區域中的某些端點 （例如負載平衡器或API閘道）。與使用 Route 53 規則為基礎的路由相比，Global Accelerator 請求路由的延遲較低，因為它可以減少公用網際網路上的流量。此外，由於 Global Accelerator 不依賴DNSTTL過期來變更路由規則，因此可以更快地調整路由。