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