作(zuò)者：佚名 來源：DockOne
微服務(wù)架構是當下比較流行的一種架構風格，它是一種以業務(wù)功能(néng)組織的服務(wù)集合，可(kě)以持續交付、快速部署、更好的可(kě)擴展性和容錯能(néng)力，而且還使組織更容易去嘗試新(xīn)技(jì )術棧。微服務(wù)具有幾個關鍵特征：
高度可(kě)維護和可(kě)測試性
與其他(tā)服務(wù)松散耦合
且可(kě)獨立部署
能(néng)夠由一個小(xiǎo)團隊開發
現在很(hěn)多(duō)公司企業想将自己的單體(tǐ)應用(yòng)架構遷移到微服務(wù)架構，在這個問題上，Martin Fowler提出了3個前提，而Phil Calcado對其進行了擴展如下：
快速配置計算資源
基本監控
快速部署
易于配置存儲
易于訪問網關
認證、授權
标準化的 RPC
今天我們主要講講易于訪問的網關，也就是 API 網關。
為(wèi)什麽需要 API 網關
假設我們要使用(yòng)微服務(wù)架構構建一個電(diàn)商平台，以下可(kě)能(néng)是一些潛在的服務(wù)：
購(gòu)物(wù)車(chē)服務(wù)
訂單服務(wù)
商品服務(wù)
評論服務(wù)
庫存服務(wù)
等等，客戶端應該怎麽訪問這些服務(wù)呢(ne)?原來單體(tǐ)應用(yòng)的情況我們都知道，都在一個服務(wù)器上部署，直接訪問IP+端口+服務(wù)前綴即可(kě)，現在微服務(wù)架構下，每個服務(wù)都可(kě)以獨立部署，并且是由不同的開發團隊開發的，難道我們要這樣訪問嗎?
理(lǐ)論上每個服務(wù)都有端點可(kě)以訪問，但是客戶端就需要記錄所有服務(wù)的端點，發起5次請求，現在還是5個服務(wù)，如果之後擴展多(duō)了呢(ne)?對客戶端來說就是一個災難，随之帶來的就是安(ān)全性問題、擴展性問題等，所以這種客戶端直接與每個服務(wù)交互是不可(kě)取的，通常，更好的方式是使用(yòng) API 網關。
API 網關是客戶端訪問服務(wù)的統一入口，API 網關封裝(zhuāng)了後端服務(wù)，還提供了一些更高級的功能(néng)，例如：身份驗證、監控、負載均衡、緩存、多(duō)協議支持、限流、熔斷等等，API 網關還可(kě)以針對不同的客戶端定制不同粒度的 API，上面例子中修改架構後如下：
API 網關的優缺點
API 網關的好處是顯而易見的，封裝(zhuāng)了應用(yòng)程序的内部結構，為(wèi)不同客戶端提供不同粒度的 API，同時網關自身也提供了一些高級功能(néng)，也減少了客戶端與應用(yòng)程序之間的往返次數，使客戶端代碼更優雅。
同時使用(yòng)網關也存在一些缺點，增加了一個新(xīn)的組件，增加了整個應用(yòng)架構的複雜度，一個通俗的道理(lǐ)，你做的越多(duō)你犯錯的風險也越高，網關不可(kě)用(yòng)很(hěn)可(kě)能(néng)導緻整個應用(yòng)架構崩潰，當然現在有各種各樣的方案，能(néng)防止網關崩潰，它也可(kě)能(néng)存在瓶頸風險。
使用(yòng)網關有利有弊，我個人而言，利肯定是大于弊的，我們盡可(kě)能(néng)的将弊端降到最低。
API 網關一些實現
使用(yòng)一個組件時，尤其是這種比較流行的架構，組件肯定存在開源的，我們不必自己去從零開始去實現一個網關，自己開發一個網關的工作(zuò)量是相當可(kě)觀的，現在比較流行的開源 API 網關如下所示：
Kong
Kong是一個在 Nginx 中運行的Lua應用(yòng)程序，并且可(kě)以通過lua-nginx模塊實現，Kong不是用(yòng)這個模塊編譯Nginx，而是與 OpenResty 一起發布，OpenResty已經包含了 lua-nginx-module， OpenResty 不是 Nginx 的分(fēn)支，而是一組擴展其功能(néng)的模塊。
它的核心是實現數據庫抽象，路由和插件管理(lǐ)，插件可(kě)以存在于單獨的代碼庫中，并且可(kě)以在幾行代碼中注入到請求生命周期的任何位置。
Traefik
Traefik 是一個現代 HTTP 反向代理(lǐ)和負載均衡器，可(kě)以輕松部署微服務(wù)，Traeffik 可(kě)以與您現有的組件(Docker、Swarm，Kubernetes，Marathon，Consul，Etcd，…)集成，并自動動态配置。
Ambassador
Ambassador 是一個開源的微服務(wù) API 網關，建立在 Envoy 代理(lǐ)之上，為(wèi)用(yòng)戶的多(duō)個團隊快速發布，監控和更新(xīn)提供支持，支持處理(lǐ) Kubernetes ingress controller 和負載均衡等功能(néng)，可(kě)以與 Istio 無縫集成。
Tyk
Tyk是一個開源的、輕量級的、快速可(kě)伸縮的 API 網關，支持配額和速度限制，支持認證和數據分(fēn)析，支持多(duō)用(yòng)戶多(duō)組織，提供全 RESTful API。基于 go 編寫。
Zuul
Zuul 是一種提供動态路由、監視、彈性、安(ān)全性等功能(néng)的邊緣服務(wù)。Zuul 是 Netflix 出品的一個基于 JVM 路由和服務(wù)端的負載均衡器。
API 網關實現對比
總結
由上述對比表格中可(kě)以看出：從開源社區(qū)活躍度來看，無疑是Kong和Traefik較好；從成熟度來看，較好的是Kong、Tyk、Traefik；從性能(néng)角度來看，Kong要比其他(tā)幾個領先一些；從架構優勢的擴展性來看，Kong、Tyk有豐富的插件，Ambassador也有插件但不多(duō)，而Zuul是完全需要自研，但Zuul由于與Spring Cloud深度集成，使用(yòng)度也很(hěn)高，近年來Istio服務(wù)網格的流行，Ambassador因為(wèi)能(néng)夠和Istio無縫集成也是相當大的優勢。
具體(tǐ)使用(yòng)選擇還是需要依據具體(tǐ)的業務(wù)場景，我們在參考鏈接中收集了一些性能(néng)對比，大家可(kě)以做下參考。
聲明：本網站發布的内容（圖片、視頻和文(wén)字）以原創、轉載和分(fēn)享網絡内容為(wèi)主，如果涉及侵權請盡快告知，我們将會在第一時間删除。文(wén)章觀點不代表本網站立場，如需處理(lǐ)請聯系客服，電(diàn)話：0755-22671324。