日流量200億,攜程網關的架構設計
日流量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 的關聯等等。