回源政策參數

Last updated on 

延續建立回源政策（Origin Policy），這篇文章將會介紹域名管理 / 回源政策的各項參數。首先，找到操作的欄位，按下修改 ninorigin。

回源政策 / 修改 ninorigin

可以看到與回源政策有關的參數，分成以下 1 個類別。說明如下：

回源政策 / 參數

基礎（Essential）

  • 回源（Origins）：下有四個參數，分別是 Origins、Weight、Enabled、As Backup。
  1. Origins：域名的源站，用來處理或回應請求的伺服器（Origin Server），此即 ninorigin.ninja.tw。
  2. Weight：源站的比重，可搭配下方的 loadbalancerMethod 設定。此處設定為 1。
  3. Enabled：是否啟用源站。
  4. As Backup：是否作為備援。
  • 回源協議（Originscheme）：請求會用哪種通訊協議（http、https、static） 從節點送至源站。
回源政策 / 回源協議
  • 端口映射（PortMappingType）：請求從節點送至源站時，要使用哪種方式（default、static）設定源站的端口。
回源政策 / 端口映射
  • 回源端口（OriginPort）：端口映射選擇 default 時，源站要設定哪個端口來連線。
  • loadbalancerMethod：有三種分配流量的方式，分別是 IP Hash、Round Robin、Weight。
  1. IP Hash：預設值，平台會透過用戶 IP 進行計算，並將同一個 IP 分配給同一個源站進行處理。假設客戶的 IP 是 1.1.1.1，經過計算後是由 Origin Server-1 處理，下次同一個客戶再度訪問時，將仍由 Origin Server-1 回應。
  2. Round Robin：隨機分配，假設客戶的 IP 是 1.1.1.1，每次的請求都會隨機由相同或不相同的 Origin Server 處理。
  3. Weight：比重，假設你有兩個源伺服器，並設定 Origin Server-1 和 Origin Server-2 的權重是 3:2。每五次的請求中，會有三次由 Origin Server-1 處理，另外兩次則由 Origin Server-2 回應。
回源政策 / loadbalancerMethod
💡
權重越大(1<2<3)，edge去那個回源的機率就愈高
  • loadbalancerSticky：可搭配 loadbalancerMethod 的 Round Robin 和 Weight 使用，方便同一個使用者的請求皆由相同的源站進行處理。
💡
你可能會好奇 loadbalancerMethod 的 Round Robin 和 Weight 若搭配 loadbalancerSticky，效果即和 IP Hash 相似。在極端的情況下，IP Hash 可能會使流量集中在特定的源站。這時你可以將 loadbalancerMethod 改成 Round Robin 或 Weight，並開啟 loadbalancerSticky 的開關，以解決流量分配不均的問題，同時保有客戶的 Cookie 或 Session 等資訊。
  • healthCheckMode：使用哪種方式（TCP、HTTP）實行節點至源站的健康度檢查。
  • healthCheckUri：當 healthCheckMode 為 HTTP 時，源站可設定特定路徑，供節點傳送 HTTP 請求。
  • healthCheckHttpCode：當 healthCheckMode 為 HTTP 時，源站回傳哪些 HTTP 狀態碼，才判定該源站健康。
  • healthCheckInterval：每隔多少秒數實行節點至源站的健康度檢查。
  • healthCheckTimeout：實行節點至源站的健康度檢查時，若源站在多少毫秒內沒有回應，即結束該次健康度檢查。
  • healthCheckSuccess：節點至源站的健康度檢查必須連續成功幾次，才判定該源站健康。
  • healthCheckFail：節點至源站的健康度檢查必須連續失敗幾次，才判定該源站不健康。