Kong（V1.0.2）loadbalancing

Kong為多個後端服務提供了多種負載平衡請求的方法:一種簡單的基于DNS-based的方法，以及一種更動态的環形負載均衡器ring-balancer，它還允許在不需要DNS伺服器的情況下使用service registry。

當使用基于DNS-based的負載均衡時，後端服務的注冊是在Kong之外完成的，Kong隻從DNS伺服器接收更新。

如果主機名解析為多個IP位址，則使用包含主機名(而不是IP位址)的主機定義的每個服務将自動使用基于DNS-based的負載平衡，前提是主機名不解析為​<code>​upstream​</code>​ 名稱或DNS主機檔案中的名稱。

DNS記錄ttl設定(生存時間)決定重新整理的頻率。當ttl為0時，每個請求每次都将使用自己的DNS查詢來解析。很明顯，這将帶來性能損失，但是更新/更改的延遲非常低。

一條記錄包含一個或多個IP位址。是以，當hostname 解析為a記錄時，每個後端服務必須有自己的IP位址。

因為沒有權重資訊，是以在負載均衡器中所有條目的權重都是相等的，均衡器将執行直接的循環。

SRV記錄包含其所有IP位址的權重和端口資訊。後端服務可以通過IP位址和端口号的唯一組合來辨別。是以，一個IP位址可以在不同的端口上承載相同服務的多個執行個體。

因為權重資訊是可用的，是以每個條目将在負載均衡器中獲得自己的權重，并執行權重循環。

類似地，來自DNS伺服器的端口資訊将覆寫任何給定的端口資訊。如果一個服務具有host=myhost.com和port=123的屬性，并且myhost.com解析為一個SRV記錄127.0.0.1:456，那麼請求将被代理到http://127.0.0.1:456/somepath，因為端口123将被456覆寫。

DNS解析器将開始解析以下記錄類型，順序如下:

前面解析的最後一個成功類型

SRV記錄

一個記錄

CNAME記錄

此順序可通過​​dns_order configuration property​​進行配置。

每當重新整理DNS記錄時，都會生成一個清單來正确處理權重。盡量保持權重作為彼此保持算法性能的倍數,例如,兩個權重17和31将轉化為527的entries ,而權重16和32(或最小等價1和2)會導緻結構僅僅3entries ,尤其是在一個非常小的(甚至0)ttl值。

某些命名伺服器不傳回所有entries (由于UDP包的大小)，在這種情況下(例如，Consul 傳回最多3entries )，給定的Kong節點将隻使用由nameserver提供的少數上遊服務執行個體。在此場景中，上遊執行個體池的加載可能不一緻，因為由于nameserver提供的資訊有限，Kong節點實際上并不知道某些執行個體。為了減少這種情況，可以使用不同的名稱伺服器，使用IP位址而不是名稱，或者確定使用足夠的Kong節點來仍然使用所有上遊服務。

當nameserver傳回3個名稱錯誤時，這是對Kong的有效響應。如果這是意外的，首先驗證查詢的名稱是否正确，然後檢查nameserver配置。

從DNS記錄(A記錄或SRV)中初始選擇IP位址不是随機的。是以，當使用ttl為0的記錄時，nameserver将随機化記錄entries。

當使用環形負載均衡器時，後端服務的添加和删除将由Kong處理，不需要DNS更新。Kong将擔任服務注冊。節點可以通過單個HTTP請求添加/删除，并立即啟動/停止接收流量。

通過​<code>​upstream​</code>​ 和​<code>​target​</code>​ entities配置環形負載均衡器。

target:帶有後端服務所在端口号的IP位址或主機名，例如。“192.168.100.12:80”。每個目标獲得一個額外的權重，以訓示它獲得的相對負載。IP位址可以是IPv4和IPv6格式。

upstream:可以在Route hiost字段中使用的“虛拟主機名”，例如，upstream名為weather.v2的上遊服務将從獲得所有帶參數host=weather.v2.service的請求。

每個上遊都有自己的環形負載均衡器。每個upstream可以有許多target entries，代理到“虛拟主機名”的請求将在目标上進行負載平衡。一個環形負載均衡器有預先定義的槽數，并且根據目标權重，槽被配置設定給upstream的目标。

可以通過管理API上的簡單HTTP請求來添加和删除目标。這個操作相對簡單。更改upstream本身的開銷更大，例如，當槽數發生變化時需要重新建構負載均衡器。

隻有在清理目标曆史記錄時，才會自動重新建構均衡器;除此之外，它隻會在更改的基礎上重新建構。

在負載均衡器中有位置(從1到slots)，它們随機分布在環上，為了在運作時廉價地調用環形負載均衡器，需要随機性。一個簡單的輪詢(位置)就可以在目标上提供一個分布良好的權重輪詢，同時在插入/删除目标時具有廉價的操作。

每個目标使用的插槽的數量應該(至少)在100左右，以確定插槽是正确分布的。如。對于最大期望的8個目标，上遊應該定義至少插槽=800，即使初始設定隻有2個目标。

這裡的權衡是插槽的數量越多，随機分布越好，但是更改(添加/删除目标)的成本就越高

關于添加和操作上行流的詳細資訊可以在​​Admin API reference​​的上遊部分中獲得。

因為​<code>​upstream​</code>​ 維護更改的曆史記錄，是以隻能添加、不能修改或删除目标。要更改目标，隻需為目标添加一個新條目，并更改權重值。最後一個條目将被使用。是以，設定weight=0将禁用目标，進而有效地将其從均衡器中删除。關于添加和操作目标的詳細資訊可以在​​Admin API reference​​的目标部分中找到。

當非活動條目比活動條目多10倍時，将自動清除目标。清理将涉及到重新建構均衡器，是以比僅僅添加目标條目更昂貴。

目标也可以有主機名而不是IP位址。在這種情況下，名稱将被解析，找到的所有條目将單獨添加到環均衡器中，例如，添加api.host.com:123和weight=100。名稱“api.host.com”解析為包含兩個IP位址的A記錄。然後将兩個ip位址都添加為目标，每個ip位址的權值為100，端口為123。注意:權重用于單個條目，而不是整個條目!

如果它解析為SRV記錄，那麼DNS記錄中的端口和權值字段也将被提取，并将否決給定的端口123和權值=100。

均衡器将尊重DNS記錄的ttl設定和請求，并在其到期時更新均衡器。

例外:當DNS記錄ttl=0時，主機名将作為單個目标添加，并具有指定的權重。每當代理請求這個目标時，它将再次查詢名稱伺服器。

預設情況下，環型均衡器将使用權重循環方案。另一種選擇是使用基于哈希的算法。哈希的輸入可以是none、consumer、ip、header或cookie。當設定為none時，将使用權重循環方案，并禁用哈希。

有兩個選項，主伺服器失敗時的主伺服器和回退伺服器(例如，如果主伺服器被設定為使用者，但是沒有經過身份驗證的使用者)

不同的哈希選項:

none:不要使用散列，而是使用權重循環(預設)。

consumer:使用consumer id作為散列輸入。如果沒有可用的consumer id(對于ldap之類的外部身份驗證)，則此選項将回退到憑據id上。

ip:将使用遠端(原始)ip位址作為輸入。在使用此選項時，請檢查确定實際IP​​determining the real IP​​的配置設定。

header:使用指定的header(在hash_on_header或hash_fallback_header字段中)作為散列的輸入。

cookie:使用指定的cookie名稱(在hash_on_cookie字段中)和指定的路徑(在hash_on_cookie_path字段中，預設為“/”)作為哈希的輸入。如果cookie不在請求中，它将由響應設定。是以，如果cookie是主要的散列機制，則hash_fallback設定無效。

雜湊演算法基于“一緻性哈希”(或“ketama原則”)，它確定當均衡器通過更改目标(添加、删除、失敗或更改權重)進行修改時，隻會發生最小數目的哈希損失。這将最大化上遊緩存命中。

有關确切設定的更多資訊，請參見​​Admin API reference​​的上遊部分

環型均衡器被設計成既可以在單個節點上工作，也可以在叢集中工作。對于權重循環算法來說差别不大，但是在使用基于散列的算法時，重要的是所有節點建構完全相同的環平衡器，以確定它們的工作方式完全相同。為此，必須以确定的方式建構均衡器。

不要在均衡器中使用主機名，因為均衡器可能/将緩慢地偏離，因為DNS ttl隻有第二次精度，并且更新取決于實際請求名稱的時間。最重要的是一些nameserver不傳回所有條目的問題，這加劇了這個問題。是以，在Kong叢集中使用散列方法時，隻根據目标實體的IP位址添加它們，而不按名稱添加。

當選擇哈希輸入時，確定輸入有足夠的方差來得到一個分布良好的哈希。散列将使用CRC-32摘要計算。是以，例如，如果您的系統有數千個使用者，但每個平台隻定義了幾個consumer(例如。3 consumers:Web, iOS和Android)然後選擇consumer哈希輸入是不夠的，使用遠端IP位址通過設定哈希為IP将提供更多的輸入方差，是以在哈希輸出更好的分布。然而，如果許多用戶端位于相同的NAT網關之後(例如在呼叫中心)，cookie将提供比ip更好的分布。

Blue-Green Deployments

Using the ring-balancer a ​​blue-green deployment​​ can be easily orchestrated for a Service.切換目标基礎設施隻需要對服務發出更新檔請求，以更改其主機值。

Set up the “Blue” environment, running version 1 of the address service:

将host header設定為address.mydomain.com的請求現在将由Kong代理到兩個已定義的目标;2/3的請求将通路http://192.168.34.15:80/address (weight=100)， 1/3的請求将通路http://192.168.34.16:80/address (weight=50)。

在部署address服務的版本2之前，設定“綠色”環境:

To activate the Blue/Green switch, we now only need to update the Service:

将host header資訊設定為address.mydomain.com的傳入請求現在将由Kong代理到新目标;其中1/2的請求将通路http://192.168.34.17:80/address (weight=100)，另外1/2的請求将通路http://192.168.34.18:80/address (weight=100)。

與往常一樣，通過Kong Admin API進行的更改是動态的，将立即生效。不需要重新加載或重新啟動，也不會删除正在處理的請求。

Canary Releases 金絲雀的版本

Using the ring-balancer, target weights 可以顆粒狀調整，允許平穩、可控的金絲雀釋出​​canary release​​.

Using a very simple 2 target example:

通過重複請求，但每次更改權重，流量将緩慢地路由到另一個目标。例如，設定為10%:

The changes through the Kong Admin API are dynamic and will take effect immediately. No reload or restart is required, and no in progress requests will be dropped.