摘要：現在大家在談“分布式”、“微服務”、“雲原生”這些概念時，更多在談支撐“軟體服務”的彈性伸縮與負載均衡。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網關一些架構圖：
點選關注，第一時間了解華為雲新鮮技術~