用戶端如何連接 Azure Cosmos DB 對效能有重要影響，尤其是觀察到的用戶端延遲。 Azure Cosmos DB 提供一種簡單且開放的 RESTful 程式設計模型，稱為 閘道 模式（gateway mode）。 此外，它提供一種高效的 TCP 協定，該協定在通訊模型中同樣採用 RESTful，並使用 TLS 進行初始認證與加密流量，稱為 直接 模式。
可用的連接模式
兩種可用的連接模式為：
閘道模式
閘道模式支援所有 SDK 平台。 如果你的應用程式是在有嚴格防火牆限制的企業網路中運行，閘道模式是最佳選擇，因為它使用標準 HTTPS 埠和單一 DNS 端點。 然而，效能的取捨在於使用閘道模式時，每次從 Azure Cosmos DB 讀取或寫入資料都會涉及額外的網路跳躍。 我們也建議在有限套接字連接的環境中執行應用程式時，使用閘道連線模式。
當你在 Azure Functions 中使用 SDK 時，特別是在 Consumption 方案中，請注意目前 連線的限制。
直接模式
直接模式支援透過 TCP 協定連線，使用 TLS 進行初始認證與加密流量，且因網路跳數較少，效能較佳。 應用程式直接連接到後端副本。 直接模式目前僅支援 .NET 和 Java SDK 平台。
這些連接模式基本上會決定資料平面請求（文件讀寫）從你的客戶端機器到Azure Cosmos DB後端分割區的路由。 直接模式是最佳效能的首選;它允許你的客戶端直接開啟 TCP 連線到 Azure Cosmos DB 後端的分割區，並 直接發送請求，無需中介。 相較之下，在閘道模式下，客戶端的請求會被路由到 Azure Cosmos DB 前端的所謂 閘道 伺服器，然後將請求分散到後端的適當分割區。
服務港口範圍
使用直接模式時，你需要確保客戶端能存取介於 10000 到 20000 之間的埠口，因為 Azure Cosmos DB 使用動態 TCP 埠口。 除此之外，還有閘道埠。 在私 有端點使用直接模式時，Azure Cosmos DB 可使用從 0 到 65535 的全範圍 TCP 埠。 如果你的客戶端這些埠口沒有開啟，而你嘗試使用 TCP 協定，可能會收到「503 服務不可用」的錯誤訊息。
下表總結了各種 API 可用的連接模式及各 API 所使用的服務埠口：
| 連線模式 | 支援的通訊協定 | 支援的 SDK | API/服務連接埠 |
|---|---|---|---|
| Gateway | HTTPS | 所有 SDK | SQL （443）、MongoDB （10255）、Table （443）、Cassandra （10350）、Graph （443） |
| 直接 | TCP（透過 TLS 加密） | .NET SDK Java SDK | 使用公用/服務端點時：10000 到 20000 範圍中的連接埠 使用私人端點時：0 到 65535 範圍中的連接埠 |
直接模式連接架構
如 前述所述，直接模式用戶端透過 TCP 協定直接連接後端節點。 每個後端節點代表屬於實體分區的副本集中的一個副本。
路由
當 Azure Cosmos DB SDK 在直接模式下執行操作時，需要解析要連接哪個後端副本。 第一步是知道操作應該送到哪個實體分割區，為此，SDK 會從閘道節點取得包含 分割區金鑰定義 的容器資訊。 同時也需要包含副本 TCP 位址的路由資訊。 路由資訊也可從閘道節點取得，兩者皆視為 控制平面元資料。 一旦 SDK 取得路由資訊，即可繼續開啟屬於目標實體分割區的副本的 TCP 連線並執行操作。
每組副本包含一個主副本和三個次要副本。 寫入操作始終路由至主要副本節點，而讀取操作則可由主節點或次節點執行。
由於容器和路由資訊不常變動，這些資訊會被快取在 SDK 上，讓後續操作能從中受益。 已建立的 TCP 連線也會在各作業間重複使用。 除非透過 SDK 選項另行配置，否則連線會在 SDK 實例的整個生命週期內永久維持。
如同任何分散式架構，持有複本的機器可能會進行升級或維護。 該服務確保副本集保持一致性，但任何副本移動都會導致現有的 TCP 位址變更。 在這些情況下，SDK 需要更新路由資訊，並透過新的閘道請求重新連接到新地址。 這些事件不應該影響整體 P99 SLA。
連接量
每個實體分割區包含一組包含四個副本的副本，為了提供最佳效能，SDK 最終會開放連接所有副本，以處理混合寫入與讀取操作的工作負載。 並行操作會在現有連線間進行負載平衡，以利用每個副本所提供的吞吐量。
有兩個因素決定 SDK 開啟的 TCP 連線數量：
實體分割區的數量
在穩定狀態下，SDK 每個副本和每個實體分割區都有一個連線。 容器中實體分割區數量越多，開啟連線數量也越多。 由於操作被路由到不同的分區，連線會按需建立。 平均連線數則為物理分割區數乘以四。
同時請求量
每個建立的連線可同時提供可配置數量的並行操作。 如果並行運算的數量超過這個門檻，表示有新的連線開放以服務這些連接，而對於物理分割區來說，開啟連線數量可能會超過穩態數值。 這種行為是預期的，適用於可能發生運行量激增的工作負載。 對於 .NET SDK 來說，這個設定是由 MaxRequestsPerTcpConnection 設定的，而對於 Java SDK 來說，你可以使用 DirectConnectionConfig 類別來自訂。
預設情況下，連線會被永久維護以提升未來操作的效能（開啟連線會產生計算負擔）。 有些情況你可能會想關閉一段時間未使用的連線，並理解這可能會稍微影響未來的營運。 對於 .NET SDK，這個設定是由 IdleTcpConnectionTimeout 設定的，而對於 Java SDK 則可以用 DirectConnectionConfig 類別來自訂。 不建議將這些配置設為低值，因為這可能導致連線頻繁關閉，影響整體效能。
語言特定的實作詳細數據
如需語言的相關實作詳細數據，請參閱：
後續步驟
針對特定的 SDK 平台效能優化：
正在嘗試為遷移至 Azure Cosmos DB 進行容量規劃嗎？ 您可以使用現有資料庫叢集的相關資訊進行容量規劃。
- 如果你只知道現有資料庫叢集中的 vcore 和伺服器數量，可以看看 如何用 vCore 或 vCPU 來估算請求單元。
- 如果您知道目前資料庫工作負載的一般要求率，請參閱使用 Azure Cosmos DB 容量規劃工具來評估要求單位。