學習目標

第1章：初識負載均衡

負載均衡：建立在現(xiàn)有網(wǎng)絡結(jié)構(gòu)之上，它提供了一種廉價有效透明的方法擴展網(wǎng)絡設備和服務器的帶寬、增加吞吐量、加強網(wǎng)絡數(shù)據(jù)處理能力、提高網(wǎng)絡的靈活性和可用性。

負載均衡說白了其實就是伴隨著微服務架構(gòu)的誕生的產(chǎn)物；過去的單體架構(gòu)，前端頁面發(fā)起請求，然后后臺接收請求直接處理，這個時候不存在什么負載均衡；但是隨著單體架構(gòu)向微服務架構(gòu)的演變，每個后臺服務可能會部署在多臺服務器上面，這個時候頁面請求進來，到底該由哪臺服務器進行處理呢？所以得有一個選擇，而這個過程就是負載均衡；同時選擇的方案有很多種，例如隨機挑選一臺或者一臺一臺輪著來，這就是負載均衡算法。

也可以通過例子來幫助自己記憶，就好比古代皇帝翻牌子，最開始皇帝只有一個妃子，那不存在翻牌子這回事，再怎么翻也只能是這一個妃子侍寢。但是隨著妃子多了，就得有選擇了，不能同時讓所有妃子一起侍寢。

1.1 實現(xiàn)方式

1.1.1 HTTP重定向負載均衡

工作原理圖如下：

HTTP重定向服務器是一臺普通的應用服務器，其唯一個功能就是根據(jù)用戶的HTTP請求計算出一臺真實的服務器地址，并將該服務器地址寫入HTTP重定向響應中返回給用戶瀏覽器。用戶瀏覽器在獲取到響應之后，根據(jù)返回的信息，重新發(fā)送一個請求到真實的服務器上。DNS服務器解析到IP地址為192.168.8.74，即HTTP重定向服務器的IP地址。重定向服務器計根據(jù)某種負載均衡算法算出真實的服務器地址為192.168.8.77并返回給用戶瀏覽器，用戶瀏覽器得到返回后重新對192.168.8.77發(fā)起了請求，最后完成訪問。

這種負載均衡方案的優(yōu)點是比較簡單，缺點是瀏覽器需要兩次請求服務器才能完成一次訪問，性能較差；同時，重定向服務器本身的處理能力有可能成為瓶頸，整個集群的伸縮性規(guī)模有限；因此實踐中很少使用這種負載均衡方案來部署。

1.1.2 DNS負載均衡

DNS（Domain Name System）是因特網(wǎng)的一項服務，它作為域名和IP地址相互映射的一個分布式數(shù)據(jù)庫，能夠使人更方便的訪問互聯(lián)網(wǎng)。人們在通過瀏覽器訪問網(wǎng)站時只需要記住網(wǎng)站的域名即可，而不需要記住那些不太容易理解的IP地址。在DNS系統(tǒng)中有一個比較重要的的資源類型叫做主機記錄也稱為A記錄，A記錄是用于名稱解析的重要記錄，它將特定的主機名映射到對應主機的IP地址上。如果你有一個自己的域名，那么要想別人能訪問到你的網(wǎng)站，你需要到特定的DNS解析服務商的服務器上填寫A記錄，過一段時間后，別人就能通過你的域名訪問你的網(wǎng)站了。DNS除了能解析域名之外還具有負載均衡的功能，下面是利用DNS工作原理處理負載均衡的工作原理圖：

由上圖可以看出，在DNS服務器中應該配置了多個A記錄，如：www.woshuaiqi.com IN A 192.168.8.75;www.woshuaiqi.com IN A 192.168.8.76;www.woshuaiqi.com IN A 192.168.8.77;

因此，每次域名解析請求都會根據(jù)對應的負載均衡算法計算出一個不同的IP地址并返回，這樣A記錄中配置多個服務器就可以構(gòu)成一個集群，并可以實現(xiàn)負載均衡。上圖中，用戶請求www.woshuaiqi.com，DNS根據(jù)A記錄和負載均衡算法計算得到一個IP地址192.168.8.77，并返回給瀏覽器，瀏覽器根據(jù)該IP地址，訪問真實的物理服務器192.168.8.77。所有這些操作對用戶來說都是透明的，用戶可能只知道www.woshuaiqi.com這個域名。

DNS域名解析負載均衡有如下優(yōu)點：

同時，DNS域名解析也存在如下缺點：

1.1.3 反向代理負載均衡

請求過程：

用戶發(fā)來的請求都首先要經(jīng)過反向代理服務器，服務器根據(jù)用戶的請求要么直接將結(jié)果返回給用戶，要么將請求交給后端服務器處理，再返回給用戶。

反向代理負載均衡

優(yōu)點：

• 隱藏后端服務器。與HTTP重定向相比，反向代理能夠隱藏后端服務器，所有瀏覽器都不會與后端服務器直接交互，從而能夠確保調(diào)度者的控制權(quán)，提升集群的整體性能。
• 故障轉(zhuǎn)移。與DNS負載均衡相比，反向代理能夠更快速地移除故障結(jié)點。當監(jiān)控程序發(fā)現(xiàn)某一后端服務器出現(xiàn)故障時，能夠及時通知反向代理服務器，并立即將其刪除。
• 合理分配任務 。HTTP重定向和DNS負載均衡都無法實現(xiàn)真正意義上的負載均衡，也就是調(diào)度服務器無法根據(jù)后端服務器的實際負載情況分配任務。但反向代理服務器支持手動設定每臺后端服務器的權(quán)重。我們可以根據(jù)服務器的配置設置不同的權(quán)重，權(quán)重的不同會導致被調(diào)度者選中的概率的不同。

缺點：

• 調(diào)度者壓力過大 。由于所有的請求都先由反向代理服務器處理，那么當請求量超過調(diào)度服務器的最大負載時，調(diào)度服務器的吞吐率降低會直接降低集群的整體性能。
• 制約擴展。當后端服務器也無法滿足巨大的吞吐量時，就需要增加后端服務器的數(shù)量，可沒辦法無限量地增加，因為會受到調(diào)度服務器的最大吞吐量的制約。

1.2 常見算法

1.2.1 輪詢

Round Robin

輪詢算法按照順序?qū)⑿碌恼埱蠓峙浣o下一個服務器，最終實現(xiàn)平分請求。

1.優(yōu)點：

實現(xiàn)簡單，無需記錄各種服務的狀態(tài)，是一種無狀態(tài)的負載均衡策略。

實現(xiàn)絕對公平

2.缺點：當各個服務器性能不一致的情況，無法根據(jù)服務器性能去分配，無法合理利用服務器資源。

代碼實現(xiàn)

public class RoundRobinDemo { @Data public static class Server { private int serverId; private String name; private String ip; private int port; private int weight; public Server(int serverId, String name, String ip, int port) { this.serverId = serverId; this.name = name; this.ip = ip; this.port = port; } public Server(int serverId, String name, String ip, int port, int weight) { this.serverId = serverId; this.name = name; this.ip = ip; this.port = port; this.weight = weight; } @Override public String toString() { return “serverId=” + serverId + “, name='” + name + ”’ + “, ip='” + ip + ”’ + “, port=” + port + “, weight=” + weight; } } private static AtomicInteger NEXT_SERVER_COUNTER = new AtomicInteger(0); //輪詢算法的具體實現(xiàn) private static int select(int modulo) { for (; ; ) { int current = NEXT_SERVER_COUNTER.get(); int next = (current + 1) % modulo; boolean compareAndSet = NEXT_SERVER_COUNTER.compareAndSet(current, next); if (compareAndSet) { return next; } } } public static Server selectServer(List serverList) { return serverList.get(select(serverList.size())); } public static void main(String[] args) { List serverList = new ArrayList(); serverList.add(new Server(1, “服務器1″,”192.168.8.74”,8080)); serverList.add(new Server(2, “服務器2″,”192.168.8.75”,8080)); serverList.add(new Server(3, “服務器3″,”192.168.8.76”,8080)); for (int i = 0; i < 10; i++) { Server selectedServer = selectServer(serverList); System.out.format("第%d次請求，選擇服務器%s", i + 1, selectedServer.toString()); } }}

1.2.2 加權(quán)輪詢

WeightedRound-Robin

由于不同的服務器配置不同，因此它們處理請求的能力也不同，給配置高的服務器配置相對較高的權(quán)重，讓其處理更多的請求，給配置較低的機器配置較低的權(quán)重減輕期負載壓力。加權(quán)輪詢可以較好地解決這個問題。

1.思路

根據(jù)權(quán)重的大小讓其獲得相應被輪詢到的機會。

可以根據(jù)權(quán)重我們在內(nèi)存中創(chuàng)建一個這樣的數(shù)組{s1,s2,s2,s3,s3,s3}，然后再按照輪詢的方式選擇相應的服務器。

2.缺點：請求被分配到三臺服務器上機會不夠平滑。前3次請求都不會落在server3上。

Nginx實現(xiàn)了一種平滑的加權(quán)輪詢算法，可以將請求平滑（均勻）的分配到各個節(jié)點上。

代碼實現(xiàn)

public class WeightRoundRobin { @Data public static class Server { private int serverId; private String name; private String ip; private int port; private int weight; private int currentWeight; public Server(int serverId, String name, String ip, int port) { this.serverId = serverId; this.name = name; this.ip = ip; this.port = port; } public Server(int serverId, String name, String ip, int port, int weight) { this.serverId = serverId; this.name = name; this.ip = ip; this.port = port; this.weight = weight; } public void selected(int total) { this.currentWeight -= total; } public void incrCurrentWeight() { this.currentWeight += weight; } @Override public String toString() { return “serverId=” + serverId + “, name='” + name + ”’ + “, ip='” + ip + ”’ + “, port=” + port + “, weight=” + weight + “, currentWeight=” + currentWeight; } } //加權(quán)輪詢的核心邏輯 //每次選擇權(quán)重最大的那個，被選擇之后，將當前權(quán)重減去總權(quán)重，（算法怎么理解呢： // 理解成排隊去領獎，每次領完獎就排到隊伍的最后繼續(xù)排，而排隊的總?cè)藬?shù)是總權(quán)重， // 全重是幾表示有多少個你的克隆） public static Server selectServer(List serverList) { int total = 0; Server selectedServer = null; int maxWeight = 0; for (Server server : serverList) { total += server.getWeight(); server.incrCurrentWeight(); //選取當前權(quán)重最大的一個服務器 if (selectedServer == null || maxWeight < server.getCurrentWeight()) { selectedServer = server; maxWeight = server.getCurrentWeight(); } } if (selectedServer == null) { Random random = new Random(); int next = random.nextInt(serverList.size()); return serverList.get(next); } selectedServer.selected(total); return selectedServer; } public static void main(String[] args) { List serverList = new ArrayList(); serverList.add(new Server(1, "服務器1", "192.168.8.74", 8080, 1)); serverList.add(new Server(2, "服務器2", "192.168.8.75", 8080, 3)); serverList.add(new Server(3, "服務器3", "192.168.8.76", 8080, 10)); for (int i = 0; i < 10; i++) { Server server = selectServer(serverList); System.out.format("第%d次請求，選擇服務器%s", i + 1, server.toString()); } }}

1.2.3 隨機

Random

思路：利用隨機數(shù)從所有服務器中隨機選取一臺，可以用服務器數(shù)組下標獲取。

優(yōu)點：使用簡單；

缺點：不適合機器配置不同的場景

代碼實現(xiàn)

public class RandomLoadBalanceDemo { @Data public static class Server { private int serverId; private String name; private String ip; private int port; private int weight; public Server(int serverId, String name, String ip, int port) { this.serverId = serverId; this.name = name; this.ip = ip; this.port = port; } public Server(int serverId, String name, String ip, int port, int weight) { this.serverId = serverId; this.name = name; this.ip = ip; this.port = port; this.weight = weight; } @Override public String toString() { return “serverId=” + serverId + “, name='” + name + ”’ + “, ip='” + ip + ”’ + “, port=” + port + “, weight=” + weight; } } //輪詢算法的具體實現(xiàn) public static Server selectServer(List serverList) { Random selector = new Random(); int next = selector.nextInt(serverList.size()); return serverList.get(next); } public static void main(String[] args) { List serverList = new ArrayList(); serverList.add(new Server(1, “服務器1″,”192.168.8.74”,8080)); serverList.add(new Server(2, “服務器2″,”192.168.8.75”,8080)); serverList.add(new Server(3, “服務器3″,”192.168.8.76”,8080)); for (int i = 0; i < 10; i++) { Server selectedServer = selectServer(serverList); System.out.format("第%d次請求，選擇服務器%s", i + 1, selectedServer.toString()); } }}

1.2.4 加權(quán)隨機

Weight Random

思路：這里我們是利用區(qū)間的思想，通過一個小于在此區(qū)間范圍內(nèi)的一個隨機數(shù)，選中對應的區(qū)間（服務器），區(qū)間越大被選中的概率就越大。

已知：

s1：[0,1] s2：(1,3] s3 （3,6]

代碼實現(xiàn)

public class WeightRandomDemo { @Data public static class Server { private int serverId; private String name; private String ip; private int port; private int weight; public Server(int serverId, String name, String ip, int port) { this.serverId = serverId; this.name = name; this.ip = ip; this.port = port; } public Server(int serverId, String name, String ip, int port, int weight) { this.serverId = serverId; this.name = name; this.ip = ip; this.port = port; this.weight = weight; } @Override public String toString() { return “serverId=” + serverId + “, name='” + name + ”’ + “, ip='” + ip + ”’ + “, port=” + port + “, weight=” + weight; } } //算法的具體實現(xiàn) public static Server selectServer(List serverList) { int sumWeight = 0; for (Server server : serverList) { sumWeight += server.getWeight(); } Random serverSelector = new Random(); int nextServerRange = serverSelector.nextInt(sumWeight); int sum = 0; Server selectedServer = null; for (Server server : serverList) { if (nextServerRange >= sum && nextServerRange < server.getWeight() + sum) { selectedServer = server; } sum += server.getWeight(); } return selectedServer; } public static void main(String[] args) { List serverList = new ArrayList(); serverList.add(new Server(1, "服務器1","192.168.8.74",8080,1)); serverList.add(new Server(2, "服務器2","192.168.8.75",8080,5)); serverList.add(new Server(3, "服務器3","192.168.8.76",8080,10)); for (int i = 0; i < 10; i++) { Server selectedServer = selectServer(serverList); System.out.format("第%d次請求，選擇服務器%s", i + 1, selectedServer.toString()); } }}

1.2.5 Hash

思路：根據(jù)每個每個請求ip（也可以是某個標識）ip.hash() % server.size()

優(yōu)點：將來自同一IP地址的請求，同一會話期內(nèi)，轉(zhuǎn)發(fā)到相同的服務器；實現(xiàn)會話粘滯。

缺點：目標服務器宕機后，會話會丟失；

代碼實現(xiàn)

public class IpHashDemo { @Data public static class Server { private int serverId; private String name; private String ip; private int port; public Server(int serverId, String name, String ip, int port) { this.serverId = serverId; this.name = name; this.ip = ip; this.port = port; } @Override public String toString() { return “serverId=” + serverId + “, name='” + name + ”’ + “, ip='” + ip + ”’ + “, port=” + port; } } //算法的具體實現(xiàn) public static Server selectServer(List serverList,String ip) { int ipHash = ip.hashCode(); return serverList.get(ipHash % serverList.size()); } public static void main(String[] args) { List serverList = new ArrayList(); serverList.add(new Server(1, “服務器1″,”192.168.8.74”,8080)); serverList.add(new Server(2, “服務器2″,”192.168.8.75”,8080)); serverList.add(new Server(3, “服務器3″,”192.168.8.76”,8080)); List ips = Arrays.asList(“192.168.8.74”, “192.168.8.75”, “192.168.8.76”); for (int i = 0; i < 10; i++) { for (String ip : ips) { Server selectedServer = selectServer(serverList, ip); System.out.format("請求ip:%s，選擇服務器%s", ip, selectedServer.toString()); } } }}

1.2.6 最少鏈接

思想：將請求分配到連接數(shù)最少的服務器上（目前處理請求最少的服務器）。

優(yōu)點：根據(jù)服務器當前的請求處理情況，動態(tài)分配；

缺點：算法實現(xiàn)相對復雜，需要監(jiān)控服務器請求連接數(shù)；

第2章：RestTemplate應用

2.1 RESTful架構(gòu)

REST（Representational State Transfer）表象化狀態(tài)轉(zhuǎn)變（表述性狀態(tài)轉(zhuǎn)變），基于HTTP、URI、XML、JSON等標準和協(xié)議，支持輕量級、跨平臺、跨語言的架構(gòu)設計。是Web服務的一種新的架構(gòu)風格（一種思想）。

2.1.1 主要原則

• 對網(wǎng)絡上所有的資源都有一個資源標志符。
• 對資源的操作不會改變標識符。
• 同一資源有多種表現(xiàn)形式（xml、json）
• 所有操作都是無狀態(tài)的（Stateless）

符合上述REST原則的架構(gòu)方式稱為RESTful

2.1.2 操作

在Restful之前的操作：http://127.0.0.1/user/query/1 GET 根據(jù)用戶id查詢用戶數(shù)據(jù)http://127.0.0.1/user/save POST 新增用戶http://127.0.0.1/user/update POST 修改用戶信息http://127.0.0.1/user/delete/1 GET/POST 刪除用戶信息

RESTful用法：http://127.0.0.1/user/1 GET 根據(jù)用戶id查詢用戶數(shù)據(jù)http://127.0.0.1/user POST 新增用戶http://127.0.0.1/user PUT 修改用戶信息http://127.0.0.1/user DELETE 刪除用戶信息

之前的操作是沒有問題的,大神認為是有問題的,有什么問題呢?你每次請求的接口或者地址,都在做描述,例如查詢的時候用了query,新增的時候用了save,其實完全沒有這個必要,我使用了get請求,就是查詢.使用post請求,就是新增的請求,我的意圖很明顯,完全沒有必要做描述,這就是為什么有了restful.

冪等性：對同一REST接口的多次訪問，得到的資源狀態(tài)是相同的。

安全性：對該REST接口訪問，不會使用服務器端資源的狀態(tài)發(fā)生改變。

2.1.3 SpringMVC實現(xiàn)

SpringMVC原生態(tài)的支持了REST風格的架構(gòu)設計

所涉及到的注解:

—@RequestMapping—@PathVariable—@ResponseBody

/** * @author Eclipse_2019 * @create 2022/2/8 18:04 */@RequestMapping(“restful/user”)@Controllerpublic class RestUserController { @Autowired private UserServiceImpl userService; /** * 根據(jù)用戶id查詢用戶數(shù)據(jù) * * @param id * @return */ @RequestMapping(value = “{id}”, method = RequestMethod.GET) @ResponseBody public ResponseEntity queryUserById(@PathVariable(“id”) Long id) { try { User user = this.userService.queryUserById(id); if (null == user) { // 資源不存在，響應404 return ResponseEntity.status(HttpStatus.NOT_FOUND).body(null); } // 200 // return ResponseEntity.status(HttpStatus.OK).body(user); return ResponseEntity.ok(user); } catch (Exception e) { e.printStackTrace(); } // 500 return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(null); } /** * 新增用戶 * * @param user * @return */ @RequestMapping(method = RequestMethod.POST) public ResponseEntity saveUser(@RequestBody User user) { try { this.userService.saveUser(user); return ResponseEntity.status(HttpStatus.CREATED).build(); } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } // 500 return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(null); } /** * 更新用戶資源 * * @param user * @return */ @RequestMapping(method = RequestMethod.PUT) public ResponseEntity updateUser(@RequestBody User user) { try { this.userService.updateUser(user); return ResponseEntity.status(HttpStatus.NO_CONTENT).build(); } catch (Exception e) { e.printStackTrace(); } // 500 return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(null); } /** * 刪除用戶資源 * * @param id * @return */ @RequestMapping(method = RequestMethod.DELETE) public ResponseEntity deleteUser(@RequestParam(value = “id”, defaultValue = “0”) Long id) { try { if (id.intValue() == 0) { // 請求參數(shù)有誤 return ResponseEntity.status(HttpStatus.BAD_REQUEST).build(); } this.userService.deleteUserById(id); // 204 return ResponseEntity.status(HttpStatus.NO_CONTENT).build(); } catch (Exception e) { e.printStackTrace(); } // 500 return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(null); }}

2.1.4 狀態(tài)碼

GET安全且冪等獲取表示變更時獲取表示（緩存）200（OK） – 表示已在響應中發(fā)出204（無內(nèi)容） – 資源有空表示301（Moved Permanently） – 資源的URI已被更新303（See Other） – 其他（如，負載均衡）304（not modified）- 資源未更改（緩存）400 （bad request）- 指代壞請求（如，參數(shù)錯誤）404 （not found）- 資源不存在406 （not acceptable）- 服務端不支持所需表示500 （internal server error）- 通用錯誤響應503 （Service Unavailable）- 服務端當前無法處理請求POST不安全且不冪等使用服務端管理的（自動產(chǎn)生）的實例號創(chuàng)建資源創(chuàng)建子資源部分更新資源如果沒有被修改，則不過更新資源（樂觀鎖）200（OK）- 如果現(xiàn)有資源已被更改201（created）- 如果新資源被創(chuàng)建202（accepted）- 已接受處理請求但尚未完成（異步處理）301（Moved Permanently）- 資源的URI被更新303（See Other）- 其他（如，負載均衡）400（bad request）- 指代壞請求404 （not found）- 資源不存在406 （not acceptable）- 服務端不支持所需表示409 （conflict）- 通用沖突412 （Precondition Failed）- 前置條件失敗（如執(zhí)行條件更新時的沖突）415 （unsupported media type）- 接受到的表示不受支持500 （internal server error）- 通用錯誤響應503 （Service Unavailable）- 服務當前無法處理請求PUT不安全但冪等用客戶端管理的實例號創(chuàng)建一個資源通過替換的方式更新資源如果未被修改，則更新資源（樂觀鎖）200 （OK）- 如果已存在資源被更改201 （created）- 如果新資源被創(chuàng)建301（Moved Permanently）- 資源的URI已更改303 （See Other）- 其他（如，負載均衡）400 （bad request）- 指代壞請求404 （not found）- 資源不存在406 （not acceptable）- 服務端不支持所需表示409 （conflict）- 通用沖突412 （Precondition Failed）- 前置條件失敗（如執(zhí)行條件更新時的沖突）415 （unsupported media type）- 接受到的表示不受支持500 （internal server error）- 通用錯誤響應503 （Service Unavailable）- 服務當前無法處理請求DELETE不安全但冪等刪除資源200 （OK）- 資源已被刪除301 （Moved Permanently）- 資源的URI已更改303 （See Other）- 其他，如負載均衡400 （bad request）- 指代壞請求404 （not found）- 資源不存在409 （conflict）- 通用沖突500 （internal server error）- 通用錯誤響應503 （Service Unavailable）- 服務端當前無法處理請求

2.2 RestTemplate

官方文檔：https://docs.spring.io/spring-framework/docs/4.3.7.RELEASE/javadoc-api/org/springframework/web/client/RestTemplate.html

2.2.1 是什么

傳統(tǒng)情況下在java代碼里訪問restful服務，一般使用Apache的HttpClient。不過此種方法使用起來太過繁瑣。spring提供了一種簡單便捷的模板類來進行操作，這就是RestTemplate。

2.2.2 使用

定義一個簡單的restful接口

@RestControllerpublic class TestController{ @RequestMapping(value = “testPost”, method = RequestMethod.POST) public ResponseBean testPost(@RequestBody RequestBean requestBean) { ResponseBean responseBean = new ResponseBean(); responseBean.setRetCode(“0000”); responseBean.setRetMsg(“succ”); return responseBean; }}

使用RestTemplate訪問該服務

//請求地址String url = “http://localhost:8080/testPost”;//入?yún)equestBean requestBean = new RequestBean();requestBean.setTest1(“1”);requestBean.setTest2(“2”);requestBean.setTest3(“3”);RestTemplate restTemplate = new RestTemplate();ResponseBean responseBean = restTemplate.postForObject(url, requestBean, ResponseBean.class);

從這個例子可以看出，使用restTemplate訪問restful接口非常的簡單粗暴無腦。(url, requestMap, ResponseBean.class)這三個參數(shù)分別代表 請求地址、請求參數(shù)、HTTP響應轉(zhuǎn)換被轉(zhuǎn)換成的對象類型。

RestTemplate方法的名稱遵循命名約定，第一部分指出正在調(diào)用什么HTTP方法，第二部分指示返回的內(nèi)容。本例中調(diào)用了restTemplate.postForObject方法，post指調(diào)用了HTTP的post方法，Object指將HTTP響應轉(zhuǎn)換為您選擇的對象類型。

RestTemplate定義了36個與REST資源交互的方法，其中的大多數(shù)都對應于HTTP的方法。其實，這里面只有11個獨立的方法，其中有十個有三種重載形式，而第十一個則重載了六次，這樣一共形成了36個方法。

• delete() 在特定的URL上對資源執(zhí)行HTTP DELETE操作
• exchange()在URL上執(zhí)行特定的HTTP方法，返回包含對象的ResponseEntity，這個對象是從響應體中映射得到的
• execute() 在URL上執(zhí)行特定的HTTP方法，返回一個從響應體映射得到的對象
• getForEntity() 發(fā)送一個HTTP GET請求，返回的ResponseEntity包含了響應體所映射成的對象
• getForObject() 發(fā)送一個HTTP GET請求，返回的請求體將映射為一個對象
• postForEntity() POST 數(shù)據(jù)到一個URL，返回包含一個對象的ResponseEntity，這個對象是從響應體中映射得到的
• postForObject() POST 數(shù)據(jù)到一個URL，返回根據(jù)響應體匹配形成的對象
• headForHeaders() 發(fā)送HTTP HEAD請求，返回包含特定資源URL的HTTP頭
• optionsForAllow() 發(fā)送HTTP OPTIONS請求，返回對特定URL的Allow頭信息
• postForLocation() POST 數(shù)據(jù)到一個URL，返回新創(chuàng)建資源的URL
• put() PUT 資源到特定的URL

實際上,由于Post 操作的非冪等性,它幾乎可以代替其他的CRUD操作.

第3章：Ribbon簡介與應用

3.1 簡介

目前主流的負載方案分為以下兩種：

• 集中式負載均衡，在消費者和服務提供方中間使用獨立的代理方式進行負載，有硬件的（比如 F5），也有軟件的（比如 Nginx）。
• 客戶端自己做負載均衡，根據(jù)自己的請求情況做負載，Ribbon 就屬于客戶端自己做負載。

Ribbon 是一個基于 HTTP和TCP的客戶端負載均衡工具。通過 Spring Cloud 的封裝，可以讓我們輕松地將面向服務的 REST 模版請求自動轉(zhuǎn)換成客戶端負載均衡的服務調(diào)用。

Spring Cloud Ribbon 雖然只是一個工具類框架，它不像服務注冊中心、配置中心、API 網(wǎng)關那樣需要獨立部署，但是它幾乎存在于每一個 Spring Cloud 構(gòu)建的微服務和基礎設施中。因為微服務間的調(diào)用，API 網(wǎng)關的請求轉(zhuǎn)發(fā)等內(nèi)容，實際上都是通過 Ribbon 來實現(xiàn)的（https://github.com/Netflix/ribbon）。

Ribbon主要提供：

• 客戶端負載均衡
• 容錯處理
• 支持多協(xié)議的異步通信。支持HTTP、TCP、UDP協(xié)議。
• 支持緩存和批量處理

Ribbon模塊介紹：

• ribbon: Ribbon功能應用入口。使用Ribbon的功能可以通過初始化應用入口，調(diào)用接口實現(xiàn)。該模塊依賴其他模版實現(xiàn)所需功能，比如容錯處理ribbon依賴Histrix。
• ribbon-loadbalancer:負載均衡功能入口。如果僅需要負載均衡功能，可以使用單獨使用該模塊。
• ribbon-eureka:基于Eureka客戶端實現(xiàn)可用服務列表管理
• ribbon-transport: 具備客戶端負載均衡能力的，基于RxNetty框架能夠支持HTTP、TCP、UDP協(xié)議的通信客戶端。
• ribbon-httpclient: 具備客戶端負載均衡能力的，基于Apache HttpClient，支持REST風格的HTTP請求客戶端。
• ribbon-core: 客戶端配置APIs和其他共享APIs。
• ribbon-example:使用例子。

3.2 對比

與Nginx的對比

• Nginx是一種服務器端負載均衡 ，客戶端所有請求統(tǒng)一交給 nginx，由 nginx 進行實現(xiàn)負載均衡請求轉(zhuǎn)發(fā)。
• Ribbon是客戶端負載均衡 Ribbon 是從 eureka 注冊中心服務器端上獲取服務注冊信息列表，緩存到本地，然后在本地實現(xiàn)輪詢負載均衡策略。既在客戶端實現(xiàn)負載均衡。

應用場景的區(qū)別：

• Nginx適合于服務器端實現(xiàn)負載均衡比如 Tomcat ，Ribbon適合與在微服務中RPC遠程調(diào)用實現(xiàn)本地服務負載均衡，比如 Dubbo、SpringCloud 中都是采用本地負載均衡。
• spring cloud的Netflix中提供了兩個組件實現(xiàn)軟負載均衡調(diào)用：ribbon和feign。
• Ribbon是一個基于 HTTP 和 TCP 客戶端的負載均衡器，它可以在客戶端配置 ribbonServerList（服務端列表），然后輪詢請求以實現(xiàn)均衡負載。

3.3 應用

不含Eureka

1.先創(chuàng)建兩個服務，用于負載均衡

Server 1 和Server2 的端口號要不同，不然起不來

Server 1接口如下：

@RestControllerpublic class TestController { @GetMapping(“/user/{id}”) public String Info(@PathVariable Long id) { return “this is client1 ,id=” + id; }}

Server 2接口如下：

@RestControllerpublic class TestController { @GetMapping(“/user/{id}”) public String Info(@PathVariable Long id) { return “this is Client2,id=” + id; }}

啟動類都是一樣的，如下：

@SpringBootApplicationpublic class Application{ public static void main( String[] args ) { SpringApplication.run(Application.class, args); }}

2.創(chuàng)建一個調(diào)用方來請求這個接口

引依賴包

org.springframework.cloud spring-cloud-commons 2.2.3.RELEASE org.springframework.cloud spring-cloud-starter-netflix-ribbon 2.2.3.RELEASE

配置啟動類，并注入 RestTemplate

import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.cloud.client.loadbalancer.LoadBalanced;import org.springframework.context.annotation.Bean;import org.springframework.scheduling.annotation.EnableScheduling;import org.springframework.web.client.RestTemplate;@EnableScheduling@SpringBootApplicationpublic class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } @Bean @LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); }}

配置一下 application.properties,如下：

ribbon-test.ribbon.listOfServers=127.0.0.1:2223,127.0.0.1:2222# ribbon連接超時default-test.ribbon.ConnectTimeout=500# ribbon讀超時default-test.ribbon.ReadTimeout=8000######## management ########management.security.enabled=falseendpoints.health.sensitive=false

3.驗證

再創(chuàng)建一個 測試方法來驗證是否生效，放在test 目錄下面，代碼如下：

import com.test.Application;import org.junit.Test;import org.junit.runner.RunWith;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.boot.test.context.SpringBootTest;import org.springframework.test.context.junit4.SpringRunner;import org.springframework.web.client.RestTemplate;@RunWith(SpringRunner.class)@SpringBootTest(classes = Application.class)public class RibbonBalanceClientTest { @Autowired private RestTemplate restTemplate; @Test public void contextLoads() { for (int i = 0; i < 10; i++) { String forObject = restTemplate.getForObject("http://ribbon-test/user/1000", String.class); System.out.println("============================"); System.out.println(forObject); } }}

先啟動 兩個server ,然后在 測試 測試類 ，結(jié)果如下：

============================this is Client2,id=1000============================this is client1 ,id=1000============================this is Client2,id=1000============================this is client1 ,id=1000============================this is Client2,id=1000============================this is client1 ,id=1000============================this is Client2,id=1000============================this is client1 ,id=1000============================this is Client2,id=1000============================this is client1 ,id=1000

從結(jié)果可以看出實現(xiàn)了負載均衡，默認是 輪詢策略，Client1和 clien2 依次調(diào)用。

3.3.1 請求超時機制配置

Ribbon 中有兩種和時間相關的設置，分別是請求連接的超時時間和請求處理的超時時間，設置規(guī)則如下：

# 請求連接的超時時間ribbon.ConnectTimeout=2000 （默認值：2000）# 請求處理的超時時間ribbon.ReadTimeout=5000 （默認值：5000）# 也可以為每個Ribbon客戶端設置不同的超時時間, 通過服務名稱進行指定：goods-serviceo.ribbon.ConnectTimeout=2000goods-service.ribbon.ReadTimeout=5000

3.3.2 并發(fā)連接數(shù)

Ribbon可以通過下面的配置項，來限制httpclient連接池的最大連接數(shù)量、以及針對不同host的最大連接數(shù)量。

Ribbon底層的網(wǎng)絡通信，采用的是HttpClient中的PoolingHttpClientConnectionManager連接池，連接池的好處是避免頻繁建立連接（針對單個目標地址）帶來的性能開銷，但是維護過多的鏈接會對客戶端造成內(nèi)存以及維護上的成本。

所以，可以通過MaxTotalConnections限制總的連接數(shù)量，或者通過MaxConnectionsPerHost限制針對每個host的最大連接數(shù)。

# 最大連接數(shù)ribbon.MaxTotalConnections=500 （默認值：200）# 每個host最大連接數(shù)ribbon.MaxConnectionsPerHost=500 （默認值：50）

3.3.3 負載均衡配置

負載均衡的核心，是通過負載均衡算法來實現(xiàn)對目標服務請求的分發(fā)。Ribbion中默認提供了7種負載均衡算法：

如何指定Ribbon的負載策略呢？

.ribbon.NFLoadBalancerRuleClassName: Should implement IRule(負載均衡算法)

修改mall-portal項目中的application.properties文件，指定負載均衡算法。

goods-service.ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.RandomRule

驗證方法：

1.在BaseLoadBalancer.chooseServer()方法中加斷點

public Server chooseServer(Object key) { if (counter == null) { counter = createCounter(); } counter.increment(); if (rule == null) { //斷點，查看rule所屬實例 return null; } else { }}

2.在RandomRule.choose()方法增加斷點，觀察請求是否進入。

除此之外，Ribbon還提供了自定義負載均衡的擴展機制，只需要繼承AbstractLoadBalancerRule抽象類即可。

3.3.4 自定義負載均衡

自定義負載均衡的實現(xiàn)主要分幾個步驟：

public class DefineIpHashRule extends AbstractLoadBalancerRule { public Server choose(ILoadBalancer lb, Object key){ if(lb==null){ return null; }else { Server server = null; while (server == null) { //獲取可用的服務實例列表 List upList = lb.getReachableServers(); //獲取所有的服務實例列表 List allList = lb.getAllServers(); int serverCount = allList.size(); if (serverCount == 0) { return null; } int index=ipAddressHash(serverCount); server = upList.get(index); } return server; } } private int ipAddressHash(int serverCount){ ServletRequestAttributes requestAttributes=(ServletRequestAttributes) RequestContextHolder.getRequestAttributes(); String remoteAddr=requestAttributes.getRequest().getRemoteAddr(); int code=Math.abs(remoteAddr.hashCode()); return code%serverCount; } @Override public Server choose(Object key) { return choose(getLoadBalancer(),key); } @Override public void initWithNiwsConfig(IClientConfig iClientConfig) { }}

ILoadBalancer接口實現(xiàn)類做了以下的一些事情：

• 維護了存儲服務實例Server對象的二個列表。一個用于存儲所有服務實例的清單，一個用于存儲正常服務的實例清單
• 初始化得到可用的服務列表，啟動定時任務去實時的檢測服務列表中的服務的可用性，并且間斷性的去更新服務列表，結(jié)合注冊中心。
• 選擇可用的服務進行調(diào)用（這個一般交給IRule去實現(xiàn)，不同的輪詢策略）

修改application.properties文件

spring-cloud-user-service.ribbon.NFLoadBalancerRuleClassName=com.mallportal.DefineIpHashRule

3.3.5 Ribbon核心之Ping機制

在ribbon負載均衡器中，提供了ping機制，每隔一段時間，就會去ping服務器，由 com.netflix.loadbalancer.IPing 接口去實現(xiàn)。

單獨使用ribbon，不會激活ping機制，默認采用DummyPing（在RibbonClientConfiguration中實例化），isAlive()方法直接返回true。

ribbon和eureka集成，默認采用NIWSDiscoveryPing（在EurekaRibbonClientConfiguration中實例化的），只有服務器列表的實例狀態(tài)為up的時候才會為Alive。

IPing中默認內(nèi)置了一些實現(xiàn)方法如下。

3.3.6 請求重試機制

在網(wǎng)絡通信中，有可能會存在由網(wǎng)絡問題或者目標服務異常導致通信失敗，這種情況下我們一般會做容錯設計，也就是再次發(fā)起請求進行重試。

Ribbon提供了一種重試的負載策略：RetryRule，可以通過下面這個配置項來實現(xiàn)

spring-cloud-user-service.ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.RetryRule

由于在單獨使用Ribbon的機制下，并沒有開啟Ping機制，所以所有服務默認是認為正常的，則這里并不會發(fā)起重試。如果需要演示重試機制，需要增加PING的判斷。

1.引入依賴包

org.apache.httpcomponents httpclient

2.創(chuàng)建一個心跳檢查的類

public class HealthChecker implements IPing { @Override public boolean isAlive(Server server) { String urlStr = “http://”+server.getId()+”/healthCheck”; boolean isAlive = false; HttpClient httpClient = new DefaultHttpClient(); HttpUriRequest getRequest = new HttpGet(urlStr); try { HttpResponse response = httpClient.execute(getRequest); isAlive = response.getStatusLine().getStatusCode() == 200; }catch (Exception e){ }finally { getRequest.abort(); } return isAlive; }}

3.修改mall-portal中application.properties文件，添加自定義心跳檢查實現(xiàn)，以及心跳檢查間隔時間。

goods-service.ribbon.NFLoadBalancerPingClassName=com.mallportal.HealthCheckergoods-service.ribbon.NFLoadBalancerPingInterval=3

4.在goods-service這個模塊中，增加一個心跳檢查的接口

@GetMapping(“/healthCheck”)public String health(){ return “SUCCESS”;}

5.測試服務啟動+停止，對于請求的影響變化。

第4章：Loadbalancer

參考官方文檔：https://spring.io/guides/gs/spring-cloud-loadbalancer

LoadBalancer 是Spring Cloud自研的組件，支持WebFlux。

由于Ribbon停止更新進入維護狀態(tài)，所以Spring Cloud不得不研發(fā)一套新的Loadbalancer機制進行替代。

在Spring Cloud 2020版本之后，Ribbon已經(jīng)被下掉了，直接用Loadbalancer取代，當然我們?nèi)匀豢梢岳^續(xù)使用Ribbon。

1.引入Loadbalancer相關jar包

org.springframework.cloud spring-cloud-starter-loadbalancer org.springframework.boot spring-boot-starter-webflux

2.定義一個配置類，這個配置類通過硬編碼的方式寫死了goods-service這個服務的實例列表，代碼如下

@Configurationpublic class GoodsServiceConfiguration { @Bean ServiceInstanceListSupplier serviceInstanceListSupplier(){ return new GoodsServiceInstanceListSupplier(“goods-service”); }}//自定義實例列表class GoodsServiceInstanceListSupplier implements ServiceInstanceListSupplier{ private final String serviceId; GoodsServiceInstanceListSupplier(String serviceId){ this.serviceId=serviceId; } @Override public String getServiceId() { return serviceId; } @Override public Flux get() { //Flux.just可以指定序列中包含的全部元素。創(chuàng)建出來的 Flux 序列在發(fā)布這些元素之后會自動結(jié)束 return Flux.just(Arrays.asList(new DefaultServiceInstance(serviceId+”1″,serviceId,”localhost”,9091,false), new DefaultServiceInstance(serviceId+”2″,serviceId,”localhost”,9081,false))); }}

3.創(chuàng)建一個配置類，注入一個LoadBalancerClient

@Configuration@LoadBalancerClient(name=”goods-service”,configuration = GoodsServiceConfiguration.class)public class WebClientConfiguration { @Bean @LoadBalanced WebClient.Builder webClientBuilder(){ return WebClient.builder(); }}

4.修改測試類

@Slf4j@RestController@RequestMapping(“/order”)public class OrderController { @Autowired private WebClient.Builder loadBalancedWebClientBuilder; /** * 下單 * WebFlux需要用Mono或者Flux，它是WebFLux的核心。 */ @GetMapping public Mono order(){ log.info(“begin order”); return loadBalancedWebClientBuilder.build().get().uri(“http://goods-service/getGoodsById”).retrieve().bodyToMono(String.class); }}

5.為了更好的看到效果，修改goods-service模塊，打印每個服務的端口號碼。

@RestControllerpublic class GoodsController { @Value(“${server.port}”) private String port; @GetMapping(“/getGoodsById”) public String getGoodsById(){ System.out.println(“我是：”+port); return “返回商品詳細信息”; }}

在Spring Cloud 2020.x版本中，Spring Cloud Netflix只留下了Eureka，其他的組件都已經(jīng)移除了。

下文預告