前言
近來(lái)，在想著重構(gòu)一個(gè)新的產(chǎn)品。準(zhǔn)備采用微服務(wù)的技術(shù)解決方案，來(lái)搭建基礎(chǔ)設(shè)施框架。網(wǎng)關(guān)，是一個(gè)必不可少的組件。那么，網(wǎng)關(guān)到底是什么？
其又有什么特點(diǎn)或者特性，成為微服務(wù)必不可少的組件呢？今天，我們就來(lái)探討下這個(gè)問(wèn)題。希望通過(guò)本文，大家能夠明白，為何用。
演變過(guò)程
傳統(tǒng)的單體技術(shù)架構(gòu)，所有的內(nèi)容，被打包進(jìn)一個(gè)包內(nèi)。為了保證，系統(tǒng)的穩(wěn)定、安全，需要開(kāi)發(fā)一些過(guò)濾器、攔截器，來(lái)實(shí)現(xiàn)對(duì)客戶(hù)端請(qǐng)求的過(guò)濾與攔截，以及完成最終請(qǐng)求的轉(zhuǎn)發(fā)。如下圖所示
微服務(wù)技術(shù)解決方案下，同樣需要為每個(gè)服務(wù)開(kāi)發(fā)過(guò)濾器、攔截器來(lái)進(jìn)行請(qǐng)求管理。但由于服務(wù)數(shù)量眾多，同時(shí)，客戶(hù)端形式多樣化，如果在每個(gè)服務(wù)身上開(kāi)發(fā)，將會(huì)造成很大的代碼冗余與開(kāi)發(fā)負(fù)擔(dān)。因此，期待，將相同的一些功能，抽取到一個(gè)服務(wù)內(nèi)實(shí)現(xiàn)，這便成為了一個(gè)組件，就是現(xiàn)在的網(wǎng)關(guān)。
網(wǎng)關(guān)存在的原因：
解決微服務(wù)技術(shù)架構(gòu)下，請(qǐng)求管理功能
解決微服務(wù)技術(shù)架構(gòu)下，多客戶(hù)端的適配，采用單一入口，完成協(xié)議適配
網(wǎng)關(guān)的基本功能
微服務(wù)技術(shù)解決方案下的，網(wǎng)關(guān)，至少需要具備圖示基本功能。
網(wǎng)關(guān)作為單點(diǎn)入口，完成統(tǒng)一的請(qǐng)求管理
免去客戶(hù)端直接對(duì)接眾多微服務(wù)的復(fù)雜性，采用單點(diǎn)入口，實(shí)現(xiàn)路由轉(zhuǎn)發(fā)，從而實(shí)現(xiàn)服務(wù)調(diào)用
服務(wù)對(duì)于整個(gè)系統(tǒng)來(lái)講，是不穩(wěn)定的，那么網(wǎng)關(guān)，需要進(jìn)行限流熔斷，保持系統(tǒng)的穩(wěn)定與分區(qū)容錯(cuò)性
對(duì)于服務(wù)調(diào)用的鏈路，網(wǎng)關(guān)有職責(zé)進(jìn)行記錄，日志監(jiān)控，保證整個(gè)系統(tǒng)，在監(jiān)控下工作
系統(tǒng)可能不僅僅是由自有客戶(hù)端調(diào)用，很多時(shí)候，系統(tǒng)開(kāi)放能力API給外部，因此網(wǎng)關(guān)需要安全認(rèn)證，來(lái)保證安全
這些年來(lái)，API網(wǎng)關(guān)正在經(jīng)歷一些身份危機(jī)。
它們是否是集中的、共享的資源，從而促進(jìn)了API對(duì)外部實(shí)體的暴露與治理？
它們是集群入口（ingress）哨兵，從而可以嚴(yán)格控制哪些用戶(hù)流量進(jìn)入或離開(kāi)集群?jiǎn)幔?/p>
或者它們根據(jù)自己擁有的客戶(hù)端類(lèi)型，使用某種API結(jié)合膠水來(lái)更簡(jiǎn)潔地表達(dá)API？
當(dāng)然，房間里的大象和我經(jīng)常聽(tīng)到的一個(gè)問(wèn)題：“服務(wù)網(wǎng)格會(huì)使API網(wǎng)關(guān)過(guò)時(shí)嗎？
房間里的大象：英語(yǔ)習(xí)語(yǔ)，指的是一些雖然顯而易見(jiàn)，但卻由于可能造成尷尬、爭(zhēng)執(zhí)、觸及敏感或禁忌等原因被人刻意忽視的事情。
一些背景
隨著技術(shù)發(fā)展日新月異，整個(gè)行業(yè)通過(guò)技術(shù)和架構(gòu)模式進(jìn)行快速洗牌，如果你說(shuō)“所有這些都使我頭大”，也可以理解。在本文中，我希望總結(jié)出“ API網(wǎng)關(guān)”的不同身份，闡明公司中的哪些群體可以使用API網(wǎng)關(guān)（他們正在嘗試解決的問(wèn)題），并重新關(guān)注這些首要原則。理想情況下，在本文結(jié)束時(shí)，您將更好地了解API基礎(chǔ)架構(gòu)在不同層級(jí)、對(duì)不同團(tuán)隊(duì)的作用，同時(shí)明白如何從每個(gè)層級(jí)獲得最大價(jià)值。
在深入探討之前，讓我們先明確API一詞的含義。
我對(duì)API的定義：
一個(gè)明確定義和目的型接口，通過(guò)網(wǎng)絡(luò)調(diào)用，使軟件開(kāi)發(fā)人員能夠以受控且方便的方式，對(duì)組織內(nèi)的數(shù)據(jù)和功能進(jìn)行編程訪問(wèn)。
這些接口抽象了實(shí)現(xiàn)它們的技術(shù)架構(gòu)細(xì)節(jié)。對(duì)于這些設(shè)計(jì)的網(wǎng)絡(luò)端點(diǎn)，我們希望獲得一定程度的文檔、使用指南、穩(wěn)定性和向后兼容性。
相反，僅僅因?yàn)槲覀兛梢酝ㄟ^(guò)網(wǎng)絡(luò)與另一軟件進(jìn)行通信，并不一定意味著遠(yuǎn)程端點(diǎn)就是符合此定義的API。許多系統(tǒng)相互通信，但是通信發(fā)生更加隨意，并在與耦合和其他因素之間進(jìn)行權(quán)衡。
我們創(chuàng)建API來(lái)為業(yè)務(wù)的各個(gè)部分提供周全的抽象，以實(shí)現(xiàn)新的業(yè)務(wù)功能以及偶然的創(chuàng)新。
在談?wù)揂PI網(wǎng)關(guān)時(shí)，首先要提到的是API管理。
API管理
許多人從API管理的角度考慮API網(wǎng)關(guān)。這是公平的。但是，讓我們快速看一下此類(lèi)網(wǎng)關(guān)的功能。
通過(guò)API Management，我們?cè)噲D解決“何時(shí)公開(kāi)現(xiàn)有的API供他人使用”的問(wèn)題，如何跟蹤誰(shuí)使用這些API，實(shí)施關(guān)于允許誰(shuí)使用它們的政策，建立安全流程來(lái)進(jìn)行身份驗(yàn)證和授權(quán)許可，同時(shí)創(chuàng)建一個(gè)服務(wù)目錄（該目錄可在設(shè)計(jì)時(shí)使用以促進(jìn)API使用，并為有效治理奠定基礎(chǔ)）。
我們想解決“我們擁有要與他人共享，但要按我們的條款共享這些現(xiàn)有的、經(jīng)過(guò)精心設(shè)計(jì)的API ”的問(wèn)題。
API管理也做得很好，它允許用戶(hù)（潛在的API使用者）進(jìn)行自助服務(wù)，簽署不同的API使用計(jì)劃（請(qǐng)考慮：在給定時(shí)間范圍內(nèi)，在指定價(jià)格點(diǎn)上，每個(gè)端點(diǎn)每個(gè)用戶(hù)的調(diào)用次數(shù)）。有能力完成這些管理功能的基礎(chǔ)架構(gòu)就是網(wǎng)關(guān)（API流量所經(jīng)過(guò)的）。在網(wǎng)關(guān)層，我們可以執(zhí)行身份驗(yàn)證，速率限制，指標(biāo)收集，其它策略執(zhí)行等操作。
API Management Gateway
基于API網(wǎng)關(guān)的API管理軟件示例：
Google Cloud Apigee
Red Hat 3Scale
Mulesoft
Kong
在這個(gè)級(jí)別上，我們考慮的是API（如上定義）是如何最好地管理和允許對(duì)其進(jìn)行訪問(wèn)。我們不是在考慮服務(wù)器，主機(jī)、端口、容器甚至服務(wù)（另一個(gè)定義不明確的詞）。
API管理（以及它們相應(yīng)的網(wǎng)關(guān)）通常被作為由“平臺(tái)團(tuán)隊(duì)”、“集成團(tuán)隊(duì)”或其它API基礎(chǔ)架構(gòu)團(tuán)隊(duì)所擁有的、嚴(yán)格控制的共享基礎(chǔ)架構(gòu)。
需要注意的一件事：我們要小心，別讓任何業(yè)務(wù)邏輯進(jìn)入這一層。如前一段所述，API管理是共享的基礎(chǔ)結(jié)構(gòu)，但是由于我們的API流量經(jīng)過(guò)了它，因此它傾向于重新創(chuàng)建“大包大攬的全能型”（認(rèn)為是企業(yè)服務(wù)總線）網(wǎng)關(guān)，這會(huì)導(dǎo)致我們必須與之協(xié)調(diào)來(lái)更改我們的服務(wù)。從理論上講，這聽(tīng)起來(lái)不錯(cuò)。實(shí)際上，這最終可能成為組織的瓶頸。有關(guān)更多信息，請(qǐng)參見(jiàn)這篇文章：具有ESB，API管理和Now…Service Mesh的應(yīng)用程序網(wǎng)絡(luò)功能？
集群入口
為了構(gòu)建和實(shí)現(xiàn)API，我們將重點(diǎn)放在代碼、數(shù)據(jù)、生產(chǎn)力框架等方面。但是，要想使這些事情中的任何一個(gè)產(chǎn)生價(jià)值，就必須對(duì)其進(jìn)行測(cè)試，部署到生產(chǎn)中并進(jìn)行監(jiān)控。當(dāng)我們開(kāi)始部署到云原生平臺(tái)時(shí)，我們開(kāi)始考慮部署、容器、服務(wù)、主機(jī)、端口等，并構(gòu)建可在此環(huán)境中運(yùn)行的應(yīng)用程序。我們可能正在設(shè)計(jì)工作流（CI）和管道（CD），以利用云平臺(tái)快速遷移、更改、將其展示在客戶(hù)面前等等。
在這種環(huán)境中，我們可能會(huì)構(gòu)建和維護(hù)多個(gè)集群來(lái)承載我們的應(yīng)用程序，并且需要某種方式來(lái)訪問(wèn)這些群集中的應(yīng)用程序和服務(wù)。以Kubernetes為例思考。我們可能會(huì)通過(guò)Kubernetes Ingress來(lái)訪問(wèn)Kubernetes集群（集群中的其它所有內(nèi)容都無(wú)法從外部訪問(wèn)）。這樣，我們就可以通過(guò)定義明確的入口點(diǎn)（例如域/虛擬主機(jī)、端口、協(xié)議等），嚴(yán)格控制哪些流量可以進(jìn)入（甚至離開(kāi)）我們的集群。
在這個(gè)級(jí)別上，我們可能希望某種“ingress網(wǎng)關(guān)”成為允許請(qǐng)求和消息進(jìn)入群集的流量哨兵。在這個(gè)級(jí)別上，您的思考更多是“我的集群中有此服務(wù)，我需要集群外的人能夠調(diào)用它”。這可能是服務(wù)（公開(kāi)API）、現(xiàn)有的整體組件、gRPC服務(wù)，緩存、消息隊(duì)列、數(shù)據(jù)庫(kù)等。有些人選擇將其稱(chēng)為API網(wǎng)關(guān)，而且實(shí)際上可能會(huì)做比流量的入口/出口更多的事情，但重點(diǎn)是這個(gè)層級(jí)的問(wèn)題是屬于集群操作級(jí)別的。
Cluster Ingress Gateway
這些類(lèi)型的ingress實(shí)現(xiàn)的示例包括：Envoy Proxy 及其基礎(chǔ)上的項(xiàng)目包括：
Datawire Ambassador
Solo.io Gloo
Heptio Contour
基于其他反向代理/負(fù)載均衡器構(gòu)建的其它組件：
HAProxy
OpenShift’s Router (based on HAProxy)
NGINX
Traefik
Kong
此層級(jí)的集群入口控制器由平臺(tái)團(tuán)隊(duì)操作，但是，這部分基礎(chǔ)架構(gòu)通常與更加去中心化的、自助服務(wù)工作流相關(guān)聯(lián)（正如您對(duì)云原生平臺(tái)所期望的那樣）。參見(jiàn)The “GitOps” workflow as described by the good folks at Weaveworks
API網(wǎng)關(guān)模式
關(guān)于“ API網(wǎng)關(guān)”一詞的另一種擴(kuò)展是我在聽(tīng)到該術(shù)語(yǔ)時(shí)通常想到的，它是與API網(wǎng)關(guān)模式最相似的。Chris Richardson在其“微服務(wù)模式”一書(shū)第8章很好地介紹了這種用法。我強(qiáng)烈建議您將此書(shū)用于此模式和其他微服務(wù)模式學(xué)習(xí)資料。可在他的microservices.io網(wǎng)站API Gatway Pattern可以進(jìn)行快速瀏覽。簡(jiǎn)而言之，API網(wǎng)關(guān)模式是針對(duì)不同類(lèi)別的消費(fèi)者來(lái)優(yōu)化API的使用。這個(gè)優(yōu)化涉及一個(gè)API間接訪問(wèn)。您可能會(huì)聽(tīng)到另一個(gè)代表API網(wǎng)關(guān)模式的術(shù)語(yǔ)是“前端的后端”，其中“前端”可以是字符終端（UI）、移動(dòng)客戶(hù)端、IoT客戶(hù)端甚至其它服務(wù)/應(yīng)用程序開(kāi)發(fā)人員。
在API網(wǎng)關(guān)模式中，我們明顯簡(jiǎn)化了一組API的調(diào)用，以模擬針對(duì)特定用戶(hù)、客戶(hù)端或使用者的“應(yīng)用程序”內(nèi)聚API。回想一下，當(dāng)我們使用微服務(wù)構(gòu)建系統(tǒng)時(shí)，“應(yīng)用程序”的概念就消失了。API網(wǎng)關(guān)模式有助于恢復(fù)此概念。這里的關(guān)鍵是API網(wǎng)關(guān)，一旦實(shí)現(xiàn)，它將成為客戶(hù)端和應(yīng)用程序的API，并負(fù)責(zé)與任何后端API和其他應(yīng)用程序網(wǎng)絡(luò)端點(diǎn)（不滿(mǎn)足上述API定義的端點(diǎn)）進(jìn)行通信。
與上一節(jié)中的Ingress控制器不同，此API網(wǎng)關(guān)更接近開(kāi)發(fā)人員的視角，而較少關(guān)注哪些端口或服務(wù)暴露以供集群外使用的方面。此“ API網(wǎng)關(guān)”也不同于我們管理現(xiàn)有API的API管理視角。此API網(wǎng)關(guān)將對(duì)后端的調(diào)用聚合在一起，這可能會(huì)公開(kāi)API，但也可能是與API描述較少的東西，例如對(duì)舊系統(tǒng)的RPC調(diào)用，使用不符合“ REST”的協(xié)議的調(diào)用（如通過(guò)HTTP但不使用JSON），gRPC，SOAP，GraphQL、websockets和消息隊(duì)列。這種類(lèi)型的網(wǎng)關(guān)也可用來(lái)進(jìn)行消息級(jí)轉(zhuǎn)換、復(fù)雜的路由、網(wǎng)絡(luò)彈性/回退以及響應(yīng)的聚合。
如果您熟悉REST API的Richardson Maturity模型，就會(huì)發(fā)現(xiàn)相比Level 1–3，實(shí)現(xiàn)了API網(wǎng)關(guān)模式的API網(wǎng)關(guān)來(lái)集成了更多的Level 0請(qǐng)求（及其之間的所有內(nèi)容）。
https://martinfowler.com/articles/richardsonMaturityModel.html
這些類(lèi)型的網(wǎng)關(guān)實(shí)現(xiàn)仍需要解決速率限制、身份驗(yàn)證/授權(quán)、斷路、度量收集、流量路由等問(wèn)題。這些類(lèi)型的網(wǎng)關(guān)可以在集群邊緣用作集群入口控制器，也可以在集群內(nèi)部用作應(yīng)用程序網(wǎng)關(guān)。
API Gateway Pattern
此類(lèi)API網(wǎng)關(guān)的示例包括：
Spring Cloud Gateway
Solo.io Gloo
Netflix Zuul
IBM-Strongloop Loopback/Microgateway
也可以使用更通用的編程或集成語(yǔ)言/框架（例如：
Apache Camel
Spring Integration
Ballerina.io
Eclipse Vert.x
NodeJS
由于這種類(lèi)型的API網(wǎng)關(guān)與應(yīng)用和服務(wù)的開(kāi)發(fā)緊密相關(guān)，因此我們希望開(kāi)發(fā)人員能夠參與幫助指定API網(wǎng)關(guān)公開(kāi)的API，了解所涉及的任何聚合邏輯以及快速測(cè)試和更改此API基礎(chǔ)架構(gòu)的能力。我們還希望運(yùn)維人員或SRE對(duì)API網(wǎng)關(guān)的安全性、彈性和可觀察性配置有一些意見(jiàn)。這種層級(jí)的基礎(chǔ)架構(gòu)還必須適應(yīng)不斷發(fā)展的、按需的、自助服務(wù)開(kāi)發(fā)人員工作流?？梢酝ㄟ^(guò)查看GitOps模型獲取更多這方面信息。
進(jìn)入服務(wù)網(wǎng)格(Service Mesh)
在云基礎(chǔ)架構(gòu)上運(yùn)行服務(wù)架構(gòu)的一部分難點(diǎn)是，如何在網(wǎng)絡(luò)中構(gòu)建正確級(jí)別的可觀察性和控制。在解決此問(wèn)題的先前迭代中，我們使用了應(yīng)用程序庫(kù)和希望的開(kāi)發(fā)人員治理來(lái)實(shí)現(xiàn)此目的。但是，在大規(guī)模和多種開(kāi)發(fā)語(yǔ)言環(huán)境下，服務(wù)網(wǎng)格技術(shù)的出現(xiàn)提供了更好的解決方案。服務(wù)網(wǎng)格通過(guò)透明地實(shí)現(xiàn)為平臺(tái)及其組成服務(wù)帶來(lái)以下功能：
服務(wù)到服務(wù)（即東西向流量）的彈性
安全性包括最終用戶(hù)身份驗(yàn)證、相互TLS、服務(wù)到服務(wù)RBAC / ABAC
黑盒服務(wù)的可觀察性（專(zhuān)注于網(wǎng)絡(luò)通信），例如請(qǐng)求/秒、請(qǐng)求延遲、請(qǐng)求失敗、熔斷事件、分布式跟蹤等
服務(wù)到服務(wù)速率限制，配額執(zhí)行等
精明的讀者會(huì)認(rèn)識(shí)到，API網(wǎng)關(guān)和服務(wù)網(wǎng)格在功能上似乎有所重疊。服務(wù)網(wǎng)格的目的是通過(guò)在L7透明地解決所有服務(wù)/應(yīng)用程序的這些問(wèn)題。換句話說(shuō)，服務(wù)網(wǎng)格希望融合到服務(wù)中（實(shí)際上它的代碼并沒(méi)有嵌入到服務(wù)中）。另一方面，API網(wǎng)關(guān)位于服務(wù)網(wǎng)格以及應(yīng)用程序之上（L8？）。服務(wù)網(wǎng)格為服務(wù)、主機(jī)、端口、協(xié)議等（東西向流量）之間的請(qǐng)求流帶來(lái)了價(jià)值。它們還可以提供基本的集群入口功能，以將某些此功能引入南北向。但是，這不應(yīng)與API網(wǎng)關(guān)可以帶來(lái)北/南流量的功能相混淆。（一個(gè)在集群的南北向和一個(gè)是在一組應(yīng)用程序的南北向）
Service Mesh和API網(wǎng)關(guān)在某些方面在功能上重疊，但是在它們?cè)诓煌瑢用婊パa(bǔ)，分別負(fù)責(zé)解決不同的問(wèn)題。理想的解決方案是將每個(gè)組件（API管理、API網(wǎng)關(guān)、服務(wù)網(wǎng)格）合適的安置到您的解決方案中，并根據(jù)需要在各組件間建立良好的邊界（或在不需要時(shí)排除它們）。同樣重要的是找到適合去中心化開(kāi)發(fā)人員和運(yùn)營(yíng)工作流程的這些工具實(shí)現(xiàn)。即使這些不同組件的術(shù)語(yǔ)和標(biāo)識(shí)存在混淆，我們也應(yīng)該依靠基本原理，并了解這些組件在我們的體系結(jié)構(gòu)中帶來(lái)的價(jià)值，從而來(lái)確定它們?nèi)绾为?dú)立存在和互補(bǔ)并存。
微服務(wù)不能沒(méi)有網(wǎng)關(guān)，就如同 Java 程序員不能沒(méi)有IDEA、Eclipse。為什么呢？
之所以網(wǎng)關(guān)對(duì)微服務(wù)這么重要，主要有以下幾點(diǎn)原因：
1. 解決 API 放哪里的問(wèn)題
要知道，采用微服務(wù)架構(gòu)的系統(tǒng)本身是由很多的獨(dú)立服務(wù)單元組合起來(lái)的。而客戶(hù)端要調(diào)用系統(tǒng)，則必須通過(guò)系統(tǒng)提供的各種對(duì)外開(kāi)放的 API 來(lái)實(shí)現(xiàn)。
問(wèn)題來(lái)了，這些 API 要放在哪里呢？直接放在組成系統(tǒng)的服務(wù)單元上行不行？
比如，在一套電商系統(tǒng)上，關(guān)于訂單相關(guān)的 API ，放在組成訂單服務(wù)的服務(wù)單元上；風(fēng)控服務(wù)的 API ，放在組成風(fēng)控服務(wù)的服務(wù)單元上。
好，咱們假設(shè)有這么一個(gè)場(chǎng)景，有一位用戶(hù)想在這套電商系統(tǒng)上查看下商品詳情。那么，這個(gè)查看商品詳情的操作，就可能：
調(diào)用商品服務(wù)的 API 獲取商品描述
調(diào)用評(píng)價(jià)服務(wù)的 API 獲取相關(guān)評(píng)價(jià)
調(diào)用商家服務(wù)的 API 獲取商家信息
調(diào)用禮券服務(wù)的 API 獲取相關(guān)禮券
……
可以看到，就這么一個(gè)商品查看操作，就可能會(huì)調(diào)用許多服務(wù)的 API。
那這些 API 如果全部分散到各個(gè)服務(wù)單元上，供客戶(hù)端調(diào)用，像查看商品這么簡(jiǎn)單的一次操作，客戶(hù)端就可能需要遠(yuǎn)程訪問(wèn)好幾次甚至十幾次服務(wù)器。
微服務(wù)自己又講究把 API 的粒度劃分的很細(xì)，也就是說(shuō)，可能從商品服務(wù)上調(diào)用商品信息，不止是調(diào)用一次商品服務(wù)就夠了，很可能需要多次對(duì)商品服務(wù)的不同 API 進(jìn)行調(diào)用，才能獲取到足夠的數(shù)據(jù)。
這樣一來(lái)，客戶(hù)端需要訪問(wèn)服務(wù)器的次數(shù)就更多了，可能十幾次都不夠，得幾十次。
這種多次訪問(wèn)服務(wù)器的行為，會(huì)極大延遲客戶(hù)端的界面響應(yīng)時(shí)間，很不現(xiàn)實(shí)。
所以，把 API 放到各個(gè)業(yè)務(wù)相關(guān)的服務(wù)單元上，看上去問(wèn)題很大。
那為什么引入網(wǎng)關(guān)就能解決這個(gè)問(wèn)題呢？
因?yàn)橐刖W(wǎng)關(guān)，就相當(dāng)于在客戶(hù)端和微服務(wù)之間加了一層隔離。通常，網(wǎng)關(guān)本身會(huì)和各個(gè)服務(wù)單元處于同一個(gè)機(jī)房，這樣，客戶(hù)端做業(yè)務(wù)操作的時(shí)候，只需要訪問(wèn)一次網(wǎng)關(guān)。然后剩下的事情，再由網(wǎng)關(guān)分別訪問(wèn)同在一個(gè)機(jī)房的不同的服務(wù)，再把拿到的數(shù)據(jù)統(tǒng)一在網(wǎng)關(guān)封裝好，返回給客戶(hù)端就好。
2. 解決邊緣功能集成的問(wèn)題
在一套微服務(wù)組成的系統(tǒng)里，除了必須的業(yè)務(wù)功能以外，還有為了系統(tǒng)自身的健壯與安全，以及微服務(wù)本身的管理，而必須引入的一些非業(yè)務(wù)功能。對(duì)于這些非業(yè)務(wù)又很重要的功能，我們統(tǒng)稱(chēng)為邊緣功能。
還是拿電商系統(tǒng)為例，我們來(lái)看一些重要的邊緣功能。
假設(shè)因?yàn)槲覀冏隽艘淮畏浅４蟮拇黉N(xiāo)活動(dòng)，導(dǎo)致流量過(guò)大，系統(tǒng)承載不了了。此時(shí)，為了保證系統(tǒng)本身的穩(wěn)定，我們就需要把一些承載不了的流量給通過(guò)各種手段消化掉，一般的做法有三種：
限流：通過(guò)令牌桶等算法，把一些額外的流量擋在系統(tǒng)外面，不讓其訪問(wèn)。
降級(jí)：由于系統(tǒng)可能已經(jīng)過(guò)載了，此時(shí)，我們就放棄處理一些服務(wù)和頁(yè)面的請(qǐng)求或者僅簡(jiǎn)單處理，比如直接返回一個(gè)報(bào)錯(cuò)。
熔斷：有些時(shí)候，系統(tǒng)過(guò)載過(guò)度或者上線出了 bug，降級(jí)都解決不了問(wèn)題。比如，緩存失效了，導(dǎo)致大量請(qǐng)求頻繁訪問(wèn)了數(shù)據(jù)庫(kù)，而這種頻繁訪問(wèn)數(shù)據(jù)庫(kù)可能造成了大量的 IO 操作，結(jié)果又去影響了數(shù)據(jù)庫(kù)所在的操作系統(tǒng)，同時(shí)，這個(gè)操作系統(tǒng)上又有著別的重要服務(wù)，直接也被影響了。對(duì)于這種連鎖反應(yīng)，我們稱(chēng)之為雪崩。而為了防止雪崩，我們就會(huì)堅(jiān)決把緩存失效導(dǎo)致數(shù)據(jù)庫(kù)被頻繁訪問(wèn)的服務(wù)給停掉，這就是熔斷。
可以看到，像限流、降級(jí)、熔斷這些系統(tǒng)保障策略，最合適的地方應(yīng)該是有一個(gè)集中的請(qǐng)求入口點(diǎn)，就像古時(shí)候，老百姓進(jìn)城需要過(guò)城門(mén)那樣。
當(dāng)系統(tǒng)出現(xiàn)問(wèn)題的時(shí)候，直接就在這個(gè)入口點(diǎn)做相應(yīng)的操作即可。
限流，就直接在這個(gè)入口點(diǎn)限制后續(xù)請(qǐng)求。
降級(jí)，就直接在這個(gè)入口點(diǎn)判斷請(qǐng)求想要訪問(wèn)的服務(wù)或者頁(yè)面，直接報(bào)錯(cuò)返回。
熔斷，就直接在這個(gè)入口點(diǎn)，斷開(kāi)所有訪問(wèn)特定服務(wù)的請(qǐng)求連接，然后再把后繼對(duì)特定服務(wù)的訪問(wèn)，也統(tǒng)統(tǒng)攔在門(mén)外。
在電商系統(tǒng)里，有很多特殊場(chǎng)景的接口，需要受到嚴(yán)格的限制。
比如，支付接口，訪問(wèn)它就需要認(rèn)證和權(quán)限控制。又比如，對(duì)于系統(tǒng)的訪問(wèn)，有時(shí)候不能讓國(guó)外的去訪問(wèn)國(guó)內(nèi)的網(wǎng)站，這就需要限制客戶(hù)端的訪問(wèn) IP，所以系統(tǒng)還需要認(rèn)證和授權(quán)功能。
那這種認(rèn)證和授權(quán)也最合適放在請(qǐng)求的一個(gè)集中入口點(diǎn)，統(tǒng)一實(shí)現(xiàn)。
還記得上面咱們說(shuō)過(guò)的網(wǎng)關(guān)的 API 統(tǒng)一存放嗎？我們只需要對(duì)這些 API 做對(duì)應(yīng)的權(quán)限設(shè)置，當(dāng)請(qǐng)求訪問(wèn)特殊場(chǎng)景接口的時(shí)候，必定會(huì)通過(guò) API 訪問(wèn)。所以，限制接口的訪問(wèn)，本質(zhì)上就是對(duì)特定 API 的限制，那么，放在網(wǎng)關(guān)再合適不過(guò)了。
現(xiàn)實(shí)里，我們有時(shí)候需要把線上的流量鏡像出來(lái)，轉(zhuǎn)發(fā)到灰度環(huán)境，利用這些鏡像出來(lái)的流量既可以用于小范圍測(cè)試，又可以更好的評(píng)估系統(tǒng)所能承載的最大吞吐量，也因此，系統(tǒng)需要有一個(gè)統(tǒng)一入口做分流。
可以看到，無(wú)論是系統(tǒng)需要的保障策略，認(rèn)證授權(quán)，還是流量分流等功能，都應(yīng)該放到一個(gè)統(tǒng)一的請(qǐng)求入口處才能得到最好的實(shí)現(xiàn)。網(wǎng)關(guān)恰好就承擔(dān)了這么個(gè)統(tǒng)一請(qǐng)求入口的角色。
所以，對(duì)于微服務(wù)中，林林總總的邊緣功能，往往會(huì)通過(guò)插件的形式，集成在 API 網(wǎng)關(guān)中。
3. 解耦了客戶(hù)端和后端微服務(wù)
一套項(xiàng)目，在使用微服務(wù)模式的初期，往往后端變化是十分頻繁的。
頻繁變化的原因有很多，像業(yè)務(wù)領(lǐng)域劃分不合適啊，像某個(gè)業(yè)務(wù)模塊急速膨脹啊，都可能導(dǎo)致后端微服務(wù)的劇烈變化。
在這種情況下，如果沒(méi)有網(wǎng)關(guān)，很可能就會(huì)出現(xiàn)客戶(hù)端需要被迫隨著后端的變化而變化的情況。
比如，在電商系統(tǒng)里，初期我們很可能會(huì)把風(fēng)控服務(wù)做的非常小。隨著業(yè)務(wù)的發(fā)展，風(fēng)控服務(wù)越來(lái)越龐大，此時(shí)，風(fēng)控服務(wù)就可能被分解為決策引擎和分析中心等更多更細(xì)的服務(wù)。
在電商里，風(fēng)控往往是下單、支付等操作的必要前置操作。如果沒(méi)有網(wǎng)關(guān)去分隔開(kāi)客戶(hù)端和微服務(wù)，客戶(hù)端直接和風(fēng)控服務(wù)打交道，那么風(fēng)控服務(wù)拆分，API 必然不會(huì)穩(wěn)定，API 的變化，自然會(huì)引發(fā)調(diào)用 API 客戶(hù)端代碼的變化。
有了網(wǎng)關(guān)之后，情況就好了很多了。當(dāng)風(fēng)控服務(wù)本身頻繁變化的時(shí)候，我們只需要改動(dòng)網(wǎng)關(guān)的代碼就好。而服務(wù)器代碼的升級(jí)可是遠(yuǎn)遠(yuǎn)要比客戶(hù)端代碼的升級(jí)容易太多了。
參考鏈接：https://juejin.cn/post/6918211351257022471
為什么微服務(wù)一定要有API網(wǎng)關(guān)？
jianshu.com/p/9fab0982c6bb
微信公眾號(hào)【程序員黃小斜】作者是前螞蟻金服Java工程師，專(zhuān)注分享Java技術(shù)干貨和求職成長(zhǎng)心得，不限于BAT面試，算法、計(jì)算機(jī)基礎(chǔ)、數(shù)據(jù)庫(kù)、分布式、spring全家桶、微服務(wù)、高并發(fā)、JVM、Docker容器，ELK、大數(shù)據(jù)等。關(guān)注后回復(fù)【book】領(lǐng)取精選20本Java面試必備精品電子書(shū)。
