微服務架構必讀篇 - 網關

前言

由于網際網路的高速發展，網絡資料請求數激增，使得伺服器承受的壓力越來越大。在早期的系統架構中，為減輕單台伺服器的壓力，通常使用 Load Balancer 來将網絡流量平攤到多個伺服器中。如今後端服務的種類和數量在不斷變多，傳統的 Load Balancer 為主的系統架構的局限性就變得明顯起來，于是一款主要工作在七層且具有豐富擴充能力的基礎設施便應運而生，那便是 API Gateway。

什麼是API網關

API網關 簡單來說是一種主要工作在七層、專門用于 API 的管理和流量轉發的基礎設施，并擁有強大的擴充性。

網關的角色是作為一個API架構，用來保護、增強和控制對于API服務的通路。它是一個處于應用程式或服務（提供REST API接口服務）之前的系統，用來管理授權、通路控制和流量限制等。這樣REST API接口服務就被網關保護起來，對所有的調用者透明。是以，隐藏在API網關後面的業務系統就可以專注于建立和管理服務，無需關心這些政策性的請求。

網關工作流程如下圖：

網關必須具備的特點

1.高性能

對于高性能而言，網關不應該也不能成為性能的瓶頸，最好使用高性能的程式設計語言來實作，如 C、C++、Go 和 Java。網關對後端的請求，以及對前端的請求的服務一定要使用異步非阻塞的 I/O 來確定後端延遲不會導緻應用程式中出現性能問題。C 和 C++ 可以參看 Linux 下的 epoll 和 Windows 的 I/O Completion Port 的異步 IO 模型，Java 下如 Netty、Spring Reactor 的 NIO 架構。

2.高可用

所有的流量或調用都要經過網關，是以網關必須成為一個高可用的元件，它的穩定直接關系到了所有服務的穩定。不能出現單點故障，是以，一個好的網關至少做到以下幾點。

叢集化 。網關要成為一個叢集，并可以自己同步叢集資料，而不需要依賴于第三方系統來同步資料。

服務化 。網關還需要做到在不間斷的情況下修改配置，一種是像 Nginx reload 配置那樣，可以做到不停服務，另一種是最好做到服務化。也就是說，得要有自己的 Admin API 來在運作時修改配置。

持續化 。比如重新開機，就是像 Nginx 那樣優雅地重新開機。有一個主管請求分發的主程序。當我們需要重新開機時，新的請求被配置設定到新的程序中，而老的程序處理完正在處理的請求後就退出。

3.高擴充

網關要承接所有的業務流量和請求，是以一定存在或多或少的業務邏輯。而業務邏輯是多變和不确定的，比如，需要在網關上加入一些和業務相關的東西。是以一個好的網關還需要是可以擴充的，并能進行二次開發。當然，像 Nginx 那樣通過 Module 進行二次開發的也是可以的。

網關主要功能

1. 路由功能： 路由是微服務網關的核心能力。通過路由功能微服務網關可以将請求轉發到目标微服務。在微服務架構中，網關可以結合注冊中心的動态服務發現，實作對後端服務的發現，調用方隻需要知道網關對外暴露的服務API就可以透明地通路後端微服務。
2. 負載均衡： API網關結合負載均衡技術，利用Eureka或者Consul等服務發現工具，通過輪詢、指定權重、IP位址哈希等機制實作下遊服務的負載均衡。
3. 統一鑒權： 一般而言，無論對内網還是外網的接口都需要做使用者身份認證，而使用者認證在一些規模較大的系統中都會采用統一的單點登入（Single Sign On）系統，如果每個微服務都要對接單點登入系統，那麼顯然比較浪費資源且開發效率低。API網關是統一管理安全性的絕佳場所，可以将認證的部分抽取到網關層，微服務系統無須關注認證的邏輯，隻關注自身業務即可。
4. 限流熔斷 ： 在某些場景下需要控制用戶端的通路次數和通路頻率，一些高并發系統有時還會有限流的需求。在網關上可以配置一個門檻值，當請求數超過門檻值時就直接傳回錯誤而不繼續通路背景服務。當出現流量洪峰或者後端服務出現延遲或故障時，網關能夠主動進行熔斷，保護後端服務，并保持前端使用者體驗良好。
5. 灰階釋出： 微服務網關可以根據HTTP請求中的特殊标記和後端服務清單中繼資料辨別進行流量控制，實作在使用者無感覺的情況下完成灰階釋出。
6. 日志審計： 微服務網關可以作為統一的日志記錄和收集器，對服務URL粒度的日志請求資訊和響應資訊進行攔截。
7. 名額監控： 網關可以統計後端服務的請求次數，并且可以實時地更新目前的流量健康狀态，可以對URL粒度的服務進行延遲統計，也可以使用Hystrix Dashboard檢視後端服務的流量狀态及是否有熔斷發生。
8. 協定轉換： API網關的一大作用在于建構異構系統，API網關作為單一入口，通過協定轉換整合背景基于REST、AMQP、Dubbo等不同風格和實作技術的微服務，面向Web Mobile、開放平台等特定用戶端提供統一服務。
9. 黑白名單： 微服務網關可以使用系統黑名單，過濾HTTP請求特征，攔截異常用戶端的請求，例如DDoS攻擊等侵蝕帶寬或資源迫使服務中斷等行為，可以在網關層面進行攔截過濾。比較常見的攔截政策是根據IP位址增加黑名單。在存在鑒權管理的路由服務中可以通過設定白名單跳過鑒權管理而直接通路後端服務資源。
10. 文檔中心： 網關結合Swagger，可以将後端的微服務暴露給網關，網關作為統一的入口給接口的使用方提供檢視後端服務的API規範，不需要知道每一個後端微服務的Swagger位址，這樣網關起到了對後端API聚合的效果。

目前主流的網關

• Spring Cloud Gateway：是springcloud的全新API網關項目，旨在替換zuul的網關服務，基于spring framework5.0+springboot 2.0+webFlux開發，其也實作了異步非阻塞的特性，有較高的性能，其有豐富的過濾器類型，可以根據自身需求來自定義過濾器。
• Zuul 2.0 : 采用Netty實作異步非阻塞程式設計模型，一個CPU一個線程，能夠處理所有的請求和響應，請求響應的生命周期通過事件和回調進行處理，減少線程數量，開銷較小。相比于zuul 1.0，zuul 2.0實作的異步非阻塞的特性，在性能上有較大提升。
• OpenResty : OpenResty基于 Nginx與 Lua 的高性能 Web 平台，其内部內建了大量精良的 Lua 庫、第三方子產品以及大多數的依賴項。用于友善地搭建能夠處理超高并發、擴充性極高的動态 Web 應用、Web 服務和動态網關。
• Kong : 基于OpenResty（Nginx + Lua子產品）編寫的高可用、易擴充的，性能高效且穩定，支援多個可用插件（限流、鑒權）等，開箱即可用，隻支援HTTP協定，且二次開發擴充難，缺乏更易用的管理和配置方式

網關之間的對比如下圖：

總結

總體而言，API Gateway 主要用于作為後端的 API 接口代理，提供對外通路不同種類 API 的一個單獨入口，并且可以提供獨立于後端服務的限流、認證、監控等功能。

在合理的架構設計下，一般都将 API Gateway 和 Load Balancer 配合使用，使用 Load Balancer 作為整個系統的網絡出入口，将流量分發到多個 API Gateway 執行個體，然後每個 API Gateway 執行個體分别對請求進行路由、認證、鑒權等操作，這樣可以使得整個網絡更加穩健、可靠、可擴充。

轉載：https://mp.weixin.qq.com/s/5wfDa4mNNFQN1X1p5YFSbg

本文使用 文章同步助手 同步