成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

日流量200億,攜程網關的架構設計

網絡 網絡管理
網關在各種技術交流平臺上一直是備受關注的話題,有很多成熟的解決方案:易于上手且發展較早的 Zuul 1.0、高性能的 Nginx、集成度高的 Spring Cloud Gateway、日益流行的 Istio 等等。

日流量200億,攜程網關的架構設計

方案的作者:Butters,攜程軟件技術專家,專注于網絡架構、API網關、負載均衡、Service Mesh等領域。

一、概述

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

在技術方案方面,公司微服務的早期發展深受 NetflixOSS 的影響,網關部分最早也是參考了 Zuul 1.0 進行的二次開發,其核心可以總結為以下四點:

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

圖片圖片


眾所周知,同步調用會阻塞線程,系統的吞吐能力受 IO 影響較大。

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

然而,隨著公司業務的不斷發展,上述策略的效果逐漸減弱,主要原因有兩方面:

  • 業務出海:網關作為海外接入層,部分流量需要轉回國內,慢 IO 成為常態
  • 服務規模增長:局部異常成為常態,加上微服務異常擴散的特性,線程池可能長期處于亞健康狀態

圖片圖片

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

重點包括:性能優化、業務形態、技術架構、治理經驗等。

二、高性能網關核心設計

2.1. 異步流程設計

全異步 = server端異步 + 業務流程異步 + client端異步

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

我們改造的核心部分是將業務流程進行異步化,常見的異步場景有:

  • 業務 IO 事件:例如請求校驗、身份驗證,涉及遠程調用
  • 自身 IO 事件:例如讀取到了報文的前 xx 字節
  • 請求轉發:包括 TCP 連接,HTTP 請求

從經驗上看,異步編程在設計和讀寫方面相比同步會稍微困難一些,主要包括:

  • 流程設計&狀態轉換
  • 異常處理,包括常規異常與超時
  • 上下文傳遞,包括業務上下文與trace log
  • 線程調度
  • 流量控制

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

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

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

圖片圖片


  • Maybe
  • RxJava 的內置容器類,表示正常結束、有且僅有一個對象返回、異常三種狀態
  • 響應式,便于整體狀態機設計,自帶異常處理、超時、線程調度等封裝
  • Maybe.empty()/Maybe.just(T),適用同步場景
  • 工具類RxJavaPlugins,方便切面邏輯封裝
  • Filter
  • 代表一塊獨立的業務邏輯,同步&異步業務統一接口,返回Maybe
  • 異步場景(如遠程調用)統一封裝,如涉及線程切換,通過maybe.obesrveOn(eventloop)切回
  • 異步filter默認增加超時,并按弱依賴處理,忽略錯誤
public interface Processor<T> {    
    ProcessorType getType();
    
    int getOrder();
    
    boolean shouldProcess(RequestContext context);
    
    //對外統一封裝為Maybe    
    Maybe<T> process(RequestContext context) throws Exception; 
}
public abstract class AbstractProcessor implements Processor { 
    //同步&無響應,繼承此方法 
    //場景:常規業務處理 
    protected void processSync(RequestContext context) throws Exception {}


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


    //異步,繼承此方法
    //場景:認證、鑒權等涉及遠程調用的模塊
    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 {
            //統一加超時,默認忽略錯誤
            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順序執行,遇到異常則中斷,inbound期間任意filter返回response也觸發中斷
public class RxUtil{
    //組合某階段(如Inbound)內的多個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傳入回調,后續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. 流式轉發&單線程

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

圖片圖片

在攜程,網關層業務不涉及請求體body。

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

同時,如果收到請求體body部分:

①若已向upstream轉發請求,則直接轉發;

②否則,需要將其暫時存儲,等待業務流程處理完畢后,再將其與initial line/header一并發送;

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

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

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

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

圖片圖片

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

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

為了應對這些挑戰,我們采用了單線程的方式,核心設計包括:

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

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

2.3 其他優化

  • 內部變量懶加載

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

  • 堆外內存&零拷貝

結合前文的流式轉發設計,進一步減少系統內存占用。

  • ZGC

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

圖片圖片


圖片圖片

  • 定制的HTTP編解碼

由于 HTTP 協議的歷史悠久及其開放性,產生了很多“不良實踐”,輕則影響請求成功率,重則對網站安全構成威脅。

  • 流量治理

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

  • 請求過濾

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

三、網關業務形態

作為獨立的、統一的入向流量收口點,網關對企業的價值主要展現在三個方面:

  • 解耦不同網絡環境:典型場景包括內網&外網、生產環境&辦公區、IDC內部不同安全域、專線等;
  • 天然的公共業務切面:包括安全&認證&反爬、路由&灰度、限流&熔斷&降級、監控&告警&排障等;

圖片圖片

圖片圖片

  • 高效、靈活的流量控制

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

  • 私有協議

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

選址方面:①通過服務端分配 IP,防止 DNS 劫持;②進行連接預熱;③采用自定義的選址策略,可以根據網絡狀況、環境等因素自行切換。

交互方式上:①采用更輕量的協議體;②統一進行加密與壓縮與多路復用;③在入口處由網關統一轉換協議,對業務無影響。

  • 鏈路優化

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

  • 異地多活

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

圖片圖片

四、網關治理

下所示的圖表概括了網上網關的工作狀態。縱向對應我們的業務流程:各種渠道(如 APP、H5、小程序、供應商)和各種協議(如 HTTP、SOTP)的流量通過負載均衡分配到網關,通過一系列業務邏輯處理后,最終被轉發到后端服務。經過第二章的改進后,橫向業務在性能和穩定性方面都得到了顯著提升。

圖片圖片


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

解決方案已經在圖中直觀地呈現出來,一是在協議上進行兼容處理,使網上代碼在一個框架下運行;二是引入控制面,對網上網關的差異特性進行統一管理。

圖片圖片

4.1 多協議兼容

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

在攜程,網上網關處理的都是請求 - 響應模式的無狀態協議,報文結構也可以劃分為元數據、擴展頭、業務報文三部分,因此可以方便地進行類似的嘗試。相關工作可以用以下兩點來概括:

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

圖片圖片


4.2 路由模塊

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

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

    //HTTP默認采用uri前綴匹配,內部通過樹結構尋址;私有協議(SOTP)通過服務唯一標識定位。
    "value": "/hotel/order",
    "matcherType": "prefix",

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

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

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


4.3 模塊編排

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

圖片圖片

{
    //模塊名稱,對應網關內部某個具體模塊
    "name": "addResponseHeader",

    //執行階段
    "stage": "PRE_RESPONSE",

    //執行順序
    "ruleOrder": 0,

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

    //執行條件
    "condition": "true",
    "conditionParam": {},

    //執行參數
    //大量${}形式的內置模板,用于獲取運行時數據
    "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"
}


五、總結

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

最終的選型還是取決于各公司的業務背景和技術生態。

因此,在攜程,我們選擇了自主研發的道路。

技術在不斷發展,我們也在持續探索,包括公共網關與業務網關的關系、新協議(如 HTTP3)的應用、與 ServiceMesh 的關聯等等。

責任編輯:武曉燕 來源: 樓仔
相關推薦

2021-06-28 10:09:59

架構網關技術

2021-03-02 07:54:18

流量網關設計

2024-05-27 08:32:45

2021-10-14 09:51:17

架構運維技術

2024-10-29 09:40:07

流量技術架構

2021-12-03 10:47:28

WOT技術峰會技術

2020-01-17 11:00:23

流量系統架構

2024-08-16 14:01:00

2020-04-22 14:25:48

云開發高可用架構

2022-02-22 10:29:24

分布式架構高可用

2009-04-22 10:16:37

網站架構Web數據冗余

2024-08-16 10:11:24

2017-01-19 18:20:59

數據架構數據庫

2025-04-15 04:00:00

2013-05-27 10:58:28

Tumblr架構設計雅虎收購

2021-10-12 10:00:25

架構運維技術

2023-05-12 08:06:46

Kubernetes多云架構

2014-06-30 13:34:57

2009-05-05 10:24:48

應用架構設計原則

2021-08-02 11:01:32

架構運維技術
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 鲁一鲁资源影视 | 日本精品视频一区二区 | 欧美一级免费看 | www.黄色片视频 | 日韩欧美高清 | 日韩免费视频 | 亚洲精品99| 免费观看一级黄色录像 | 久久成人一区 | 日本aaa视频| 女人牲交视频一级毛片 | 欧美一区二区三区在线观看 | 爱草在线| 久久久久久中文字幕 | 国产综合在线视频 | 亚洲欧美激情视频 | 97久久国产 | 亚洲成人av在线播放 | 亚洲国产aⅴ成人精品无吗 综合国产在线 | 国产精品久久久久久久三级 | 久久伊人精品 | 欧美精品一区二区三区蜜桃视频 | 日韩欧美三区 | av网站在线播放 | 国产精品久久7777777 | 国产一区二区三区免费视频 | 欧美日韩国产精品一区二区 | 日韩欧美视频 | 欧美成人激情视频 | 国产欧美日韩在线一区 | 日本黄色短片 | 国产精品久久久久久久7电影 | 国产精品一区二区在线 | 欧美日韩亚洲三区 | 日韩一区二区三区在线 | 亚洲人va欧美va人人爽 | 久久草在线视频 | 日韩无 | 日韩色综合 | 欧美久久久久 | 日本精品网站 |