微服務(wù)“大門”如何選擇？

時(shí)間：2021-02-24 22:00:04

關(guān)鍵字：微服務(wù) 網(wǎng)關(guān) Nginx

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]使用微服務(wù)網(wǎng)關(guān)作為微服務(wù)面向客戶端的單一入口，是目前普遍采用的微服務(wù)架構(gòu)模式。

使用微服務(wù)網(wǎng)關(guān)作為微服務(wù)面向客戶端的單一入口，是目前普遍采用的微服務(wù)架構(gòu)模式。企業(yè)組織通過(guò)良好定義的 API 將內(nèi)部系統(tǒng)向內(nèi)部和外部用戶公開(kāi)，通常都會(huì)采用 API （微服務(wù)）網(wǎng)關(guān)來(lái)處理橫向的關(guān)注點(diǎn)，包括訪問(wèn)控制、速率限制、負(fù)載均衡等等，來(lái)實(shí)現(xiàn)安全可控的 API 開(kāi)放。廣泛實(shí)踐的微服務(wù)架構(gòu)中，似乎有很多產(chǎn)品具有這些能力，那如何更好的根據(jù)我們的業(yè)務(wù)場(chǎng)景選擇最合適自己的“大門”呢？

性能選擇-Nginx

Nginx 應(yīng)該是 Web 應(yīng)用的標(biāo)配組件，使用場(chǎng)景包括負(fù)載均衡、反向代理、代理緩存等。Nginx 的內(nèi)核的設(shè)計(jì)非常微小和簡(jiǎn)潔，實(shí)現(xiàn)的功能也相對(duì)簡(jiǎn)單，僅僅通過(guò)查找配置文件與請(qǐng)求進(jìn)行 URL 匹配，用于啟動(dòng)不同的模塊去完成相應(yīng)的工作。
Nginx 在啟動(dòng)后，會(huì)有一個(gè) Master 進(jìn)程和多個(gè) Worker 進(jìn)程，Master 進(jìn)程和 Worker 進(jìn)程之間是通過(guò)進(jìn)程間通信進(jìn)行交互的。Worker 工作進(jìn)程的阻塞點(diǎn)是在像 select()、epoll_wait() 等這樣的 I/O 多路復(fù)用函數(shù)調(diào)用處，以等待發(fā)生數(shù)據(jù)可讀 / 寫(xiě)事件。Nginx 采用了異步非阻塞的方式來(lái)處理請(qǐng)求，是可以同時(shí)處理成千上萬(wàn)個(gè)請(qǐng)求的。

服務(wù)親和-Zuul & Sping Cloud Gateway

Zuul 是 Netflix 開(kāi)源的微服務(wù)網(wǎng)關(guān)組件，其可以配合 Eureka、Nacos 等開(kāi)源產(chǎn)品實(shí)現(xiàn)不錯(cuò)的服務(wù)發(fā)現(xiàn)能力，同時(shí)集成Ribbon、Hystrix 或 Sentinel 等組件實(shí)現(xiàn)對(duì)整個(gè)鏈路的流控。
Zuul 的核心是一系列的過(guò)濾器，這些過(guò)濾器許多功能，例如：
? 鑒權(quán)與訪問(wèn)控制： 識(shí)別每次請(qǐng)求的合法性，并拒絕那些沒(méi)有在授權(quán)列表中的來(lái)源請(qǐng)求。
? 審計(jì)與監(jiān)控：記錄每次請(qǐng)求/響應(yīng)的內(nèi)容，以及 RT/錯(cuò)誤率等，從而分析出 API 的動(dòng)態(tài)質(zhì)量、安全情況。
? 動(dòng)態(tài)路由負(fù)載：動(dòng)態(tài)地將請(qǐng)求路由分流到不同的服務(wù)、應(yīng)用或者集群。
? 統(tǒng)一上下文：在請(qǐng)求轉(zhuǎn)發(fā)前根據(jù)業(yè)務(wù)需求設(shè)置公共的上下文信息向后傳遞。
? Mock 響應(yīng)：針對(duì)簡(jiǎn)單請(qǐng)求可以組合配置中心，直接在網(wǎng)關(guān)層直接響應(yīng)，從而避免其轉(zhuǎn)發(fā)到內(nèi)部。
上面提及的這些特性是 Nginx 所沒(méi)有的，Netflix 公司研發(fā) Zuul 是為了解決微服務(wù)場(chǎng)景的諸多問(wèn)題，而不僅僅是做一個(gè)類似于 nginx 的反向代理。
Spring Cloud Gateway 是 Spring Cloud 的一個(gè)全新項(xiàng)目，該項(xiàng)目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技術(shù)開(kāi)發(fā)的網(wǎng)關(guān)，它旨在為微服務(wù)架構(gòu)提供一種簡(jiǎn)單有效的統(tǒng)一的 API 路由管理方式。
Spring Cloud Gateway 作為 Spring Cloud 生態(tài)系統(tǒng)中的網(wǎng)關(guān)，目標(biāo)是替代 Zuul，在Spring Cloud 2.0 以上版本中，沒(méi)有對(duì)新版本的 Zuul 2.0 以上最新高性能版本進(jìn)行集成，仍然還是使用的 Zuul 2.0 之前的非 Reactor 模式的老版本。而為了提升網(wǎng)關(guān)的性能，SpringCloud Gateway 是基于 WebFlux 框架實(shí)現(xiàn)的，而 WebFlux 框架底層則使用了高性能的 Reactor 模式通信框架 Netty。
Spring Cloud Gateway 的目標(biāo)，不僅提供統(tǒng)一的路由方式，并且基于 Filter 鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：安全，監(jiān)控/指標(biāo)，和限流。

兩者兼得-Kong

Kong 是一款基于 Nginx_Lua 模塊寫(xiě)的高可用服務(wù)網(wǎng)關(guān)，由于 Kong 是基于 Nginx 的，所以可以水平擴(kuò)展多個(gè) Kong 服務(wù)器。通過(guò)前置的負(fù)載均衡配置把請(qǐng)求均勻地分發(fā)到各個(gè) Server，來(lái)應(yīng)對(duì)大批量的網(wǎng)絡(luò)請(qǐng)求。
Kong 主要有三個(gè)組件：
? Kong Server：基于 nginx 的服務(wù)器，用來(lái)接收 API 請(qǐng)求。
? Apache Cassandra/PostgreSQL：用來(lái)存儲(chǔ)操作數(shù)據(jù)。
? Kong dashboard：官方推薦 UI 管理工具，當(dāng)然，也可以使用 restfull 方式管理 admin api。
Kong 采用插件機(jī)制進(jìn)行功能定制，插件集（可以是 0 或 N 個(gè)）在 API 請(qǐng)求響應(yīng)循環(huán)的生命周期中被執(zhí)行。插件使用 Lua 編寫(xiě)，基礎(chǔ)功能包括：HTTP 基本認(rèn)證、密鑰認(rèn)證、CORS（Cross-Origin Resource Sharing，跨域資源共享）、TCP、UDP、文件日志、API 請(qǐng)求限流、請(qǐng)求轉(zhuǎn)發(fā)以及 Nginx 監(jiān)控等。
Kong 網(wǎng)關(guān)具有以下的特性：
? 可擴(kuò)展性：通過(guò)簡(jiǎn)單地添加更多的服務(wù)器，可以輕松地進(jìn)行橫向擴(kuò)展，這相較于 nginx 能讓你省心不少，但可能相對(duì)于 Zuul 稍稍弱些；
? 模塊化：可以通過(guò)添加新的插件進(jìn)行擴(kuò)展，這些插件可以通過(guò) RESTful Admin API 輕松配置；
? 在任何基礎(chǔ)架構(gòu)上運(yùn)行：Kong 網(wǎng)關(guān)可以在任何地方都能運(yùn)行，可以在云或內(nèi)部網(wǎng)絡(luò)環(huán)境中部署 Kong。

自建 OR 云產(chǎn)品

但是！有過(guò)使用經(jīng)驗(yàn)的同學(xué)應(yīng)該會(huì)發(fā)現(xiàn)，真正用起來(lái)我們還需要更多的服務(wù)發(fā)現(xiàn)能力、更全面的監(jiān)控可觀測(cè)能力、更高的穩(wěn)定性保障，那么到底是自己手工打造還是購(gòu)買成本更合適呢？我們先來(lái)看下自建和云產(chǎn)品的比較：

自建 VS 托管云產(chǎn)品

能力	自建	托管
彈性擴(kuò)縮容	需要自建維護(hù)K8s	產(chǎn)品控制臺(tái)直接操作
多種開(kāi)發(fā)語(yǔ)言	Kong 使用 Lua 來(lái)擴(kuò)展（可能還需要掌握 nginx ），Zuul 用 Java 實(shí)現(xiàn)	全都要，不用關(guān)注
服務(wù)發(fā)現(xiàn)	Kong 不支持，Zuul 支持部分需要開(kāi)發(fā)	支持 Eureka、Nacos 等
監(jiān)控大盤	需要一個(gè)團(tuán)隊(duì)支持，且要二次開(kāi)發(fā)	控制臺(tái)一鍵創(chuàng)建
協(xié)議轉(zhuǎn)換	需要服務(wù)框架團(tuán)隊(duì)開(kāi)發(fā)	支持 Http、Dubbo 等
微服務(wù)治理	需要中間件團(tuán)隊(duì)支持	集成 MSE 支持無(wú)損上下線、金絲雀發(fā)布、標(biāo)簽路由、離群實(shí)例摘除等

對(duì)比可以看到，這些能力使用托管的 MSE 微服務(wù)網(wǎng)關(guān)就相當(dāng)于省去了一個(gè)運(yùn)維團(tuán)隊(duì)、一個(gè)中間件團(tuán)隊(duì)、一個(gè)多語(yǔ)言開(kāi)發(fā)能力的研發(fā)團(tuán)隊(duì)?，F(xiàn)在，您只要結(jié)合自己的業(yè)務(wù)場(chǎng)景選擇合適的引擎即可：

接入層場(chǎng)景選擇 Kong，性能高 SSL 安全能力匹配；

業(yè)務(wù)分支選擇 Zuul，自定義擴(kuò)展方便還有很強(qiáng)的服務(wù)發(fā)現(xiàn)能力；

或者如果你是 Spring Cloud 技術(shù)體系，那么趕緊把 Spring Cloud Gateway 加入你的全家桶吧。

云產(chǎn)品的各引擎對(duì)比

更多內(nèi)容了解： https://www.aliyun.com/product/aliware/mse

總結(jié)

微服務(wù)網(wǎng)關(guān)作為微服務(wù)流量的“大門”，它的穩(wěn)定性、安全性、功能完備性上的要求是要遠(yuǎn)遠(yuǎn)高于我們業(yè)務(wù)自身的，我們往往需要投入非常大的人力和時(shí)間在他的運(yùn)維和開(kāi)發(fā)上，并還未必能保證有非常好的效果；BaaS 化的服務(wù)型（全托管）云產(chǎn)品，幫助我們的用戶堅(jiān)持開(kāi)源技術(shù)棧這一大方向不變的基礎(chǔ)上，更穩(wěn)定、更便捷、更專注的為我們業(yè)務(wù)保駕護(hù)航。

免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場(chǎng)，如有問(wèn)題，請(qǐng)聯(lián)系我們，謝謝！