怎么理解微服務網關

這篇文章主要介紹“怎么理解微服務網關”，在日常操作中，相信很多人在怎么理解微服務網關問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么理解微服務網關”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

什么是網關

網關作為流量入口，其實就是一個把HTTP請求拓展到后端服務的過程，網關封裝了后端服務，還提供了一些更高級的功能，例如：身份驗證、監控、負載均衡、緩存、多協議支持、限流、熔斷等等。

為什么需要網關

統一流量入口

客戶端與微服務直接通信，如果涉及到的微服務數量巨大，將導致客戶端代碼非常復雜。
部分服務使用的協議不是Web友好協議。一個服務可能使用Thrift二進制RPC，而另一個服務可能使用AMQP消息傳遞協議，不管哪種協議都不是瀏覽器友好或防火墻友好。在防火墻之外，應用程序應該使用諸如HTTP和WebSocket之類的協議，即協議需要適配。
這種方法的另一個缺點是，它會使得微服務難以重構。隨著時間推移，我們可能想要更改系統劃分成服務的方式。例如，我們可能合并兩個服務，或者將一個服務拆分成兩個或更多服務。然而，如果客戶端與微服務直接通信，那么執行這類重構就非常困難了。

統一維護通用功能

接口鑒權、限流、熔斷降級、隔離、日志監控等通用功能在網關統一實現，不必下沉到業務邏輯，降低分開維護的成本與風險。

網關的功能

統一接入

前端（包括app或者其它來源）的流量，都能在統一網關層進行接入，需要做到高性能透傳、高并發接入。

流量管控

面對海量流量，我們怎樣通過一些防刷技術，保障網關不被大流量沖垮；以及怎樣通過一些像限流、降級、熔斷等技術，對網關進行全方位保護。

協議適配

由于在內部開發中我們都是以RPC協議(thrift or dubbo)去做開發，暴露給內部服務，當外部服務需要使用這個接口的時候往往需要將RPC協議轉換成HTTP協議。

安全防護

防止惡意流量，黑名單機制、限制非法IP等手段拒絕惡意流量。

網關設計的關鍵點

接入

接入層需要能扛特別大的并發流量。Nginx天然就是NIO異步的方式，能夠非常好地支持大并發的業務需求。所以可以把一些核心的，比如降級、流控等，都放在這一層（借助lua的應用邏輯實現），讓它替我們在最前端把流量防住。

異步

對于我們統一的網關層，如何用少量的機器接入更多的服務，這就需要我們的異步，用來提高更多的吞吐量。對于異步化一般有下面兩種策略：
Tomcat/Jetty+NIO+servlet3
這種策略使用的比較普遍，京東，有贊，Zuul，都選取的是這個策略，這種策略比較適合HTTP。在Servlet3中可以開啟異步。
Netty+NIO
Netty為高并發而生，目前唯品會的網關使用這個策略，在唯品會的技術文章中在相同的情況下Netty是每秒30w+的吞吐量，Tomcat是13w+,可以看出是有一定的差距的，但是Netty需要自己處理HTTP協議，這一塊比較麻煩。
對于網關是HTTP請求場景比較多的情況可以采用Servlet，畢竟有更加成熟的處理HTTP協議。如果更加重視吞吐量那么可以采用Netty。

全鏈路異步

對于來的請求做到異步，為了達到全鏈路異步所以我們需要對去的請求也進行異步處理，對于去的請求我們可以利用rpc的異步支持進行異步請求，也可以考慮采用借助RxJava采取觀察者模式進行異步請求。

流量管控

限流、降級、熔斷降級（熔斷之后就相當于降級了）

分離（隔離）

請求解析和業務處理分離

                                                            圖-tomcat分離

第一個是通過NIO的方式，把請求解析的線程和后面處理的業務線程進行分離。請求由Tomcat單線程處理，在NIO模式下可以用非常少量的線程處理大量的鏈接情況。業務邏輯處理和生成響應都是由另外的Tomcat線程池處理，從而跟請求線程隔離。這里的業務線程池還可以進一步隔離，不同業務設置不同的線程池。

還可以采用響應式編程，借助Reactor模式，在使用很少固定數目的線程和較少的內存情況下的提高吞吐量，避免阻塞，Spring-WebFlux正是響應式的編程框架。

業務線程池分離

第二個是業務線程池分離，就是通過一個線程的隔離技術，把不同的接口或不同類型的接口進行隔離。
比如訂單相關的接口，拿20個單獨線程去處理；商品相關的接口，拿10個單獨的線程去處理，這樣的話就可以讓不同的接口之間互不影響，如果訂單這塊有一個出了問題，最多消耗它自己，不會影響到其他接口的線程的調用。
具體的線程隔離可以根據業務來指定一組線程的數量，這幾個線程是為固定接口準備的。
當這個接口出現問題，它就把自己的線程數用掉了，不會去占用其他接口的線程，這樣起到了線程隔離的作用，讓單個API出問題的時候不會影響到其他。

信號量隔離
信號量隔離只是限制了總的并發數，服務還是主線程進行同步調用。這個隔離如果遠程調用超時依然會影響主線程，從而會影響其他業務。因此，如果只是想限制某個服務的總并發調用量或者調用的服務不涉及遠程調用的話，可以使用輕量級的信號量來實現。有贊的網關由于沒有自定義filter所以選取的是信號量隔離。
線程池隔離
最簡單的就是不同業務之間通過不同的線程池進行隔離，就算業務接口出現了問題由于線程池已經進行了隔離那么也不會影響其他業務。在京東的網關實現之中就是采用的線程池隔離，比較重要的業務比如商品或者訂單都是單獨的通過線程池去處理。但是由于是統一網關平臺，如果業務線眾多，大家都覺得自己的業務比較重要需要單獨的線程池隔離，如果使用的是Java語言開發的話，那么在Java中線程是比較重的資源比較受限，如果需要隔離的線程池過多不是很適用。如果使用一些其他語言比如Golang進行開發網關的話，線程是比較輕的資源，所以比較適合使用線程池隔離。

集群隔離
如果有某些業務就需要使用隔離但是統一網關又沒有線程池隔離那么應該怎么辦呢？那么可以使用集群隔離，如果你的某些業務真的很重要那么可以為這一系列業務單獨申請一個集群或者多個集群，通過機器之間進行隔離。

快速失敗-鏈路中的超時

超時設置對于一個分布式系統非常重要，沒有設置超時，請求響應慢的情況下可能會累積導致連鎖反應，甚至雪崩，一般包括Mysql、Redis、RPC服務、HTTP服務等的超時。快速失敗是非常重要的實踐，不光是網關系統，其它系統也是一樣，需要重點關注整個鏈條中的超時設置。

鏈式處理

在設計模式中有一個模式叫責任鏈模式，他的作用是避免請求發送者與接收者耦合在一起，讓多個對象都有可能接收請求，將這些對象連接成一條鏈，并且沿著這條鏈傳遞請求，直到有對象處理它為止。通過這種模式將請求的發送者和請求的處理者解耦了。在我們的各個框架中對此模式都有實現，比如servlet里面的filter，springmvc里面的Interceptor。Zuul就采用了這種模式，分為前置、路由、后置和錯誤過濾器，一個請求會先按順序通過所有的前置過濾器，之后在路由過濾器中轉發給后端應用，得到響應后又會通過所有的后置過濾器，最后響應給客戶端，在整個流程中如果發生了異常則會跳轉到錯誤過濾器中。

到此，關于“怎么理解微服務網關”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！