1、微服務(wù)為什么要用網(wǎng)關(guān)？（首先要理解網(wǎng)關(guān)并不是必須的組件，只是一種設(shè)計(jì)模式或者設(shè)計(jì)理念）

客戶(hù)端直接訪問(wèn)各子服務(wù)：

微服務(wù)剛剛誕生的時(shí)候，人們將服務(wù)進(jìn)行拆分，實(shí)現(xiàn)服務(wù)之間的松耦合，并且每個(gè)服務(wù)有專(zhuān)門(mén)的團(tuán)隊(duì)維護(hù)，然后客戶(hù)端直接和各個(gè)子服務(wù)進(jìn)行交互。比如，訂單，商品，會(huì)員服務(wù)。

這種客戶(hù)端直接和后端服務(wù)交互的方式會(huì)有什么問(wèn)題呢？

1、客戶(hù)端需要知道每個(gè)服務(wù)的地址（如果有網(wǎng)關(guān)，分布式部署的話這樣可以統(tǒng)一api的ip地址，再由網(wǎng)關(guān)去分發(fā)，可以通過(guò)注冊(cè)中心獲取你需要的服務(wù)節(jié)點(diǎn)列表，然后給你分配你調(diào)用那個(gè)節(jié)點(diǎn)去調(diào)用）

2、每個(gè)后端服務(wù)都需要實(shí)現(xiàn)認(rèn)證、限流、日志、監(jiān)控、緩存等功能，重復(fù)造輪子大大降低了開(kāi)發(fā)效率，而這些公共業(yè)務(wù)邏輯完全可以拆分出來(lái)。而且會(huì)造成的代碼復(fù)雜度和維護(hù)難度上升。

3、假如后端某些服務(wù)由之前的http/https調(diào)用變成rpc調(diào)用，或者某些參數(shù)發(fā)生改變，則客戶(hù)端需要做很大調(diào)整。

這里我覺(jué)得還有必要補(bǔ)一篇rpc遠(yuǎn)程調(diào)用和restful請(qǐng)求的區(qū)別，這里簡(jiǎn)單科普一下：

rpc一般用于內(nèi)部微服務(wù)之間的調(diào)用，restful請(qǐng)求也就是http請(qǐng)求一般是請(qǐng)求外部服務(wù)；

rpc可以像調(diào)用本地方法一樣去調(diào)用其它微服務(wù)（在不同的服務(wù)器）的方法，原理是一般是cp/ip協(xié)議+動(dòng)態(tài)代理。這里就減少了向外暴露的服務(wù)。而http請(qǐng)求是基于http協(xié)議的，需要暴露給外部，而且需要自己封裝請(qǐng)求提和請(qǐng)求參數(shù)。rpc只是一種概念，有多種實(shí)現(xiàn)方式。

?

引入網(wǎng)關(guān)可以怎么解決這些問(wèn)題呢？

1、網(wǎng)關(guān)作為邊界，分割了內(nèi)部應(yīng)用和外部調(diào)用。

不同于外部API一般使用HTTP或REST，內(nèi)部微服務(wù)可以從使用不用通訊協(xié)議中收獲益處。這些協(xié)議可以是ProtoBuf或AMQP，甚至是諸如SOAP，JSON-RPC或者XML-RPC這樣的系統(tǒng)集成協(xié)議。API網(wǎng)關(guān)可以對(duì)這些協(xié)議提供統(tǒng)一的外部REST接口，這就允許開(kāi)發(fā)團(tuán)隊(duì)挑選一款最適合于內(nèi)部架構(gòu)的協(xié)議。

?

2、網(wǎng)關(guān)實(shí)現(xiàn)了安全層，降低了各子微服務(wù)的復(fù)雜度

API網(wǎng)關(guān)通過(guò)提供額外的安全層幫助阻止大規(guī)模攻擊。這些攻擊包括SQL注入，XML解析漏洞和DoS攻擊。

微服務(wù)中有一些常見(jiàn)的要點(diǎn)，諸如使用API令牌進(jìn)行授權(quán)，訪問(wèn)控制和調(diào)用頻次限制。這每個(gè)點(diǎn)都需要每個(gè)服務(wù)區(qū)增加額外的時(shí)間去實(shí)現(xiàn)它們。API網(wǎng)關(guān)將這些要點(diǎn)從你的代碼中提取出來(lái)，允許你的服務(wù)只關(guān)注于它們需要關(guān)注的任務(wù)。同時(shí)可以作為統(tǒng)一收集微服務(wù)日志的地方，方便了問(wèn)題的定位。

?

3、微服務(wù)方便了服務(wù)的管理，提供了外部請(qǐng)求的統(tǒng)一入口，實(shí)現(xiàn)了路由轉(zhuǎn)發(fā)，同時(shí)降低了對(duì)外暴露的服務(wù)

如果一個(gè)業(yè)務(wù)功能，調(diào)用了n個(gè)外部微服務(wù)，那邊管理和維護(hù)起來(lái)簡(jiǎn)直是噩夢(mèng)，二微服務(wù)萬(wàn)貫基于統(tǒng)一的域名和上下文去訪問(wèn)，管理起來(lái)更加方便。同時(shí)網(wǎng)關(guān)還可以實(shí)現(xiàn)路由轉(zhuǎn)發(fā)和負(fù)載均衡的功能，但是并不是最佳的選擇，因?yàn)橛衅渌_(kāi)源組件比它更nb，那就是nginx。

2、 有了網(wǎng)關(guān)為什么還需要nginx或者ribbon作負(fù)載均衡？

你可以理解為基于性能問(wèn)題。

3、有了網(wǎng)關(guān)為什么還要需要有服務(wù)注冊(cè)和發(fā)現(xiàn)？

讓我們來(lái)看看一個(gè)同時(shí)有網(wǎng)關(guān)和服務(wù)發(fā)現(xiàn)注冊(cè)中心的請(qǐng)求路徑是怎樣的？

一個(gè)請(qǐng)求過(guò)來(lái)了，根據(jù)網(wǎng)關(guān)根據(jù)路由規(guī)則分析出是請(qǐng)求的哪個(gè)服務(wù)，然后跟注冊(cè)中心說(shuō)：這個(gè)XX服務(wù)有木有？沒(méi)有？那404！有？服務(wù)下有幾個(gè)實(shí)例，都告訴我我自己找一個(gè)或者你告訴我一個(gè)能用的。然后把請(qǐng)求往某個(gè)服務(wù)的某個(gè)實(shí)例上發(fā)送，得到返回值后丟給客戶(hù)端。 ? ? ? 這樣就不會(huì)出現(xiàn)，某個(gè)服務(wù)一直被調(diào)而一直在等待響應(yīng)最終造成服務(wù)器掛掉的風(fēng)險(xiǎn)。網(wǎng)關(guān)保障的是微服務(wù)之間的安全和解耦，注冊(cè)中心是保障微服務(wù)的高可用和可靠。但是網(wǎng)關(guān)的配置最好更高一點(diǎn)，不然也是一種風(fēng)險(xiǎn)。或者在網(wǎng)關(guān)前面掛一個(gè)nginx代理，多幾套網(wǎng)關(guān)實(shí)例也行。

總結(jié)

以上是生活随笔為你收集整理的网关、负载均衡、服务注册发现什么关系？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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