KONG為請求多個后端服務提供了多種負載均衡方案：一種是簡單的基於DNS，另一種是更加動態的環形均衡器，他在不需要DNS服務器的情況下也允許服務注冊。
一、基於DNS的負載均衡
當使用基於DNS的負載平衡時，后端服務的注冊是在Kong之外完成，而Kong只接收來自DNS服務器的更新。如果請求的API被解析為多個IP地址，則已使用包含主機名（而不是IP地址）的upstream_url定義的每個API將自動使用基於DNS的負載平衡，前提是主機名未被解析為upstream名稱或你的localhosts文件中的名稱。DNS記錄ttl設置（生存時間）確定刷新信息的頻率。當設置ttl為0時，每個請求將使用自己的dns查詢進行解析。顯然這會帶來性能損失，但更新/更改的延遲將非常低。
1. A記錄
A記錄包含一個或多個IP地址。因此，當主機名解析為A記錄時，每個后端服務都必須有自己的IP地址。因為沒有 weight 信息，所有條目在負載平衡器中將被視為同樣的權重，平衡器將進行直線循環。來自DNS記錄的IP地址的初始選擇是隨機的。這是為了確保即使當ttl為0時，負載也正確分配。
2. SRV記錄
SRV記錄包含所有IP地址的權重和端口信息。可以通過唯一的IP端口號的組合來標識后端服務。因此，單個IP地址可以托管不同端口上相同服務的多個實例。因為權重信息可用，每個條目將在負載平衡器中獲得自己的權重，並且它將執行加權循環。
類似地，任何給定的端口信息將被來自DNS服務器的端口信息覆蓋。如果一個API的 upstream_url=http://myhost.com:1234/path 並且 myhost.com 被解析為 SRV 記錄中的 127.0.0.1:5678，此時的API將會被代理到 http://127.0.0.1:5678/path，之前的 1234 端口會被重寫為 5678 端口。IP地址+端口組合在初始時是隨機選擇的，這是為了確保服務能被正確分配，即使ttl設置為0。
tip：每當刷新DNS記錄時，都會生成列表以正確處理加權。建議將權重保持為彼此的倍數以保證系統的性能。
3. DNS的優先級
DNS解析器按順序開始解析以下記錄類型：
> 1. 最后一個成功的類型優先解析；
> 2. SRV記錄
> 3. A記錄
> 4. CNAME記錄
所以，如果你使用的主機名稱中同時含有SRV記錄和A記錄時，將僅解析SRV實例。如果你想使用A記錄，那么你必須得把SRV記錄從DNS中刪除。如果你只有A記錄，則SRV記錄查詢失敗，然后自動指向到A記錄，並查詢A記錄是否存在，依次類推。
二、環形均衡器
使用環形平衡器時，后台服務的添加和刪除將由Kong處理，不需要進行DNS更新。KONG將扮演服務注冊的角色。可以通過單個HTTP請求添加/刪除節點，並可立即啟動/停止接收請求流量。
可以通過配置 upstream 和 target 屬性來配置環形均衡器。
· upstream： 在API中把一個虛擬主機名稱配置到upstream屬性里。例如：一個weather.service的主機可以接收所有類似於http://weather.service/path/xxx/...的請求。
· target： 后台服務所在的IP和端口號的組合。例如：192.168.11.48:8080。每一個target都附加有一個weight屬性來指示獲得的相對負載。
1. upstream上游服務
每一個上游服務都有他自己的環形均衡器。每一個upstream都可以有多個target屬性，代理到虛擬主機名的請求會被均衡到每個target上。環形平衡器具有預定義的槽數，基於target的權重，每個target會分配到一定數量的槽。進來的請求將會以加權循環方式進行代理。添加或刪除一個target可以用管理員身份，通過一個簡單的HTTP請求來完成。這種操作比較簡單省事，然而相對的，如果要改變上游服務本身，則相當繁瑣，譬如要重建負載，重新分配槽數等。
平衡器自動重建的唯一情況是清除target的歷史記錄；除此之外，它只會在更改時重建。
在平衡器中，環上有位置（從1到插槽總數量），每個都有一個“1”對齊的“插槽”。因此，還存在時隙數量的時隙，但它們隨機分布在環位置上。這個隨機性可以通過使用orderlist來設置，但是我們強烈反對這樣做。在運行時廉價的調用環形均衡器時才會使用隨機分配。輪到一個簡單的循環（位置）將提供一個分布均勻的加權輪回目標，同時在插入/刪除目標時也有廉價的操作。
2. 目標服務
四、Canary發布