1、微服務為什么要用網關？（首先要理解網關并不是必須的組件，只是一種設計模式或者設計理念）

客戶端直接訪問各子服務：

微服務剛剛誕生的時候，人們將服務進行拆分，實現服務之間的松耦合，并且每個服務有專門的團隊維護，然后客戶端直接和各個子服務進行交互。比如，訂單，商品，會員服務。

這種客戶端直接和后端服務交互的方式會有什么問題呢？

1、客戶端需要知道每個服務的地址（如果有網關，分布式部署的話這樣可以統一api的ip地址，再由網關去分發，可以通過注冊中心獲取你需要的服務節點列表，然后給你分配你調用那個節點去調用）

2、每個后端服務都需要實現認證、限流、日志、監控、緩存等功能，重復造輪子大大降低了開發效率，而這些公共業務邏輯完全可以拆分出來。而且會造成的代碼復雜度和維護難度上升。

3、假如后端某些服務由之前的http/https調用變成rpc調用，或者某些參數發生改變，則客戶端需要做很大調整。

這里我覺得還有必要補一篇rpc遠程調用和restful請求的區別，這里簡單科普一下：

rpc一般用于內部微服務之間的調用，restful請求也就是http請求一般是請求外部服務；

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

?

引入網關可以怎么解決這些問題呢？

1、網關作為邊界，分割了內部應用和外部調用。

不同于外部API一般使用HTTP或REST，內部微服務可以從使用不用通訊協議中收獲益處。這些協議可以是ProtoBuf或AMQP，甚至是諸如SOAP，JSON-RPC或者XML-RPC這樣的系統集成協議。API網關可以對這些協議提供統一的外部REST接口，這就允許開發團隊挑選一款最適合于內部架構的協議。

?

2、網關實現了安全層，降低了各子微服務的復雜度

API網關通過提供額外的安全層幫助阻止大規模攻擊。這些攻擊包括SQL注入，XML解析漏洞和DoS攻擊。

微服務中有一些常見的要點，諸如使用API令牌進行授權，訪問控制和調用頻次限制。這每個點都需要每個服務區增加額外的時間去實現它們。API網關將這些要點從你的代碼中提取出來，允許你的服務只關注于它們需要關注的任務。同時可以作為統一收集微服務日志的地方，方便了問題的定位。

?

3、微服務方便了服務的管理，提供了外部請求的統一入口，實現了路由轉發，同時降低了對外暴露的服務

如果一個業務功能，調用了n個外部微服務，那邊管理和維護起來簡直是噩夢，二微服務萬貫基于統一的域名和上下文去訪問，管理起來更加方便。同時網關還可以實現路由轉發和負載均衡的功能，但是并不是最佳的選擇，因為有其它開源組件比它更nb，那就是nginx。

2、 有了網關為什么還需要nginx或者ribbon作負載均衡？

你可以理解為基于性能問題。

3、有了網關為什么還要需要有服務注冊和發現？

讓我們來看看一個同時有網關和服務發現注冊中心的請求路徑是怎樣的？

一個請求過來了，根據網關根據路由規則分析出是請求的哪個服務，然后跟注冊中心說：這個XX服務有木有？沒有？那404！有？服務下有幾個實例，都告訴我我自己找一個或者你告訴我一個能用的。然后把請求往某個服務的某個實例上發送，得到返回值后丟給客戶端。 ? ? ? 這樣就不會出現，某個服務一直被調而一直在等待響應最終造成服務器掛掉的風險。網關保障的是微服務之間的安全和解耦，注冊中心是保障微服務的高可用和可靠。但是網關的配置最好更高一點，不然也是一種風險。或者在網關前面掛一個nginx代理，多幾套網關實例也行。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。