摘要：現在大家在談“分布式”、“微服務”、“雲原生”這些概念時，更多在談支撐“軟件服務”的彈性伸縮與負載均衡。API Gateway作為其第一道關卡以及其重要組成組件，我們來看看他的發展歷程、現狀及未來的方向。
API網關作為現代分布式、微服務、雲原生系統中的一個重要組成部分，也作為一項重要的討論主題，咱也聊聊負載均衡及API Gateway的現狀。
現在大家在談“分布式”、“微服務”、“雲原生”這些概念時，除了“軟件服務”功能本身，更多的是在談如何讓服務可以更好的擴展來支持大規模的應用。負載均衡及API網關是作為其第一道關卡以及其重要組成組件，我們來看看他的發展歷程、現狀及未來的方向。
負載均衡
談到網關，不得不談負載均衡，通常負載均衡有服務器負載均衡和客戶端負載均衡（例如Spring Cloud Ribbon & Eureka）兩種不同的方式。對於非REST且對實時性要求較高的服務來說，客戶端負載均衡是一種常用的選擇，比如王者榮耀、英雄聯盟這種游戲來說，進入游戲的各種日常活動，都是基於REST服務的，而組隊進行比賽時，通常都是非REST服務。還有在線協作的產品，如Welink的IM/Presence功能，其服務端是可以做成REST服務，而Welink Meeting這種實時音視頻會議（real-time colloration），RESE服務不能滿足其實時性要求。大都是采用客戶端負載均衡的方式，基本過程如下：
1、負載均衡網關與服務器之間的注冊或發現機制。
2、客戶端向網關請求會議服務器列表，這里服務器會有一些業務邏輯從而計算出一些服務器列表返回給客戶端。
3、客戶端拿到服務器列表會向服務器發送探測報文，根據探測報文的響應時間（客戶端與服務器之間網絡狀況），以及服務器的負載等因素來決定選擇哪一個服務器。
4、客戶端與服務器通過約定的協議建立業務連接。
5、如果客戶端或者服務器任何一段出現異常，客戶端會重新走2-4的流程恢復業務連接。
從上述可以看出客戶負載均衡的會有一個相對復雜的過程，但是一旦建立連接，其性能一定是最優的。不過客戶端負載均衡無法保證服務器REST服務化，一旦服務器發生故障，會有短暫的服務中斷。但是該方案適用於一些實時性要求較高的一些應用（如上述說到的一些應用）。而對於REST的服務來說，采用L4負載均衡（F5、LVS、nginx、haproxy等）/L7負載均衡（haproxy、nginx、apache、Mysql proxy等）是通用的方法。這次Arch Summit，部分廠商介紹其采用4層負載均衡方案。我們來大致看一下整個分布式系統負載均衡的整體架構及發展歷程。
從負載均衡的發展來看，根據其應用規模其演進過程大致如下：
API Gateway的現狀
隨着微服務的流行，API Getway得到蓬勃的發展。對於API Gateway本職工作是承擔消息分發任務，提供給客戶統一的API入口。通常有2種方式：Single API Gateway和Backend for Frontend API Gateway。有沒有第三種模式呢？我之前做的一個產品，其網關基本架構如下：
1、客戶端有登錄的要求，在登錄認證的response里，包含了不同服務的api的url列表。
2、客戶端在不同的api請求是，使用對應的api url，這樣客戶端來實現了大部分api的分發工作。
3、這時候API 網關的主要任務其實已經不是最初的API轉發的功能了。而是為了簡化后端服務，實現后端服務的一些公共功能。
4、甚至在這種場景下，可以沒有API網關，API可以直接面對應用服務，再由應用服務來調度微服務進行業務處理。
回到的API gateway本身，其最核心設計理念是保證數據面的業務不中斷。由於對接 API 網關的服務是多樣的，客戶 API 跟應用的設計不可控，你很難能要求每個接入的服務以及客戶端都具備容錯能力。這就要求網關盡量保證能正常處理每個請求，且滿足較高的 SLA，現在業界的 API 網關的主流使用Nginx系，主要考慮如下：
- 支持熱重啟
數據面的組件升級是一個高風險動作， 一旦出現異常就可能導致連接中斷，系統異常， 除非你的前端 LB（負載均衡）能具備快速排水的能力，當然即使如此，還是可能導致正在處理的請求被強制中斷。所以數據面的熱重啟非常關鍵。 - 支持訂閱式動態路由
API 路由變化相對頻繁，及時性也要求比較高，如果采用定期同步方案，一次性同步幾萬條的數據會拖慢你的系統，因此增加一個訂閱式的路由服務中心非常關鍵，我們可以快速訂閱 ETCD 中的路由數據並實時生效。而且只拿增量數據性能壓力不會太大。 - 支持插件化管理
Nginx 在插件方面提供了豐富的生態。不同的 API，不同的用戶所需要的處理流程不完全一致，如果每個請求過來都按照相同流程處理，必定帶來相關的冗余操作。插件化管理可以在一定程度上提升性能，還能保障在升級過程中能快速添加處理鏈。 - 高性能的轉發能力
API 網關一般工作在多后端 API 反向代理模式，很多自研的 API 網關在性能上容易出現瓶頸，因此 nginx 優異的性能和高效的流量吞吐是其核心競爭力。 - 無狀態可橫向擴展
API 網關承載的是整個系統所有請求的集合，需要根據業務規模進行彈性伸縮，采用服務中心配合 Nginx 配置管理可以快速增刪已有的集群，並同步到 LVS，實現快速的橫向擴展能力。
隨着現在的系統的越來越復雜，很多服務模塊除了處理自身業務之外，還有承擔一些非業務的職責，如認證和授權，限流，緩存，日志，監控，重試，熔斷等。這樣涌現了一批開源的API網關實現。
- Tyk：Tyk是一個開源的、輕量級的、快速可伸縮的 API 網關，支持配額和速度限制，支持認證和數據分析，支持多用戶多組織，提供全 RESTful API（go語言）。
- Kong：Kong 可以認為是一個 OpenResty 應用程序，而OpenResty 運行在 Nginx 之上，使用 Lua 擴展了 Nginx。（Kong = OpenResty + Nginx + Lua）
- Orange：Orange 是一個基於 OpenResty 的 API Gateway，提供API及自定義規則的監控和管理，如訪問統計、流量切分、API重定向、API鑒權、WEB防火牆等功能。（騰訊在用）
- Netflix Zuul：Zuul是一種提供動態路由、監視、彈性、安全性等功能的邊緣服務。Zuul是Netflix出品的一個基於JVM路由和服務端的負載均衡器。（Spring Cloud）
- Ambassador：Ambassador 是一個開源的微服務 API 網關，建立在 Envoy 代理之上，為用戶的多個團隊快速發布，監控和更新提供支持，支持處理 Kubernetes ingress controller 和負載均衡等功能，可以與 Istio 無縫集成。(Kubernetes-Native)
- 其他…(例如：apiaxle: Nodejs 實現的一個 API 網關； api-umbrella: Ruby 實現的一個 API 網關。)
除了上述功能，隨着API網關服務承擔了越來越多的職責，其性能瓶頸也越顯突出。這次ArchSummit一些公司展示了一些自己的特色功能，還有在產品演化中，自己在架構上做了一些優化，主要有：
- 采用C++來實現網關來提升性能 （*）
– 在本次會議中，有2-3家企業都在提用C++實現來提升性能。這基本上與架構無關，更多的是編程語言自身的差異了。 - 私有協議加速API與服務的映射關系
– 這個好幾家都在做，比如騰訊。 - 網關實現分層隔離不變與易變，實現網關的增值業務的架構演進（*）
– 這個就是架構層面的東西了，我的理解是更多架構演進及運維相關的考慮。把面向前端客戶（穩定）與面向后端服務（不穩定）的部分再分層實現、分層部署，從而面向客戶的網關服務基本上不變動。當后端服務在功能擴展或者重構后，系統升級對於客戶影響最小（具體細節沒介紹）。 - 網關實現限流，讓后端服務更穩定，更簡單。
– 這個比較容易理解，也是常規的做法。這樣讓后端的應用服務/微服務設計與實現更簡單。當然不同的產品實現各不相同。其中騰訊介紹游戲API網關時，提到了服務啟動靜態創建最大化連接Session，去除動態創建和回收機制，以達到性能最優。 - 網關實現認證，簡化后端服務的業務流程（適合認證，不適合權限）
– 這個也是比較常規的做法，目的是也是讓后端的應用服務/微服務設計與實現更簡單。這種服務多適合認證，但是權限的管理在一些特殊的應用場景未必適用。比如某些應用里的某個功能，對於權限划分比較細，已經是針對內容級別的訪問控制。網關一般不能代替服務來實現，還是需要通過服務本身來完成。
總結
從網關的發展來看，其經歷了一代又一代的演進，從自身架構的演進，再到其功能上疊加，在促進其架構上的再此迭代演進。在現再這個萬物皆雲的時代，雲原生這個概念已經被各個行業所接受並且提高一個很高的高度。連一些傳統的網絡設備業務也要上雲。
對於產品的發展與演進，我們也會“抄、學、變”。
- 對於相同相識業務，成熟優秀的解決方案，我們要會“抄”，直接拿過來用，不要自己閉門造輪子。
- 對於不同的業務做轉型演進，可以借鑒的經驗不多，但是對於相關領域架構、知識。我們不能抄，而要“學”，學習其思想，其精髓。
- 最后是變，任何通用的解決方案和架構可以解決通用的問題，但是由於通用，也不可避免的有一些“通病”。
附錄：Arch Summit API網關一些架構圖：
