作者 | 李鵬飛 阿裡雲開放平台技術專家，負責阿裡雲OpenAPI網關建設，緻力于為使用者提供高可用的OpenAPI服務。
引言
企業級API網關作為企業中流量的出入口，典型的特征就是承載了大量不同租戶、不同的業務的超高流量，對高并發、高性能、高穩定性、強隔離性、依賴熔斷能力、安全性都有着非常高的要求，本文将從網關形态，技術選型入手，最後重點講一下在安全防護、流量控制、穩定性方面的思路。
随着網際網路技術以及微服務、Service Mesh的發展，API在近幾年變得越來越重要，大部分的企業都開放了API，絕大多數的技術能力也可以通過API快速擷取，比如圖像識别、語音識别、資源操作等。
要開放API，就會有一個API網關，網際網路上每天數以億次的API調用背後，除了有具體的API Service提供服務外，還有API 網關作為統一出入口來處理這些流量。
網關形态
API 網關一般分為：
- 中心化；
- 去中心化。
兩類，主要差別如下：
得益于開發模型更簡單、更易維護、易接入、且有多種手段來保障穩定性，中心化的網關服務更常見，被很多大型企業、API網關服務提供廠商采用，我們本次将分享中心化網關的建設。
網關選型
要開放API，常見的解決方案有3種：
- 雲上的API Gateway類雲服務，比如 API Gateway ，提供了開箱即用的API 網關服務
- 基于開源API網關二次開發，如 Kong
- 從零自建
三種解決方案的對比如下：
核心能力
要建設一個企業級的API網關絕非一件易事，需要大量的技術持續投入，由于篇幅有限，我們在這裡隻介紹幾個最核心能力的落地思路：
- 網絡層安全防護；
- 應用層流量控制；
- 穩定性。
網絡層安全防護
作為流量的統一出入口，網關是很容易受到各類攻擊的，有一些是惡意攻擊，比如遊戲等行業就更容易受到一些惡意的攻擊，也有一些是無意的帶有攻擊行為的流量，比如突發活動導緻的大流量。
常用的防護手段有：
- 四層防護；
- 七層防護；
- 流量清洗。
四層、七層防護是兩塊涉及到攻防的專業領域，比如常見的有DDOS、基于IP的CC攻擊等，這塊需要有專門的技術投入建設的，如果沒有資源投入的話，建議購買雲上的高防服務來防護，要避免裸奔，沒有任何防護的網際網路應用是非常危險的，尤其是對于網關來說。
以基于HTTP協定的API為例：
- 我們需要針對不同的出口IP配置流量門檻值，避免某個用戶端出口IP占用過多流量而影響整個Endpoint，如果可以識别出使用者身份還可以基于使用者身份配置流控門檻值
- 如果為不同API服務提供了不同的Endpoint，我們還需要為每個Endpoint配置獨立的流量門檻值，避免單個Endpoint流量過大影響同叢集的其他Endpoint
- 除此之外，網絡層還需要對後端Real Server進行保護，需要為後端叢集配置叢集防護門檻值，避免有超過叢集容量的流量進入叢集，這裡建議配置為基于單個Server的流控門檻值，這樣當叢集動态擴縮容的時候這個門檻值會自動變更，而不是配置為絕對值。
有了四層、七層的防護，基本的防護能力就已經具備了，如果我們為每一個API服務或者每一個使用者配置設定了一個Endpoint，通常多個Endpoint的流量會流入到同一個LVS裝置，這個LVS裝置受到四層攻擊的時候我們就無法判斷是由于哪個Endpoint導緻的，這個時候就需要流量清洗能力，來分析出是攻擊者是通過哪個Endpoint作為攻擊點的，由于此類攻擊一般都是自動跟随攻擊，服務端切換一個新的LVS裝置後攻擊就會跟過來。應對措施主要流程如下：
- 使用二分法，将域名分成2份分别解析到2個LVS上；
- 判斷攻擊跟随到了哪個LVS上；
- 将跟随到的這個LVS繼續使用二分法進行拆分，直到定位到攻擊流量跟随的是哪個Endpoint；
- 将這個Endpoint拉到黑洞。
這個流量清洗方案通常可以自己開發完成，但是需要有一個用于清洗的LVS裝置池子，至此在網絡層的防護就比較全面了，包含了IP、使用者、Endpoint、叢集、流量清洗。
應用層流量控制
通過網絡層防護對網關有了比較全面的防護，網關的處理能要比每個後端Service的處理能力要強，網關作為流量入口除了要保護好網關自身，還好保護好後端Service不受攻擊，這個時候就要使用網關應用層流量控制了，在網關層需要支援為以下次元配置流控：
- 為每個Service租戶配置流控門檻值，確定每個後端服務收到的流量不會超過Service叢集容量；
- 為每個API配置流控門檻值，避免某個API占用了單個Service過多流量；
- 為每個使用者配置Service、API粒度的流控門檻值，避免單個使用者占用過多流量；
- 為特殊使用者配置特殊的流控配置，比如大使用者等。
過去，被很多人問到了應用層要如何做流控，要做一套完善的流控機制，還是需要不少投入的，對技術也有比較高的要求，流控一般有兩個互相牽制的因素：性能、準确性，尤其是當單次請求流控次元非常多的時候，性能問題就會凸顯出來，尤其是還要保障精度的時候，常用的方案有：
- 精準流控，基于Redis等分布式緩存的計數器能力進行控制；
- 單機流控，純單機流量控制；
- 單機+分布式兩段流控；
- 叢集内部流控。
基于分布式緩存的計數器模式是比較簡單的流控方案，可以做到精準流控，但是當調用分布式緩存延遲比較高+流控次元過多後性能就會成為問題，這個地方有個技巧，緩存的KEY可以設定為業務Key+時間戳，比如秒級流控可以設定為：XXX_YYYYMMDDHHMMSS，根據這個Key通過調用一次遠端計數器的Inc接口就可以完成一次精準流控，當業務體量不大，次元不多，但是需要支援精準流控的時候可以使用此方案。
純單機的流控也是一個比較常見的方案，由于不涉及到遠端IO，性能是最好的，通常用于非精準流控場景，因為不均衡的流量分布、擴容、縮容等場景都會對流控準确度造成較大的影響，将流控總門檻值平均分布到每個Server上，可以通過背景手動設定叢集數量的方式，也可以使用自動化的叢集Server數量自動感覺模式來感覺叢集總Server數。
單機+分布式緩存的兩段式流控是集上面兩種方案的優點的一種平衡解決方案，當流控水位比較低的時候采用單機流控，以取得更好的性能，當流控水位到達一定水位快滿的時候，彙總所有本地流控計數資訊後累加到分布式計數器中，并切換到分布式計數模式進行精準流控，此方案整體上在保障高精度的同時換取了更好的性能表現，通常分鐘、小時、天級别的流控更适合采用這種模式。
叢集内部流控方式，也是一種精準流控模式，即在目前本地Server叢集中選舉一個計數Server，将遠端計數IO切換到叢集内部通信，在做到精準流控的同時擷取更好的性能，這個方式在技術上會有更大的挑戰，比如當技術Server重新開機、故障後如何保障精度等。
流控方面在開源方面已經有了很多的解決方案，比如阿裡開源的
Sentinel綜合實力是非常強的，支援多種計數模式，包含叢集計數模式、滑動視窗等，其他開源解決方案還有Hystrix、resilience4j等。
穩定性
網關對于穩定性SLA的要求是要比其他任何單個Service都要高的，比如網關的SLA是5個9，那麼其他所有通過網關開放的API的SLA都不可能高于5個9。尤其是對于中心化部署的網關，一旦網關故障，造成的影響也是非常大的。是以需要通過一系列的穩定性保障體系來保障網關的穩定性，而不是隻做到某個點就可以的，其中比較核心的幾個點有：
租戶隔離：
網關作為一個平台，會有很多租戶接入，即不同的Service提供者，網關要做到不同租戶之間的隔離，不能互相影響，典型的反例是：網關是基于線程模型的同步調用，且多個Service在同一個叢集提供服務，當某個Service有大量慢調用的時候就會耗盡所有網關層的線程資源，導緻整個叢集中的服務不可用，導緻雪崩。
- 首先網關需要基于異步的模型，或者使用協程，網關做為一個網絡IO密集型應用，一定要避免被某個遠端調用影響；
- 在租戶層面可以考慮基于容器的隔離，為所有接入租戶或者重要租戶進行實體隔離；
- 對連結進行隔離，比如基于HTTP的連接配接池，要為每個host設定預設的最大連接配接數量；
- 基于線程池的隔離，實際在網關中應用較少，如果有适合的場景也可以考慮使用。
熔斷降級：
對于依賴的服務要有熔斷降級機制
- 網關的主要依賴就是後端Service，後端Service通常也是最不穩定的，比如高RT、大Request、大Response等。當某個後端服務、API指定異常數量超過一定數量後要自動降級，隻放小流量到後端Service，通過小流量探測後端恢複正常後再恢複服務，避免單個Service、API的異常流量耗盡系統資源。
- 除了Service外就是資料源、分布式緩存、認證系統等，當這些依賴服務異常後網關要有逃生能力，通常可以通過多級邏輯+實體緩存解決，比如本地緩存、分布式緩存、磁盤檔案兜底等方案，當依賴服務故障後對于存量的業務網關依然可以繼續提供服務。
熔斷也有一些開源的解決方案，比如阿裡開源的
，除了支援流控，在熔斷方面也是非常優秀的。
巡檢、自動化回歸測試：
網關作為開放API的平台，所有的能力都可以通過API調用完成自動化的測試、驗證，是最适合做自動化回歸測試、自動巡檢的系統，一定要確定網關系統有完善的自動化測試Case，當API釋出過程中進行驗證，并在日常做巡檢，一旦系統能力有任何問題，可以第一時間收到報警。
容災演練：
将容災演練日常化，在大版本釋出的時候要有容災測試，確定新代碼沒有破壞系統的容災能力。
除了這些以外，還要結合前面講到的安全防護能力一起保障網關的穩定性
總結
要建設一個企業級的網關要先根據目前的環境選擇适合的方案，不是所有的企業都需要自己從零建設自己的網關，一旦決定要做，是需要持續的技術投入的，本文隻是重點介紹了建設網關中最重要的穩定性部分，作為網關穩定一定是第一位的，也是最難做的部分，本文作為一個引子，後續将會針對不同的細分領域進行分享。