負(fù)載均衡（Load balancing）是一種計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)，用來在多個(gè)計(jì)算機(jī)（計(jì)算機(jī)集群）、網(wǎng)絡(luò)連接、CPU、磁盤驅(qū)動(dòng)器或其他資源中分配負(fù)載，以達(dá)到最佳化資源使用、最大化吞吐率、最小化響應(yīng)時(shí)間、同時(shí)避免過載的目的。

使用帶有負(fù)載均衡的多個(gè)服務(wù)器組件，取代單一的組件，可以通過冗余提高可靠性。負(fù)載均衡服務(wù)通常是由專用軟體和硬件來完成。

對(duì)于互聯(lián)網(wǎng)服務(wù)，負(fù)載均衡器通常是一個(gè)軟體程序，這個(gè)程序偵聽一個(gè)外部端口，互聯(lián)網(wǎng)用戶可以通過這個(gè)端口來訪問服務(wù)，而作為負(fù)載均衡器的軟體會(huì)將用戶的請(qǐng)求轉(zhuǎn)發(fā)給后臺(tái)內(nèi)網(wǎng)服務(wù)器，內(nèi)網(wǎng)服務(wù)器將請(qǐng)求的響應(yīng)返回給負(fù)載均衡器，負(fù)載均衡器再將響應(yīng)發(fā)送到用戶，這樣就向互聯(lián)網(wǎng)用戶隱藏了內(nèi)網(wǎng)結(jié)構(gòu)，阻止了用戶直接訪問后臺(tái)（內(nèi)網(wǎng)）服務(wù)器，使得服務(wù)器更加安全，可以阻止對(duì)核心網(wǎng)絡(luò)棧和運(yùn)行在其它端口服務(wù)的攻擊。

當(dāng)所有后臺(tái)服務(wù)器出現(xiàn)故障時(shí)，有些負(fù)載均衡器會(huì)提供一些特殊的功能來處理這種情況。例如轉(zhuǎn)發(fā)請(qǐng)求到一個(gè)備用的負(fù)載均衡器、顯示一條關(guān)于服務(wù)中斷的消息等。負(fù)載均衡器使得 IT 團(tuán)隊(duì)可以顯著提高容錯(cuò)能力。它可以自動(dòng)提供大量的容量以處理任何應(yīng)用程序流量的增加或減少。

　　對(duì)于核心 api，需要保證搞可靠性，那么就要對(duì)于該 api 有多個(gè) backend service，即實(shí)際后端對(duì)該 api 有多個(gè)服務(wù)的節(jié)點(diǎn)；那么最好在 api-gateway 即 kong 這一層實(shí)現(xiàn)負(fù)載均衡。
　　Kong為多個(gè)后端服務(wù)提供了多種負(fù)載平衡請(qǐng)求方式：一種基于DNS的簡單方法，以及一種更加動(dòng)態(tài)的環(huán)平衡器，該方法還允許在不需要DNS服務(wù)器的情況下進(jìn)行服務(wù)注冊(cè)。

基于DNS的負(fù)載均衡

　　當(dāng)使用基于DNS的負(fù)載均衡時(shí)，后端服務(wù)的注冊(cè)是在Kong以外完成的，而Kong僅接收來自DNS服務(wù)器的更新。 如果名稱解析為多個(gè)IP地址，并且主機(jī)名未解析為上游名稱或名稱，則每個(gè)使用包含hostname（而不是IP地址）的host定義的service都將自動(dòng)使用基于DNS的負(fù)載平衡你的DNS hosts文件。 DNS記錄ttl設(shè)置（生存時(shí)間）決定信息刷新的頻率。當(dāng)使用0的ttl時(shí)，每個(gè)請(qǐng)求都將使用自己的DNS查詢來解析。很明顯，這會(huì)導(dǎo)致性能下降，但更新/更改的延遲將非常低。

A記錄

　　A記錄包含一個(gè)或多個(gè)IP地址。因此，當(dāng)主機(jī)名解析為A記錄時(shí)，每個(gè)后端服務(wù)都必須具有自己的IP地址。 由于沒有weight信息，因此所有條目在負(fù)載平衡器中將被視為具有相同的權(quán)重，并且平衡器(balancer)將進(jìn)行簡單的循環(huán)。

SRV記錄

　　SRV記錄包含所有IP地址的權(quán)重(weight)和端口(port)信息。后端服務(wù)可以通過IP地址和端口號(hào)的唯一組合來識(shí)別。因此，單個(gè)IP地址可以在不同的端口上托管同一服務(wù)的多個(gè)實(shí)例。 由于weight信息可用，每個(gè)條目將在負(fù)載均衡器中獲得自己的權(quán)重，并執(zhí)行加權(quán)循環(huán)。 同樣，任何給定的端口信息都將被來自DNS服務(wù)器的端口信息覆蓋。如果服務(wù)具有host = myhost.com和port = 123的屬性，并且myhost.com解析為具有127.0.0.1:456的SRV記錄，則該請(qǐng)求將被代理到http://127.0.0.1:456/somepath，因?yàn)?23端口將被456覆蓋。

DNS優(yōu)先級(jí)

DNS解析器將按順序解析以下記錄類型：

• 上次解析的最后一次成功類型（LAST）
• SRV記錄
• A記錄
• CNAME記錄

該順序可通過dns_order配置屬性進(jìn)行配置。
解析不同記錄類型的順序。 LAST類型表示上次成功查找的類型（用于指定的名稱）。格式是一個(gè)（不區(qū)分大小寫）逗號(hào)分隔的列表。 默認(rèn)值：LAST，SRV，A，CNAME

DNS警告（DNS caveats）

• 無論何時(shí)刷新DNS記錄，都會(huì)生成一個(gè)列表以正確處理權(quán)重。盡量保持權(quán)重為對(duì)方的倍數(shù)以保持算法的高效性，例如，17和31的2個(gè)權(quán)重將導(dǎo)致具有527個(gè)項(xiàng)目的結(jié)構(gòu)，而權(quán)重16和32（或其最小的相對(duì)對(duì)應(yīng)項(xiàng)1和2）將導(dǎo)致在只有3個(gè)條目的結(jié)構(gòu)中，尤其是具有非常小（甚至0）ttl值的結(jié)構(gòu)。
• 在這些情況下，某些域名服務(wù)器不會(huì)返回所有條目（由于UDP數(shù)據(jù)包的大小）（例如Consul最多返回3個(gè)），給定的Kong節(jié)點(diǎn)將只使用由名稱服務(wù)器提供的少數(shù)上游服務(wù)實(shí)例。在這種情況下，由于名稱服務(wù)器提供的信息有限，Kong節(jié)點(diǎn)實(shí)際上不了解某些實(shí)例，因此上游實(shí)例池可能會(huì)不一致地加載。為了緩解這種情況，可以使用不同的名稱服務(wù)器，使用IP地址而不是名稱，或者確保使用足夠的Kong節(jié)點(diǎn)來繼續(xù)使用所有上游服務(wù)。
• 當(dāng)名稱服務(wù)器返回3 name error時(shí)，那么對(duì)于Kong來說這是一個(gè)有效的響應(yīng)。如果這是意外，請(qǐng)首先驗(yàn)證是否正在查詢正確的name，然后檢查您的nameserver配置。
• 從DNS記錄（A或SRV）中初始選擇IP地址不是隨機(jī)的。因此，當(dāng)使用ttl為0的記錄時(shí)，nameserver應(yīng)該隨機(jī)記錄條目。

環(huán)平衡器(ring-balancer)

　　當(dāng)使用環(huán)平衡器時(shí)，添加和刪除后端服務(wù)將由Kong處理，并且不需要DNS更新。kong將擔(dān)任服務(wù)登記。節(jié)點(diǎn)可以通過一個(gè)HTTP請(qǐng)求added/deleted，并立即start/stop接收流量。 配置環(huán)平衡器是通過上游和目標(biāo)實(shí)體完成的。

　　target：具有后端服務(wù)駐留端口號(hào)的IP地址或主機(jī)名，例如。 “192.168.100.12:80”。每個(gè)target都會(huì)得到一個(gè)額外的權(quán)重來指示它獲得的相對(duì)負(fù)載。 IP地址可以是IPv4和IPv6兩種格式。

　　upstream：可以在路由主機(jī)字段中使用的'virtual hostname'，例如，上游命名的weather.v2.service將從具有host = weather.v2.service的服務(wù)獲得所有請(qǐng)求

上游（upstream）

　　每個(gè)upstream都有自己的環(huán)形平衡器。每個(gè)upstream可以有許多target條目附加到它，代理到'virtual hostname'的請(qǐng)求將在target上進(jìn)行負(fù)載平衡。環(huán)形平衡器具有預(yù)定義(pre-defined)數(shù)量的槽(number of slots)，并且基于目標(biāo)權(quán)重，槽(slots)被分配給上游的目標(biāo)。

　　添加和刪??除目標(biāo)可以通過Admin API上的簡單HTTP請(qǐng)求完成。這個(gè)操作相對(duì)便宜。改變上游本身更昂貴，因?yàn)槔绠?dāng)槽的數(shù)量改變時(shí)平衡器將需要重建。

　　自動(dòng)重建平衡器的唯一情況是清理目標(biāo)歷史記錄時(shí);除此之外，它只會(huì)在改變時(shí)重建。

在平衡器內(nèi)部有（從1到slots）的位置，它們隨機(jī)分布(?randomly distributed)在環(huán)上。在運(yùn)行時(shí)需要隨機(jī)性來調(diào)用環(huán)平衡器。輪子上的簡單循環(huán)（位置）將為目標(biāo)提供良好的分布式加權(quán)循環(huán)，同時(shí)在插入/刪除目標(biāo)時(shí)也具有廉價(jià)的操作。

每個(gè)目標(biāo)使用的插槽數(shù)量（至少）應(yīng)該在100個(gè)左右，以確保插槽正確分布。例如。對(duì)于預(yù)期最多8個(gè)目標(biāo)，即使初始設(shè)置僅包含2個(gè)目標(biāo)，上游應(yīng)至少定義為slot = 800。

這里的折衷是，插槽數(shù)量越多，隨機(jī)分布越好，但更改更為昂貴（添加/刪除目標(biāo)）

有關(guān)添加和操作上游的詳細(xì)信息，請(qǐng)參閱Admin API

目標(biāo)（target）

　　由于上游保留了更改歷史記錄，目標(biāo)只能添加，不能修改或刪除。要更改目標(biāo)，只需為目標(biāo)添加一個(gè)新條目，然后更改重量值。最后一個(gè)條目是將要使用的條目。因?yàn)檫@樣的設(shè)置權(quán)重= 0將禁用目標(biāo)，有效地從平衡器中刪除它。有關(guān)添加和操作目標(biāo)的詳細(xì)信息，請(qǐng)參閱Admin API參考的目標(biāo)部分。

　　當(dāng)活動(dòng)條目比活動(dòng)條目多10倍時(shí)，目標(biāo)將自動(dòng)清除。清潔將涉及重建平衡器，因此比添加目標(biāo)條目更昂貴。 目標(biāo)也可以具有主機(jī)名而不是IP地址，在這種情況下，名稱將被解析，所有找到的條目將被單獨(dú)添加到環(huán)形平衡器中，例如，添加api.host.com:123且權(quán)重= 100。名稱'api.host.com'解析為具有2個(gè)IP地址的A記錄。然后這兩個(gè)IP地址將被添加為目標(biāo)，每個(gè)獲得weight = 100和端口123.注意：權(quán)重用于單個(gè)條目，而不是整個(gè)！ 它是否會(huì)解析為SRV記錄，然后DNS記錄中的端口和權(quán)重字段將被拾取，并且會(huì)否定給定的端口123和權(quán)重= 100。 平衡器將遵守DNS記錄的ttl設(shè)置和重新查詢，并在平衡器到期時(shí)更新。 例外情況：當(dāng)DNS記錄的ttl = 0時(shí)，主機(jī)名將被添加為具有指定權(quán)重的單個(gè)目標(biāo)。在對(duì)該目標(biāo)的每個(gè)代理請(qǐng)求時(shí)，它將再次查詢名稱服務(wù)器。

平衡算法

　　默認(rèn)情況下，環(huán)平衡器將使用加權(quán)循環(huán)方案。另一種方法是使用基于散列的算法。散列的輸入可以是none，consumer，ip或header。如果設(shè)置為none，則將使用加權(quán)循環(huán)方案，并且散列將被禁用。

有兩種選擇，一種primary 和 一種回退(fallback)，以防primary失敗（例如，如果primary設(shè)置為consumer，但沒有consumer通過驗(yàn)證）

不同的散列選項(xiàng)：

• none：不要使用散列，而是使用weighted-round-robin（默認(rèn)）。
• consumer：使用消費(fèi)者ID作為散列輸入。如果沒有消費(fèi)者ID可用（如果使用外部身份驗(yàn)證，如ldap），此選項(xiàng)將回退到憑證ID。
• ip：遠(yuǎn)程（始發(fā)）IP地址將用作輸入。在使用此設(shè)置時(shí)，查看確定真實(shí)IP的配置設(shè)置。
• header：使用指定的標(biāo)題（在hash_on_header或hash_fallback_header字段中）作為散列的輸入。

哈希算法基于'一致哈希'（或'ketama原理'），它確保當(dāng)平衡器通過改變目標(biāo)（添加，移除，失敗或改變權(quán)重）而被修改時(shí)，只有最小數(shù)量的哈希損失發(fā)生。這將最大化上游緩存命中。

有關(guān)確切設(shè)置的更多信息，請(qǐng)參閱Admin API參考的上游upstream部分。

平衡警告（Balancing caveats）

　　環(huán)平衡器設(shè)計(jì)為既可以在單個(gè)節(jié)點(diǎn)上工作，也可以在群集中工作。對(duì)于加權(quán)循環(huán)算法沒有太大的區(qū)別，但是當(dāng)使用基于散列的算法時(shí)，重要的是所有節(jié)點(diǎn)構(gòu)建完全相同的環(huán)平衡器以確保它們都工作一致。要做到這一點(diǎn)，平衡器必須以確定性的方式構(gòu)建。

　　不要在平衡器中使用主機(jī)名稱，因?yàn)槠胶馄骺赡軙?huì)/會(huì)慢慢發(fā)生分歧，因?yàn)镈NS ttl只有第二精度，更新取決于實(shí)際請(qǐng)求名稱的時(shí)間。最重要的是一些域名服務(wù)器沒有返回所有條目的問題，這加劇了這個(gè)問題。因此，在Kong群集中使用哈希方法時(shí)，只能通過IP地址添加目標(biāo)實(shí)體，而不能通過名稱添加target實(shí)體。

　　當(dāng)選擇你的散列輸入時(shí)，確保輸入具有足夠的方差以得到散布良好的散列。哈希將使用CRC-32摘要進(jìn)行計(jì)算。例如，如果您的系統(tǒng)有成千上萬的用戶，但只有少數(shù)用戶（每個(gè)平臺(tái)定義了3個(gè)用戶：Web，iOS和Android），那么挑選consumer散列輸入是不夠的，通過設(shè)置使用遠(yuǎn)程IP地址對(duì)于ip的哈希將提供更多的輸入差異，從而更好地分配哈希輸出

藍(lán)綠部署（Blue-Green Deployments）

　　使用環(huán)形平衡器，可以輕松地為一項(xiàng)服務(wù)策劃一個(gè)藍(lán)綠色部署。切換目標(biāo)基礎(chǔ)架構(gòu)只需要服務(wù)上的PATCH請(qǐng)求，即可更改其主機(jī)值。

設(shè)置“blue”環(huán)境，運(yùn)行version 1 of the address service：

# create an upstream $ curl -X POST http://kong:8001/upstreams \--data "name=address.v1.service"# add two targets to the upstream $ curl -X POST http://kong:8001/upstreams/address.v1.service/targets \--data "target=192.168.34.15:80"--data "weight=100" $ curl -X POST http://kong:8001/upstreams/address.v1.service/targets \--data "target=192.168.34.16:80"--data "weight=50"# create a Service targeting the Blue upstream $ curl -X POST http://kong:8001/services/ \--data "name=address-service" \--data "host=address.v1.service" \--data "path=/address"# finally, add a Route as an entry-point into the Service $ curl -X POST http://kong:8001/services/address-service/routes/ \--data "hosts[]=address.mydomain.com"

在部署version 2 of the address service之前，請(qǐng)?jiān)O(shè)置“green”環(huán)境：

# create a new Green upstream for address service v2 $ curl -X POST http://kong:8001/upstreams \--data "name=address.v2.service"# add targets to the upstream $ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \--data "target=192.168.34.17:80"--data "weight=100" $ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \--data "target=192.168.34.18:80"--data "weight=100"

要激活blue/green開關(guān)，現(xiàn)在只需要更新服務(wù):

# Switch the Service from Blue to Green upstream, v1 -> v2 $ curl -X PATCH http://kong:8001/services/address-service \--data "host=address.v2.service"

主機(jī)頭設(shè)置為address.mydomain.com的傳入請(qǐng)求現(xiàn)在由Kong代理到新目標(biāo); 1/2的請(qǐng)求將轉(zhuǎn)到http://192.168.34.17:80/address（權(quán)重= 100），另一半將轉(zhuǎn)到http://192.168.34.18:80/address（權(quán)重= 100 ）。

與往常一樣，通過Kong Admin API進(jìn)行的更改是動(dòng)態(tài)的，并且會(huì)立即生效。不需要重新加載或重新啟動(dòng)，并且沒有進(jìn)行中的請(qǐng)求將被丟棄。?

金絲雀版本（Canary Releases）

　　使用環(huán)形平衡器，可以精確調(diào)整目標(biāo)重量，從而實(shí)現(xiàn)平穩(wěn).。

使用一個(gè)非常簡單的2 target示例：

# first target at 1000 $ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \--data "target=192.168.34.17:80"--data "weight=1000"# second target at 0 $ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \--data "target=192.168.34.18:80"--data "weight=0"

通過重復(fù)請(qǐng)求，但每次改變權(quán)重，流量將緩慢路由到另一個(gè)target。例如，將其設(shè)置為10％：

# first target at 900 $ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \--data "target=192.168.34.17:80"--data "weight=900"# second target at 100 $ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \--data "target=192.168.34.18:80"--data "weight=100"

通過Kong Admin API進(jìn)行的更改是動(dòng)態(tài)的，并會(huì)立即生效。不需要重新加載或重新啟動(dòng)，并且沒有進(jìn)行中的請(qǐng)求將被丟棄。

KONG負(fù)載均衡實(shí)現(xiàn)

　　實(shí)際在操作過程中，采用的是 kong 的 Ring-balancer 做負(fù)載均衡。

　　使用 Kong?Community?Edition（社區(qū)版 v0.13）來搭建一個(gè)負(fù)載均衡器，由于 Kong 是基于 Openresty 的，而 Openresty 又是 Nginx 的二次封裝，所有很多配置項(xiàng)和 Nginx 類似。

來看一個(gè)較為典型的 Nginx 負(fù)載均衡配置：

upstream hello { server localhost:3000 weight=100; server localhost:3001 weight=50; } server { listen 80; location /hello { proxy_pass http://hello; } }

　　nginx 監(jiān)聽來自本地 80 端口的請(qǐng)求，如果路徑與 /hello 匹配，便將請(qǐng)求原封不動(dòng)的轉(zhuǎn)發(fā)到名稱為 hello 的upstream，而該 upstream 我們配置了一個(gè)負(fù)載均衡器，會(huì)路由到本地的 3000 端口和 3001 端口。

接下來便可以針對(duì) Kong 進(jìn)行負(fù)載均衡的配置了。

配置 upstream 和 target

創(chuàng)建一個(gè)名稱 hello 的 upstream

curl -X POST http://localhost:8001/upstreams --data "name=hello"

為 hello 添加兩個(gè)負(fù)載均衡節(jié)點(diǎn)

curl -X POST http://localhost:8001/upstreams/hello/targets --data "target=localhost:3000" --data "weight=100" curl -X POST http://localhost:8001/upstreams/hello/targets --data "target=localhost:3001" --data "weight=50"

如上的配置對(duì)應(yīng)了 Nginx 的配置：

upstream hello { server localhost:3000 weight=100; server localhost:3001 weight=50; }

配置 service 和 route

　　使用 Kong v0.13之前版本的用戶可能會(huì)接觸過 api 這個(gè)概念，但是在 Kong v0.13.0 中，已經(jīng)被廢除了，取而代之的是 service 和 route 的配置。

配置一個(gè) service

curl -X POST http://localhost:8001/services --data "name=hello" --data "host=hello"

host 的值便對(duì)應(yīng)了 upstream 的名稱，配置成功后會(huì)返回生成的 service 的 id，返回結(jié)果：8695cc65-16c1-43b1-95a1-5d30d0a50409。

為上面的 service 配置路由信息

curl -X POST http://localhost:8001/routes --data "paths[]=/hello" --data "service.id=8695cc65-16c1-43b1-95a1-5d30d0a50409"

請(qǐng)求路徑包含 /hello 的請(qǐng)求都會(huì)被轉(zhuǎn)移到對(duì)應(yīng)的 service 進(jìn)行處理。

?

如上的配置便對(duì)應(yīng)了Nginx的配置：

location /hello { proxy_pass http://hello; }

測(cè)試 Kong 的負(fù)載均衡

curl http://localhost:8000/hello/hi

因?yàn)閺?fù)雜均衡的原因，需要多測(cè)試幾次，多次 curl 之后結(jié)果如下：

3000 3000 3000 3000 3000 3000 3001 3001 3001 3000 3001

?

reference：

https://getkong.org/docs/0.13.x/loadbalancing/

https://getkong.org/docs/0.13.x/configuration/

?

作者：zhoujie 出處：http://www.cnblogs.com/zhoujie/ 本文版權(quán)歸作者和博客園共有，歡迎轉(zhuǎn)載，但未經(jīng)作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，不然我擔(dān)心博客園找你算賬 如果您覺得本文對(duì)你有幫助，請(qǐng)豎起您的大拇指右下角點(diǎn)推薦，也可以關(guān)注我

總結(jié)

以上是生活随笔為你收集整理的apigateway-kong(四)负载均衡理论及实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。