微服務架構必讀篇 - 網(wǎng)關
前言
由于互聯(lián)網(wǎng)的高速發(fā)展，網(wǎng)絡數(shù)據(jù)請求數(shù)激增，使得服務器承受的壓力越來越大。在早期的系統(tǒng)架構中，為減輕單臺服務器的壓力，通常使用 Load Balancer 來將網(wǎng)絡流量平攤到多個服務器中。如今后端服務的種類和數(shù)量在不斷變多，傳統(tǒng)的 Load Balancer 為主的系統(tǒng)架構的局限性就變得明顯起來，于是一款主要工作在七層且具有豐富擴展能力的基礎設施便應運而生，那便是 API Gateway。
什么是API網(wǎng)關
API網(wǎng)關 簡單來說是一種主要工作在七層、專門用于 API 的管理和流量轉(zhuǎn)發(fā)的基礎設施，并擁有強大的擴展性。
網(wǎng)關的角色是作為一個API架構，用來保護、增強和控制對于API服務的訪問。它是一個處于應用程序或服務（提供REST API接口服務）之前的系統(tǒng)，用來管理授權、訪問控制和流量限制等。這樣REST API接口服務就被網(wǎng)關保護起來，對所有的調(diào)用者透明。因此，隱藏在API網(wǎng)關后面的業(yè)務系統(tǒng)就可以專注于創(chuàng)建和管理服務，無需關心這些策略性的請求。
網(wǎng)關工作流程如下圖：
網(wǎng)關必須具備的特點
1.高性能
對于高性能而言，網(wǎng)關不應該也不能成為性能的瓶頸，最好使用高性能的編程語言來實現(xiàn)，如 C、C++、Go 和 Java。網(wǎng)關對后端的請求，以及對前端的請求的服務一定要使用異步非阻塞的 I/O 來確保后端延遲不會導致應用程序中出現(xiàn)性能問題。C 和 C++ 可以參看 Linux 下的 epoll 和 Windows 的 I/O Completion Port 的異步 IO 模型，Java 下如 Netty、Spring Reactor 的 NIO 框架。
2.高可用
所有的流量或調(diào)用都要經(jīng)過網(wǎng)關，所以網(wǎng)關必須成為一個高可用的組件，它的穩(wěn)定直接關系到了所有服務的穩(wěn)定。不能出現(xiàn)單點故障，因此，一個好的網(wǎng)關至少做到以下幾點。
集群化 。網(wǎng)關要成為一個集群，并可以自己同步集群數(shù)據(jù)，而不需要依賴于第三方系統(tǒng)來同步數(shù)據(jù)。
服務化 。網(wǎng)關還需要做到在不間斷的情況下修改配置，一種是像 Nginx reload 配置那樣，可以做到不停服務，另一種是最好做到服務化。也就是說，得要有自己的 Admin API 來在運行時修改配置。
持續(xù)化 。比如重啟，就是像 Nginx 那樣優(yōu)雅地重啟。有一個主管請求分發(fā)的主進程。當我們需要重啟時，新的請求被分配到新的進程中，而老的進程處理完正在處理的請求后就退出。
3.高擴展
網(wǎng)關要承接所有的業(yè)務流量和請求，所以一定存在或多或少的業(yè)務邏輯。而業(yè)務邏輯是多變和不確定的，比如，需要在網(wǎng)關上加入一些和業(yè)務相關的東西。因此一個好的網(wǎng)關還需要是可以擴展的，并能進行二次開發(fā)。當然，像 Nginx 那樣通過 Module 進行二次開發(fā)的也是可以的。
網(wǎng)關主要功能
路由功能： 路由是微服務網(wǎng)關的核心能力。通過路由功能微服務網(wǎng)關可以將請求轉(zhuǎn)發(fā)到目標微服務。在微服務架構中，網(wǎng)關可以結(jié)合注冊中心的動態(tài)服務發(fā)現(xiàn)，實現(xiàn)對后端服務的發(fā)現(xiàn)，調(diào)用方只需要知道網(wǎng)關對外暴露的服務API就可以透明地訪問后端微服務。
負載均衡： API網(wǎng)關結(jié)合負載均衡技術，利用Eureka或者Consul等服務發(fā)現(xiàn)工具，通過輪詢、指定權重、IP地址哈希等機制實現(xiàn)下游服務的負載均衡。
統(tǒng)一鑒權： 一般而言，無論對內(nèi)網(wǎng)還是外網(wǎng)的接口都需要做用戶身份認證，而用戶認證在一些規(guī)模較大的系統(tǒng)中都會采用統(tǒng)一的單點登錄（Single Sign On）系統(tǒng)，如果每個微服務都要對接單點登錄系統(tǒng)，那么顯然比較浪費資源且開發(fā)效率低。API網(wǎng)關是統(tǒng)一管理安全性的絕佳場所，可以將認證的部分抽取到網(wǎng)關層，微服務系統(tǒng)無須關注認證的邏輯，只關注自身業(yè)務即可。
限流熔斷 ： 在某些場景下需要控制客戶端的訪問次數(shù)和訪問頻率，一些高并發(fā)系統(tǒng)有時還會有限流的需求。在網(wǎng)關上可以配置一個閾值，當請求數(shù)超過閾值時就直接返回錯誤而不繼續(xù)訪問后臺服務。當出現(xiàn)流量洪峰或者后端服務出現(xiàn)延遲或故障時，網(wǎng)關能夠主動進行熔斷，保護后端服務，并保持前端用戶體驗良好。
灰度發(fā)布： 微服務網(wǎng)關可以根據(jù)HTTP請求中的特殊標記和后端服務列表元數(shù)據(jù)標識進行流量控制，實現(xiàn)在用戶無感知的情況下完成灰度發(fā)布。
日志審計： 微服務網(wǎng)關可以作為統(tǒng)一的日志記錄和收集器，對服務URL粒度的日志請求信息和響應信息進行攔截。
指標監(jiān)控： 網(wǎng)關可以統(tǒng)計后端服務的請求次數(shù)，并且可以實時地更新當前的流量健康狀態(tài)，可以對URL粒度的服務進行延遲統(tǒng)計，也可以使用Hystrix Dashboard查看后端服務的流量狀態(tài)及是否有熔斷發(fā)生。
協(xié)議轉(zhuǎn)換： API網(wǎng)關的一大作用在于構建異構系統(tǒng)，API網(wǎng)關作為單一入口，通過協(xié)議轉(zhuǎn)換整合后臺基于REST、AMQP、Dubbo等不同風格和實現(xiàn)技術的微服務，面向Web Mobile、開放平臺等特定客戶端提供統(tǒng)一服務。
黑白名單： 微服務網(wǎng)關可以使用系統(tǒng)黑名單，過濾HTTP請求特征，攔截異?？蛻舳说恼埱?，例如DDoS攻擊等侵蝕帶寬或資源迫使服務中斷等行為，可以在網(wǎng)關層面進行攔截過濾。比較常見的攔截策略是根據(jù)IP地址增加黑名單。在存在鑒權管理的路由服務中可以通過設置白名單跳過鑒權管理而直接訪問后端服務資源。
文檔中心： 網(wǎng)關結(jié)合Swagger，可以將后端的微服務暴露給網(wǎng)關，網(wǎng)關作為統(tǒng)一的入口給接口的使用方提供查看后端服務的API規(guī)范，不需要知道每一個后端微服務的Swagger地址，這樣網(wǎng)關起到了對后端API聚合的效果。
目前主流的網(wǎng)關
Spring Cloud Gateway：是springcloud的全新API網(wǎng)關項目，旨在替換zuul的網(wǎng)關服務，基于spring framework5.0+springboot 2.0+webFlux開發(fā)，其也實現(xiàn)了異步非阻塞的特性，有較高的性能，其有豐富的過濾器類型，可以根據(jù)自身需求來自定義過濾器。
Zuul 2.0 : 采用Netty實現(xiàn)異步非阻塞編程模型，一個CPU一個線程，能夠處理所有的請求和響應，請求響應的生命周期通過事件和回調(diào)進行處理，減少線程數(shù)量，開銷較小。相比于zuul 1.0，zuul 2.0實現(xiàn)的異步非阻塞的特性，在性能上有較大提升。
OpenResty : OpenResty基于 Nginx與 Lua 的高性能 Web 平臺，其內(nèi)部集成了大量精良的 Lua 庫、第三方模塊以及大多數(shù)的依賴項。用于方便地搭建能夠處理超高并發(fā)、擴展性極高的動態(tài) Web 應用、Web 服務和動態(tài)網(wǎng)關。
Kong : 基于OpenResty（Nginx + Lua模塊）編寫的高可用、易擴展的，性能高效且穩(wěn)定，支持多個可用插件（限流、鑒權）等，開箱即可用，只支持HTTP協(xié)議，且二次開發(fā)擴展難，缺乏更易用的管理和配置方式
網(wǎng)關之間的對比如下圖：
總結(jié)
總體而言，API Gateway 主要用于作為后端的 API 接口代理，提供對外訪問不同種類 API 的一個單獨入口，并且可以提供獨立于后端服務的限流、認證、監(jiān)控等功能。
在合理的架構設計下，一般都將 API Gateway 和 Load Balancer 配合使用，使用 Load Balancer 作為整個系統(tǒng)的網(wǎng)絡出入口，將流量分發(fā)到多個 API Gateway 實例，然后每個 API Gateway 實例分別對請求進行路由、認證、鑒權等操作，這樣可以使得整個網(wǎng)絡更加穩(wěn)健、可靠、可擴展。
轉(zhuǎn)載：https://mp.weixin.qq.com/s/5wfDa4mNNFQN1X1p5YFSbg
本文使用 文章同步助手 同步
本文使用 文章同步助手 同步
