日流量200億，攜程網(wǎng)關的架構(gòu)設計

方案的作者：Butters，攜程軟件技術(shù)專家，專注于網(wǎng)絡架構(gòu)、API網(wǎng)關、負載均衡、Service Mesh等領域。

一、概述

類似于許多企業(yè)的做法，攜程 API 網(wǎng)關是伴隨著微服務架構(gòu)一同引入的基礎設施，其最初版本于 2014 年發(fā)布。隨著服務化在公司內(nèi)的迅速推進，網(wǎng)關逐步成為應用程序暴露在外網(wǎng)的標準解決方案。后續(xù)的“ALL IN 無線”、國際化、異地多活等項目，網(wǎng)關都隨著公司公共業(yè)務與基礎架構(gòu)的共同演進而不斷發(fā)展。截至 2021 年 7 月，整體接入服務數(shù)量超過 3000 個，日均處理流量達到 200 億。

在技術(shù)方案方面，公司微服務的早期發(fā)展深受 NetflixOSS 的影響，網(wǎng)關部分最早也是參考了 Zuul 1.0 進行的二次開發(fā)，其核心可以總結(jié)為以下四點：

• server端：Tomcat NIO + AsyncServlet
• 業(yè)務流程：獨立線程池，分階段的責任鏈模式
• client端：Apache HttpClient，同步調(diào)用
• 核心組件：Archaius（動態(tài)配置客戶端），Hystrix（熔斷限流），Groovy（熱更新支持）

圖片

眾所周知，同步調(diào)用會阻塞線程，系統(tǒng)的吞吐能力受 IO 影響較大。

作為行業(yè)的領先者，Zuul 在設計時已經(jīng)考慮到了這個問題：通過引入 Hystrix，實現(xiàn)資源隔離和限流，將故障（慢 IO）限制在一定范圍內(nèi)；結(jié)合熔斷策略，可以提前釋放部分線程資源；最終達到局部異常不會影響整體的目標。

然而，隨著公司業(yè)務的不斷發(fā)展，上述策略的效果逐漸減弱，主要原因有兩方面：

• 業(yè)務出海：網(wǎng)關作為海外接入層，部分流量需要轉(zhuǎn)回國內(nèi)，慢 IO 成為常態(tài)
• 服務規(guī)模增長：局部異常成為常態(tài)，加上微服務異常擴散的特性，線程池可能長期處于亞健康狀態(tài)

圖片

全異步改造是攜程 API 網(wǎng)關近年來的一項核心工作，本文也將圍繞此展開，探討我們在網(wǎng)關方面的工作與實踐經(jīng)驗。

重點包括：性能優(yōu)化、業(yè)務形態(tài)、技術(shù)架構(gòu)、治理經(jīng)驗等。

二、高性能網(wǎng)關核心設計

2.1. 異步流程設計

全異步 = server端異步 + 業(yè)務流程異步 + client端異步

對于server與client端，我們采用了 Netty 框架，其 NIO/Epoll + Eventloop 的本質(zhì)就是事件驅(qū)動的設計。

我們改造的核心部分是將業(yè)務流程進行異步化，常見的異步場景有：

• 業(yè)務 IO 事件：例如請求校驗、身份驗證，涉及遠程調(diào)用
• 自身 IO 事件：例如讀取到了報文的前 xx 字節(jié)
• 請求轉(zhuǎn)發(fā)：包括 TCP 連接，HTTP 請求

從經(jīng)驗上看，異步編程在設計和讀寫方面相比同步會稍微困難一些，主要包括：

• 流程設計&狀態(tài)轉(zhuǎn)換
• 異常處理，包括常規(guī)異常與超時
• 上下文傳遞，包括業(yè)務上下文與trace log
• 線程調(diào)度
• 流量控制

特別是在Netty上下文內(nèi)，如果對 ByteBuf 的生命周期設計不完善，很容易導致內(nèi)存泄漏。

圍繞這些問題，我們設計了對應外圍框架，最大努力對業(yè)務代碼抹平同步/異步差異，方便開發(fā)；同時默認兜底與容錯，保證程序整體安全。

在工具方面，我們使用了 RxJava，其主要流程如下圖所示。

圖片

• Maybe
• RxJava 的內(nèi)置容器類，表示正常結(jié)束、有且僅有一個對象返回、異常三種狀態(tài)
• 響應式，便于整體狀態(tài)機設計，自帶異常處理、超時、線程調(diào)度等封裝
• Maybe.empty()/Maybe.just(T)，適用同步場景
• 工具類RxJavaPlugins，方便切面邏輯封裝
• Filter
• 代表一塊獨立的業(yè)務邏輯，同步&異步業(yè)務統(tǒng)一接口，返回Maybe
• 異步場景（如遠程調(diào)用）統(tǒng)一封裝，如涉及線程切換，通過maybe.obesrveOn(eventloop)切回
• 異步filter默認增加超時，并按弱依賴處理，忽略錯誤

public interface Processor<T> {    
    ProcessorType getType();
    
    int getOrder();
    
    boolean shouldProcess(RequestContext context);
    
    //對外統(tǒng)一封裝為Maybe    
    Maybe<T> process(RequestContext context) throws Exception; 
}

public abstract class AbstractProcessor implements Processor { 
    //同步&無響應，繼承此方法 
    //場景：常規(guī)業(yè)務處理 
    protected void processSync(RequestContext context) throws Exception {}


    //同步&有響應，繼承此方法，健康檢測
    //場景：健康檢測、未通過校驗時的靜態(tài)響應
    protected T processSyncAndGetReponse(RequestContext context) throws Exception {
        process(context);
        return null;
    };


    //異步，繼承此方法
    //場景：認證、鑒權(quán)等涉及遠程調(diào)用的模塊
    protected Maybe<T> processAsync(RequestContext context) throws Exception 
    {
        T response = processSyncAndGetReponse(context);
        if (response == null) {
            return Maybe.empty();
        } else {
            return Maybe.just(response);
        }
    };


    @Override
    public Maybe<T> process(RequestContext context) throws Exception {
        Maybe<T> maybe = processAsync(context);
        if (maybe instanceof ScalarCallable) {
            //標識同步方法，無需額外封裝
            return maybe;
        } else {
            //統(tǒng)一加超時，默認忽略錯誤
            return maybe.timeout(getAsyncTimeout(context), TimeUnit.MILLISECONDS,
                                 Schedulers.from(context.getEventloop()), timeoutFallback(context));
        }
    }


    protected long getAsyncTimeout(RequestContext context) {
        return 2000;
    }


    protected Maybe<T> timeoutFallback(RequestContext context) {
        return Maybe.empty();
    }
}

• 整體流程
• 沿用責任鏈的設計，分為inbound、outbound、error、log四階段
• 各階段由一或多個filter組成
• filter順序執(zhí)行，遇到異常則中斷，inbound期間任意filter返回response也觸發(fā)中斷

public class RxUtil{
    //組合某階段（如Inbound）內(nèi)的多個filter（即Callable<Maybe<T>>）
    public static <T> Maybe<T> concat(Iterable<? extends Callable<Maybe<T>>> iterable) {
        Iterator<? extends Callable<Maybe<T>>> sources = iterable.iterator();
        while (sources.hasNext()) {
            Maybe<T> maybe;
            try {
                maybe = sources.next().call();
            } catch (Exception e) {
                return Maybe.error(e);
            }
            if (maybe != null) {
                if (maybe instanceof ScalarCallable) {
                    //同步方法
                    T response = ((ScalarCallable<T>)maybe).call();
                    if (response != null) {
                        //有response，中斷
                        return maybe;
                    }
                } else {
                    //異步方法
                    if (sources.hasNext()) {
                        //將sources傳入回調(diào)，后續(xù)filter重復此邏輯
                        return new ConcattedMaybe(maybe, sources);
                    } else {
                        return maybe;
                    }
                }
            }
        }
        return Maybe.empty();
    }
}

public class ProcessEngine{
    //各個階段，增加默認超時與錯誤處理
    private void process(RequestContext context) {
        List<Callable<Maybe<Response>>> inboundTask = get(ProcessorType.INBOUND, context);
        List<Callable<Maybe<Void>>> outboundTask = get(ProcessorType.OUTBOUND, context);
        List<Callable<Maybe<Response>>> errorTask = get(ProcessorType.ERROR, context);
        List<Callable<Maybe<Void>>> logTask = get(ProcessorType.LOG, context);

        RxUtil.concat(inboundTask)    //inbound階段                    
            .toSingle()        //獲取response                          
            .flatMapMaybe(response -> {
                context.setOriginResponse(response);
                return RxUtil.concat(outboundTask);
            })            //進入outbound
            .onErrorResumeNext(e -> {
                context.setThrowable(e);
                return RxUtil.concat(errorTask).flatMap(response -> {
                    context.resetResponse(response);
                    return RxUtil.concat(outboundTask);
                });
            })            //異常則進入error，并重新進入outbound
            .flatMap(response -> RxUtil.concat(logTask))  //日志階段
            .timeout(asyncTimeout.get(), TimeUnit.MILLISECONDS, Schedulers.from(context.getEventloop()),
                     Maybe.error(new ServerException(500, "Async-Timeout-Processing"))
                    )            //全局兜底超時
            .subscribe(        //釋放資源
            unused -> {
                logger.error("this should not happen, " + context);
                context.release();
            },
            e -> {
                logger.error("this should not happen, " + context, e);
                context.release();
            },
            () -> context.release()
        );
    }   
}

2.2. 流式轉(zhuǎn)發(fā)&單線程

以HTTP為例，報文可劃分為initial line/header/body三個組成部分。

圖片

在攜程，網(wǎng)關層業(yè)務不涉及請求體body。

因為無需全量存，所以解析完請求頭header后可直接進入業(yè)務流程。

同時，如果收到請求體body部分：

①若已向upstream轉(zhuǎn)發(fā)請求，則直接轉(zhuǎn)發(fā)；

②否則，需要將其暫時存儲，等待業(yè)務流程處理完畢后，再將其與initial line/header一并發(fā)送；

③對upstream端響應的處理方式亦然。

對比完整解析HTTP報文的方式，這樣處理：

• 更早進入業(yè)務流程，意味著upstream更早接收到請求，可以有效地降低網(wǎng)關層引入的延遲
• body生命周期被壓縮，可降低網(wǎng)關自身的內(nèi)存開銷

盡管性能有所提升，但流式處理也大大增加了整個流程的復雜性。

圖片

在非流式場景下，Netty Server端編解碼、入向業(yè)務邏輯、Netty Client端的編解碼、出向業(yè)務邏輯，各個子流程相互獨立，各自處理完整的HTTP對象。而采用流式處理后，請求可能同時處于多個流程中，這帶來了以下三個挑戰(zhàn)：

• 線程安全問題：如果各個流程使用不同的線程，那么可能會涉及到上下文的并發(fā)修改；
• 多階段聯(lián)動：比如Netty Server請求接收一半遇到了連接中斷，此時已經(jīng)連上了upstream，那么upstream側(cè)的協(xié)議棧是走不完的，也必須隨之關閉連接；
• 邊緣場景處理：比如upstream在請求未完整發(fā)送情況下返回了404/413，是選擇繼續(xù)發(fā)送、走完協(xié)議棧、讓連接能夠復用，還是選擇提前終止流程，節(jié)約資源，但同時放棄連接？再比如，upstream已收到請求但未響應，此時Netty Server突然斷開，Netty Client是否也要隨之斷開？等等。

為了應對這些挑戰(zhàn)，我們采用了單線程的方式，核心設計包括：

• 上線文綁定Eventloop，Netty Server/業(yè)務流程/Netty Client在同個eventloop執(zhí)行；
• 異步filter如因IO庫的關系，必須使用獨立線程池，那在后置處理上必須切回；
• 流程內(nèi)資源做必要的線程隔離（如連接池）；

單線程方式避免了并發(fā)問題，在處理多階段聯(lián)動、邊緣場景問題時，整個系統(tǒng)處于確定的狀態(tài)下，有效降低了開發(fā)難度和風險；此外，減少線程切換，也能在一定程度上提升性能。然而，由于 worker 線程數(shù)較少（一般等于 CPU 核數(shù)），eventloop 內(nèi)必須完全避免 IO 操作，否則將對系統(tǒng)的吞吐量造成重大影響。

2.3 其他優(yōu)化

• 內(nèi)部變量懶加載

對于請求的 cookie/query 等字段，如果沒有必要，不提前進行字符串解析

• 堆外內(nèi)存&零拷貝

結(jié)合前文的流式轉(zhuǎn)發(fā)設計，進一步減少系統(tǒng)內(nèi)存占用。

• ZGC

由于項目升級到 TLSv1.3，引入了 JDK11（JDK8 支持較晚，8u261 版本，2020.7.14），同時也嘗試了新一代的垃圾回收算法，其實際表現(xiàn)確實如人們所期待的那樣出色。盡管 CPU 占用有所增加，但整體 GC 耗時下降非常顯著。

圖片

圖片

• 定制的HTTP編解碼

由于 HTTP 協(xié)議的歷史悠久及其開放性，產(chǎn)生了很多“不良實踐”，輕則影響請求成功率，重則對網(wǎng)站安全構(gòu)成威脅。

• 流量治理

對于請求體過大（413）、URI 過長（414）、非 ASCII 字符（400）等問題，一般的 Web 服務器會選擇直接拒絕并返回相應的狀態(tài)碼。由于這類問題跳過了業(yè)務流程，因此在統(tǒng)計、服務定位和故障排查方面會帶來一些麻煩。通過擴展編解碼，讓問題請求也能完成路由流程，有助于解決非標準流量的管理問題。

• 請求過濾

例如 request smuggling（Netty 4.1.61.Final 修復，2021.3.30 發(fā)布）。通過擴展編解碼，增加自定義校驗邏輯，可以讓安全補丁更快地得以應用。

三、網(wǎng)關業(yè)務形態(tài)

作為獨立的、統(tǒng)一的入向流量收口點，網(wǎng)關對企業(yè)的價值主要展現(xiàn)在三個方面：

• 解耦不同網(wǎng)絡環(huán)境：典型場景包括內(nèi)網(wǎng)&外網(wǎng)、生產(chǎn)環(huán)境&辦公區(qū)、IDC內(nèi)部不同安全域、專線等；
• 天然的公共業(yè)務切面：包括安全&認證&反爬、路由&灰度、限流&熔斷&降級、監(jiān)控&告警&排障等；

圖片

圖片

• 高效、靈活的流量控制

這里展開講幾個細分場景：

• 私有協(xié)議

在收口的客戶端（APP）中，框架層會攔截用戶發(fā)起的 HTTP 請求，通過私有協(xié)議（SOTP）的方式傳送到服務端。

選址方面：①通過服務端分配 IP，防止 DNS 劫持；②進行連接預熱；③采用自定義的選址策略，可以根據(jù)網(wǎng)絡狀況、環(huán)境等因素自行切換。

交互方式上：①采用更輕量的協(xié)議體；②統(tǒng)一進行加密與壓縮與多路復用；③在入口處由網(wǎng)關統(tǒng)一轉(zhuǎn)換協(xié)議，對業(yè)務無影響。

• 鏈路優(yōu)化

關鍵在于引入接入層，讓遠程用戶就近訪問，解決握手開銷過大的問題。同時，由于接入層與 IDC 兩端都是可控的，因此在網(wǎng)絡鏈路選擇、協(xié)議交互模式等方面都有更大的優(yōu)化空間。

• 異地多活

與按比例分配、就近訪問策略等不同，在異地多活模式下，網(wǎng)關（接入層）需要根據(jù)業(yè)務維度的 shardingKey 進行分流（如 userId），防止底層數(shù)據(jù)沖突。

圖片

四、網(wǎng)關治理

下所示的圖表概括了網(wǎng)上網(wǎng)關的工作狀態(tài)?？v向?qū)覀兊臉I(yè)務流程：各種渠道（如 APP、H5、小程序、供應商）和各種協(xié)議（如 HTTP、SOTP）的流量通過負載均衡分配到網(wǎng)關，通過一系列業(yè)務邏輯處理后，最終被轉(zhuǎn)發(fā)到后端服務。經(jīng)過第二章的改進后，橫向業(yè)務在性能和穩(wěn)定性方面都得到了顯著提升。

圖片

另一方面，由于多渠道/協(xié)議的存在，網(wǎng)上網(wǎng)關根據(jù)業(yè)務進行了獨立集群的部署。早期，業(yè)務差異（如路由數(shù)據(jù)、功能模塊）通過獨立的代碼分支進行管理，但是隨著分支數(shù)量的增加，整體運維的復雜性也在不斷提高。在系統(tǒng)設計中，復雜性通常也意味著風險。因此，如何對多協(xié)議、多角色的網(wǎng)關進行統(tǒng)一管理，如何以較低的成本快速為新業(yè)務構(gòu)建定制化的網(wǎng)關，成為了我們下一階段的工作重點。

解決方案已經(jīng)在圖中直觀地呈現(xiàn)出來，一是在協(xié)議上進行兼容處理，使網(wǎng)上代碼在一個框架下運行；二是引入控制面，對網(wǎng)上網(wǎng)關的差異特性進行統(tǒng)一管理。

圖片

4.1 多協(xié)議兼容

多協(xié)議兼容的方法并不新穎，可以參考 Tomcat 對 HTTP/1.0、HTTP/1.1、HTTP/2.0 的抽象處理。盡管 HTTP 在各個版本中增加了許多新特性，但在進行業(yè)務開發(fā)時，我們通常無法感知到這些變化，關鍵在于 HttpServletRequest 接口的抽象。

在攜程，網(wǎng)上網(wǎng)關處理的都是請求 - 響應模式的無狀態(tài)協(xié)議，報文結(jié)構(gòu)也可以劃分為元數(shù)據(jù)、擴展頭、業(yè)務報文三部分，因此可以方便地進行類似的嘗試。相關工作可以用以下兩點來概括：

• 協(xié)議適配層：用于屏蔽不同協(xié)議的編解碼、交互模式、對 TCP 連接的處理等
• 定義通用中間模型與接口：業(yè)務面向中間模型與接口進行編程，更好地關注到協(xié)議對應的業(yè)務屬性上

圖片

4.2 路由模塊

路由模塊是控制面的兩個主要組成部分之一，除了管理網(wǎng)關與服務之間的映射關系外，服務本身可以用以下模型來概括：

{
    //匹配方式
    "type": "uri",

    //HTTP默認采用uri前綴匹配，內(nèi)部通過樹結(jié)構(gòu)尋址；私有協(xié)議（SOTP）通過服務唯一標識定位。
    "value": "/hotel/order",
    "matcherType": "prefix",

    //標簽與屬性
    //用于portal端權(quán)限管理、切面邏輯運行（如按核心/非核心）等
    "tags": [
        "owner_admin",
        "org_framework",
        "appId_123456"
    ],
    "properties": {
        "core": "true"
    },

    //endpoint信息
    "routes": [{
        //condition用于二級路由，如按app版本劃分、按query重分配等
        "condition": "true",
        "conditionParam": {},
        "zone": "PRO",

        //具體服務地址，權(quán)重用于灰度場景
        "targets": [{
            "url": "http://test.ctrip.com/hotel",
            "weight": 100
        }
                   ]
    }]
}

4.3 模塊編排

模塊調(diào)度是控制面的另一個關鍵組成部分。我們在網(wǎng)關處理流程中設置了多個階段（圖中用粉色表示）。除了熔斷、限流、日志等通用功能外，運行時，不同網(wǎng)關需要執(zhí)行的業(yè)務功能由控制面統(tǒng)一分配。這些功能在網(wǎng)關內(nèi)部有獨立的代碼模塊，而控制面則額外定義了這些功能對應的執(zhí)行條件、參數(shù)、灰度比例和錯誤處理方式等。這種調(diào)度方式也在一定程度上保證了模塊之間的解耦。

圖片

{
    //模塊名稱，對應網(wǎng)關內(nèi)部某個具體模塊
    "name": "addResponseHeader",

    //執(zhí)行階段
    "stage": "PRE_RESPONSE",

    //執(zhí)行順序
    "ruleOrder": 0,

    //灰度比例
    "grayRatio": 100,

    //執(zhí)行條件
    "condition": "true",
    "conditionParam": {},

    //執(zhí)行參數(shù)
    //大量${}形式的內(nèi)置模板，用于獲取運行時數(shù)據(jù)
    "actionParam": {
        "connection": "keep-alive",
        "x-service-call": "${request.func.remoteCost}",
        "Access-Control-Expose-Headers": "x-service-call",
        "x-gate-root-id": "${func.catRootMessageId}"
    },

    //異常處理方式，可以拋出或忽略
    "exceptionHandle": "return"
}

五、總結(jié)

網(wǎng)關在各種技術(shù)交流平臺上一直是備受關注的話題，有很多成熟的解決方案：易于上手且發(fā)展較早的 Zuul 1.0、高性能的 Nginx、集成度高的 Spring Cloud Gateway、日益流行的 Istio 等等。

最終的選型還是取決于各公司的業(yè)務背景和技術(shù)生態(tài)。

因此，在攜程，我們選擇了自主研發(fā)的道路。

技術(shù)在不斷發(fā)展，我們也在持續(xù)探索，包括公共網(wǎng)關與業(yè)務網(wǎng)關的關系、新協(xié)議（如 HTTP3）的應用、與 ServiceMesh 的關聯(lián)等等。