国际完美世界下载,古风名字,兽性总裁的爱奴

作者程小蘭，API7.ai 技術工程師，Apache APISIX Contributor。

什么是微服務

微服務架構（通常簡稱為微服務）是指開發(fā)應用所用的一種架構形式。通過微服務，可將大型應用分解成多個獨立的組件，其中每個組件都有各自的責任領域。

在處理一個用戶請求時，基于微服務的應用可能會調(diào)用許多內(nèi)部微服務來共同生成其響應。微服務是互聯(lián)網(wǎng)業(yè)務發(fā)展的結果，互聯(lián)網(wǎng)業(yè)務的飛速發(fā)展導致系統(tǒng)的架構也在不斷地發(fā)生變化，總體來說，系統(tǒng)的架構大致經(jīng)歷了：單體應用架構—> SOA 架構—>微服務架構的演變，具體發(fā)展歷程和各自的優(yōu)缺點如下表所示。

架構類型	簡介	優(yōu)點	缺點
單體應用架構	將所有的功能代碼打包成一個服務。	1. 架構簡單，項目開發(fā)和維護成本低。	所有模塊耦合在一起，比較有利于小型項目的開發(fā)和維護；但是，對于大型項目來說卻存在問題，比如： 1. 項目各模塊之間過于耦合，一個模塊的性能問題可能導致整個項目的不可用； 2. 項目的擴展性差。
SOA 架構	中文意思為 “面向服務的架構”，通常包含多個服務，一個服務通常以獨立的形式存在于操作系統(tǒng)進程中，服務之間通過相互依賴或者通過通信機制來完成通信的，最終提供一系列的功能。	1. 系統(tǒng)集成：站在系統(tǒng)的角度，解決企業(yè)系統(tǒng)間的通信問題，把原先散亂、無規(guī)劃的系統(tǒng)間的網(wǎng)狀結構，梳理成規(guī)整、可治理的系統(tǒng)間星形結構； 2. 系統(tǒng)的服務化：站在功能的角度，把業(yè)務邏輯抽象成可復用、可組裝的服務，通過服務的編排實現(xiàn)業(yè)務的快速再 3. 業(yè)務的服務化：站在企業(yè)的角度，把企業(yè)職能抽象成可復用、可組裝的服務。	1. 服務的中心化，各服務之間存在依賴關系，如果某個服務出現(xiàn)故障可能會造成服務的雪崩； 2. 服務之間的依賴與調(diào)用關系復雜，測試部署的困難比較大。
微服務架構	微服務是在 SOA 上做的升華。微服務架構重點強調(diào)的一個是"業(yè)務需要徹底的組件化和服務化"，原有的單個業(yè)務系統(tǒng)會拆分為多個可以獨立開發(fā)、設計、運行的小應用。各個小應用之間，相互去協(xié)作通信，來完成一個交互和集成，這就是微服務架構。	1. 去中心化； 2. 通過服務實現(xiàn)組件化； 3. 按業(yè)務能力來劃分服務和開發(fā)團隊； 4. 基礎設施自動化（Devops、自動化部署）。	1. 開發(fā)的成本比較高； 2. 會引發(fā)服務的容錯性問題； 3. 會引發(fā)數(shù)據(jù)的一致性問題； 4. 會涉及分布式事務。

因此，微服務是互聯(lián)網(wǎng)發(fā)展的必然結果，很多傳統(tǒng)公司的系統(tǒng)架構也在逐步微服務化。但是，隨著互聯(lián)網(wǎng)業(yè)務的發(fā)展，API 的數(shù)量也在劇增，使用網(wǎng)關對API統(tǒng)一管理也將面臨挑戰(zhàn)，選擇一個更強大的 API 網(wǎng)關，可以有效地增強系統(tǒng)的監(jiān)控、容災、鑒權和限流等能力。

什么是 API 網(wǎng)關

API 網(wǎng)關為客戶與服務系統(tǒng)之間的交互提供了統(tǒng)一的接口，也是管理請求和響應的中心點，選擇一個適合的 API 網(wǎng)關，可以有效地簡化開發(fā)并提高系統(tǒng)的運維與管理效率。API 網(wǎng)關在微服務架構中是系統(tǒng)設計的一個解決方案，用來整合各個不同模塊的微服務，統(tǒng)一協(xié)調(diào)服務。

API 網(wǎng)關作為一個系統(tǒng)訪問的切面，對外提供統(tǒng)一的入口供客戶端訪問，隱藏系統(tǒng)架構實現(xiàn)的細節(jié)，讓微服務使用更為友好；并集成了一些通用特性（如鑒權、限流、熔斷），避免每個微服務單獨開發(fā)，提升效率，使系統(tǒng)更加標準化，比如身份驗證、監(jiān)控、負載均衡、限流、降級與應用檢測等功能。

為什么微服務需要 API 網(wǎng)關

Architecture Diagram

如上圖所示，API 網(wǎng)關作為客戶端和微服務的中間層，它可以將微服務以統(tǒng)一的地址對外提供服務，將外部訪問這個地址的流量，根據(jù)適當?shù)囊?guī)則路由到內(nèi)部集群中正確的服務節(jié)點之上，如果沒有 API 網(wǎng)關，流量的出入口則不統(tǒng)一，客戶端就需要知道所有服務的訪問信息，微服務的意義將不復存在，所以，微服務網(wǎng)關在微服務系統(tǒng)架構中的存在是必要的。此外，API 網(wǎng)關在系統(tǒng)的可觀測性、身份鑒權認證、穩(wěn)定性和服務發(fā)現(xiàn)等方面也會發(fā)揮重要作用。

微服務遇到的挑戰(zhàn)

微服務網(wǎng)關應該首先要具備 API 路由能力，微服務數(shù)量變多，API 數(shù)量急劇增加，網(wǎng)關還可以根據(jù)具體的場景作為流量過濾器來使用，以提供某些額外可選功能，因此對微服務 API Gateway 提出了更高要求，比如：

可觀測性：在以往的單體應用中，排查問題往往通過查看日志定位錯誤信息和異常堆棧；但是在微服務架構中服務繁多，出現(xiàn)問題時的問題定位變得非常困難；因此，如何監(jiān)控微服務的運行狀況、當出現(xiàn)異常時能快速給出報警，這給開發(fā)人員帶來很大挑戰(zhàn)。

鑒權認證：而微服務架構下，一個應用會被拆分成若干個微應用，每個微應用都需要對訪問進行鑒權，每個微應用都需要明確當前訪問用戶以及其權限。尤其當訪問來源不只是瀏覽器，還包括其它服務的調(diào)用時，單體應用架構下的鑒權方式就不是特別合適了。在微服務架構下，要考慮外部應用接入的場景、用戶 - 服務的鑒權、服務 - 服務的鑒權等多種鑒權場景。

系統(tǒng)穩(wěn)定性：若大量請求超過微服務的處理能力時，可能會將服務打垮，甚至產(chǎn)生雪崩效應、影響系統(tǒng)的整體穩(wěn)定性。

服務發(fā)現(xiàn)：微服務的分散管理，讓微服務的負載均衡的實現(xiàn)也更具有挑戰(zhàn)性。

解決方案

API 網(wǎng)關作為客戶端和服務端的中間橋梁，為微服務系統(tǒng)提供統(tǒng)一的管理機制：

除了基礎的請求分發(fā)、API 管理和條件路由等功能，還包括身份驗證、監(jiān)控報警、調(diào)用鏈追蹤、負載均衡、限流隔離和熔斷降級。身份認證：下圖表示的是微服務聯(lián)合 API 網(wǎng)關如何進行身份認證的，由圖可見所有請求都通過網(wǎng)關，從而有效地隱藏了微服務。

Architecture Diagram

監(jiān)控報警/調(diào)用鏈追蹤：

API 作為客戶端和服務端的中間橋梁，是微服務監(jiān)控的最好載體，API 網(wǎng)關監(jiān)控功能的主要職責是及時發(fā)現(xiàn)網(wǎng)關以及后端服務器的連接異常，在 API 的監(jiān)控平臺上面用戶可以隨時查看日志信息，監(jiān)控信息，調(diào)用鏈等等，并且主機發(fā)生的任何異常都會自動報警到控制臺。有些網(wǎng)關甚至可以做到給客戶端和服務端雙向報警。

Architecture Diagram

限流隔離/熔斷降級：

隨著互聯(lián)網(wǎng)業(yè)務規(guī)模的增加，系統(tǒng)的并發(fā)度增高，多個服務之間相互調(diào)用鏈路，一條核心鏈路往往可能調(diào)用十個服務。如果在鏈路中，某個服務的 rt（響應時間）急劇上升，上游服務不斷請求，造成惡性循環(huán)，上游等待結果線程數(shù)越多，使得更上游服務阻塞最終整條鏈路無法使用，從而導致服務雪崩，所以對入口流量進行整治管理是很有必要的，下圖表示微服務系統(tǒng)是如何結合 API 網(wǎng)關進行限流隔離和熔斷降級的。

Architecture Diagram

主流網(wǎng)關選擇

在微服務領域，有許多開源網(wǎng)關實現(xiàn)，有 NGINX、Kong、Apache APISIX 和 Envoy 等，Java 技術棧的有 Netfilx Zuul、Spring Cloud Gateway、Soul 等。或許你會問“有了 NGINX 和 Kong，為什么還需要 Apache APISIX？” ，下面做個簡單對比。

網(wǎng)關	痛點	優(yōu)勢
NGINX	1. 修改配置需要 Reload 才能生效，跟不上云原生的發(fā)展。	1. 老牌應用； 2. 穩(wěn)定可靠，久經(jīng)考驗； 3. 高性能。
Apache APISIX	1. 文檔不夠豐富和清晰，需要待改進。	1. Apache 基金會頂級項目； 2. 技術架構更貼合云原生； 3. 性能表現(xiàn)優(yōu)秀； 4. 生態(tài)豐富； 5. 除了支持 Lua 開發(fā)插件外，還支持 Java、Go、Python、Node 等語言插件。
Kong	1. 默認使用 PostgreSQL 或 Cassandra 數(shù)據(jù)庫，使得整個架構非常臃腫，并且會帶來高可用的問題； 2. 路由使用的是遍歷查找，當網(wǎng)關內(nèi)有超過上千個路由時，它的性能就會出現(xiàn)比較急劇的下降； 3. 一些重要功能是需要付費的。	1. 開源 API 網(wǎng)關的鼻祖，用戶數(shù)眾多； 2. 性能滿足大部分用戶的需求； 3. 生態(tài)豐富； 4. 支持 Lua 和 Go 開發(fā)插件。
Envoy	1. 使用 C++，二次開發(fā)難度大； 2. 除了 C++ 開發(fā) filter 外，還支持 WASM 和 Lua。	1. CNCF 畢業(yè)項目更適合服務網(wǎng)格場景多語言架構部署。
Spring Cloud Gateway	1. 雖然 Spring 社區(qū)成熟，但是 Gateway 資源缺乏。	1. 內(nèi)置了非常多的開箱即用功能，并且都可以通過 SpringBoot 配置或者手工編碼鏈式調(diào)用來使用； 2. Spring 系列可擴展性強，易配置，可維護性好； 3. Spring 社區(qū)成熟； 4. 簡單易用； 5. 對于 Java 技術棧來說方便。

總結

隨著互聯(lián)網(wǎng)的發(fā)展，互聯(lián)網(wǎng)企業(yè)的業(yè)務也在不斷的飛速發(fā)展，進而導致系統(tǒng)的架構也在不斷的發(fā)生著變化，微服務架構已經(jīng)在眾多公司得到廣泛應用。隨著微服務的數(shù)據(jù)越來越多，API 的數(shù)量也越來越多，對于大流量的治理，選擇一個優(yōu)秀的 API 網(wǎng)關是至關重要的。

本文列舉了常見網(wǎng)關，并進行對比，列出各自的優(yōu)缺點，如果你正在做 API 網(wǎng)關的技術選型，或者你的微服務系統(tǒng)出現(xiàn)了性能問題，再或者你想搭建一個高效穩(wěn)定的微服務系統(tǒng)，希望本文可以帶給你一定的啟發(fā)。

審核編輯：湯梓紅

聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權轉載。文章觀點僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用，如有內(nèi)容侵權或者其他違規(guī)問題，請聯(lián)系本站處理。舉報投訴