本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# DynamoDB 的路由策略
也許，全域資料表部署中最複雜的部分是管理請求路由。請求必須首先從終端使用者以某種方式選擇和路由到區域。請求在該區域中遇到一些服務堆疊，包括可能由 AWS Lambda函數、容器或 Amazon Elastic Compute Cloud (Amazon EC2) 節點支援的負載平衡器組成的運算層，以及其他可能包括另一個資料庫的服務。該運算層與 DynamoDB 通訊應該使用該區域的本機端點來執行此操作。全域資料表中的資料會複寫到所有其他參與的區域，而且每個區域在其 DynamoDB 資料表周圍都有類似的服務堆疊。
全域資料表會為不同區域中的每個堆疊提供相同資料的本機複本。如果本機 DynamoDB 資料表發生問題，您可以考慮為單一區域中的單一堆疊進行設計，並預期會對次要區域的 DynamoDB 端點進行遠端呼叫。這不是最佳實務。若某個區域出現由 DynamoDB 引起的問題 (或更可能由堆疊中其他元件或依賴 DynamoDB 的服務導致)，建議將終端使用者請求路由至其他區域處理，並使用該區域的運算層與其本機 DynamoDB 端點通訊。此方法可完全避開有問題的區域。為確保系統具備高彈性，需在多個區域間進行運算層與資料層的複寫。
有許多替代技術可將終端使用者請求路由到區域進行處理。最佳選擇取決於您的寫入模式和容錯移轉的考量。本節討論四個選項：用戶端驅動、運算層、Route 53 和 Global Accelerator。
## 用戶端驅動的請求路由
透過下圖所示的用戶端驅動請求路由，終端用戶端 (應用程式、含 JavaScript 的網頁或其他用戶端) 會追蹤有效的應用程式端點 (例如 Amazon API Gateway 端點，而非固定的 DynamoDB 端點)，並依自身內嵌邏輯選擇通訊區域。選擇依據可包含隨機抽樣、最低觀察延遲、最高觀察頻寬或本機執行的運作狀態檢查結果。
用戶端驅動請求路由的優勢在於，能依實際網際網路流量狀況自動調整，並在偵測到性能下降時切換至其他區域。用戶端必須了解所有可用端點，但啟動新的區域端點並不常見。
使用*寫入任何區域*模式時，用戶端可自行選擇偏好的端點。如果對某個區域的存取受損，用戶端可以路由到另一個端點。
透過*寫入單一區域*模式，用戶端需要一種機制，將寫入路由到目前使用中的區域。這可以是簡單的實際測試，以找出目前可接受寫入的區域 (記錄任何寫入拒絕並回退至替代區域)；也可以是較複雜的方式，例如呼叫全域協調器以查詢目前的應用程式狀態 (可能建構於 Amazon 應用程式復原控制器 (ARC) 的路由控制之上，該控制提供一個以五區域仲裁機制維持全域狀態的系統，以支援此類需求)。用戶端可以決定讀取是否可以移轉到任何區域以取得最終一致性，還是必須路由到使用中的區域以取得高度一致性。如需進一步資訊，請參閱 [Route 53 的運作方式](https://docs.aws.amazon.com/r53recovery/latest/dg/introduction-how-it-works.html)。
使用*寫入您的區域*模式時，用戶端必須確定其處理之資料集的主區域。例如，如果用戶端對應一個使用者帳戶，且每個使用者帳戶都連結至一個區域，則用戶端可以從全域登入系統要求適當的端點。
例如，透過網路協助使用者管理其業務金融的金融服務公司，可以使用全域資料表和*寫入您的區域*模式。每個使用者都必須登入中央服務。該服務會傳回憑證，以及這些憑證將在該區域使用的端點。憑證僅在短時間內有效。之後，網頁會自動協商一個新的登入，提供一個可能將使用者活動重定導向新區域的機會。
## 運算層請求路由
如下圖所示，透過運算層請求路由，運算層執行的程式碼會決定是於本機處理請求，或將其轉交給在其他區域執行的相同程式實例。使用*寫入單一區域*模式時，運算層可能偵測自身非作用中區域，允許本機讀取操作，並將所有寫入操作轉送至其他區域。運算層程式碼必須了解資料拓撲與路由規則，並根據最新設定 (定義哪些區域為各資料的作用中區域) 可靠地強制執行。區域內的外層軟體堆疊無需了解微型服務如何路由讀寫請求。在穩健的設計中，接收區域會驗證其是否為寫入操作的目前主要項目。如果不是，則會產生錯誤，指出需要全域狀態需要修改。如果主要區域正在變更，則接收區域也可能會緩衝寫入操作一段時間。在所有情況下，區域中的運算堆疊只會寫入其本機 DynamoDB 端點，但運算堆疊可能會彼此通訊。
Vanguard 集團在 [re:Invent 2022](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s) 中介紹了其使用的路由系統，包括 Global Orchestration and Status Tool (GOaST) 以及 Global Multi-Region Library (GMRlib)。他們採用「追日式」單一主要區域模型。GOaST 維護全域狀態，其運作方式類似於前節所述的 ARC 路由控制。該系統使用全域資料表來追蹤主要區域與下一次主要區域切換的排程時間。所有讀寫操作皆經由 GMRlib 處理，並與 GOaST 協調運作。GMRlib 允許在本機以低延遲執行讀取操作。對於寫入操作，GMRlib 會檢查本機區域是否為目前主要區域。如果是，則寫入操作會直接完成。若非主要區域，GMRlib 會將寫入任務轉送至主要區域的 GMRlib。接收程式庫會確認它也會將自己視為主要區域，如果不是，則會引發錯誤，表示全域狀態的傳播延遲。此方法不直接寫入遠端 DynamoDB 端點，進而提供驗證優勢。
## Route 53 請求路由
Amazon 應用程式復原控制器 (ARC) 是一種網域名稱服務 (DNS) 技術。使用 Route 53 時，用戶端會透過查詢已知的 DNS 網域名稱來請求其端點，Route 53 會傳回與其認為最合適的區域端點對應 IP 位址。這會在下列圖表中進行說明。Route 53 具備多種路由策略，用以決定最適合的區域。Route 53 亦可執行容錯移轉路由，將流量導離運作狀態檢查失敗的區域。
使用*寫入任何區域*模式，或者結合後端運算層請求路由使用，Route 53 可以取得完整存取權限，以根據任何複雜的內部規則 (例如，最近網絡鄰近的區域或最近的地理位置或任何其他選擇) 返回區域。
使用*寫入單一區域*模式，可設定 Route 53 返回目前作用中區域 (透過 Route 53 ARC)。若用戶端需連線至被動區域 (例如進行讀取操作)，可查詢不同的 DNS 名稱。
**注意**
用戶端會快取 Route 53 回應中的 IP 位址一段時間，該時間由網域名稱上的存留時間 (TTL) 設定所指定的時間。較長的 TTL 會延長復原時間點目標 (RTO)，讓所有用戶端辨識新的端點。60 秒是容錯移轉使用的典型值。並非所有軟體都嚴格遵守 DNS TTL 到期設定，且可能存在多層 DNS 快取，例如作業系統層、虛擬機層及應用程式層。
*寫入您的區域*模式時，最好避免使用 Route 53，除非您還使用運算層請求路由。
## Global Accelerator 請求路由
使用 [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)，如下圖所示，用戶端會在 Route 53 中查詢知名網域名稱。不過，用戶端不會傳回對應至區域端點的 IP 地址，而是收到路由至最近 AWS 節點的任何廣播靜態 IP 地址。從該邊緣節點開始，所有流量都會路由到私有 AWS 網路，並透過路由至 Global Accelerator 內維護由路由規則所選擇區域中的某些端點 (例如負載平衡器或 API Gateway)。與使用 Route 53 規則為基礎的路由相比，Global Accelerator 請求路由的延遲較低，因為它可以減少公用網際網路上的流量。此外，由於 Global Accelerator 不依賴 DNS TTL 到期來更新路由規則，因此能更快速地調整流量路由。
透過*寫入任何區域*模式，或者如果與後端的計算層請求路由結合使用，Global Accelerator 可以無縫工作。用戶端會連線到最近的邊緣節點，而且不需要擔心由哪個區域接收請求。
使用*寫入單一區域*的 Global Accelerator 路由規則時，必須將請求傳送到目前使用中的區域。您可以使用運作狀態檢查，以人為方式報告任何區域的故障，而這些區域並未被您的全域系統視為使用中區域。與 DNS 一樣，如果請求可能來自任何區域，則可以使用替代 DNS 網域名稱來路由讀取請求。
使用*寫入您的區域*模式時，最好避免使用 Global Accelerator，除非您同時使用運算層請求路由。