日流量200億，攜程網(wǎng)關(guān)的架構(gòu)設(shè)計
日流量200億，攜程網(wǎng)關(guān)的架構(gòu)設(shè)計
方案的作者：Butters，攜程軟件技術(shù)專家，專注于網(wǎng)絡(luò)架構(gòu)、API網(wǎng)關(guān)、負(fù)載均衡、Service Mesh等領(lǐng)域。
一、概述
類似于許多企業(yè)的做法，攜程 API 網(wǎng)關(guān)是伴隨著微服務(wù)架構(gòu)一同引入的基礎(chǔ)設(shè)施，其最初版本于 2014 年發(fā)布。隨著服務(wù)化在公司內(nèi)的迅速推進(jìn)，網(wǎng)關(guān)逐步成為應(yīng)用程序暴露在外網(wǎng)的標(biāo)準(zhǔn)解決方案。后續(xù)的“ALL IN 無線”、國際化、異地多活等項目，網(wǎng)關(guān)都隨著公司公共業(yè)務(wù)與基礎(chǔ)架構(gòu)的共同演進(jìn)而不斷發(fā)展。截至 2021 年 7 月，整體接入服務(wù)數(shù)量超過 3000 個，日均處理流量達(dá)到 200 億。
在技術(shù)方案方面，公司微服務(wù)的早期發(fā)展深受 NetflixOSS 的影響，網(wǎng)關(guān)部分最早也是參考了 Zuul 1.0 進(jìn)行的二次開發(fā)，其核心可以總結(jié)為以下四點：
- server端：Tomcat NIO + AsyncServlet
- 業(yè)務(wù)流程：獨立線程池，分階段的責(zé)任鏈模式
- client端：Apache HttpClient，同步調(diào)用
- 核心組件：Archaius（動態(tài)配置客戶端），Hystrix（熔斷限流），Groovy（熱更新支持）
圖片
眾所周知，同步調(diào)用會阻塞線程，系統(tǒng)的吞吐能力受 IO 影響較大。
作為行業(yè)的領(lǐng)先者，Zuul 在設(shè)計時已經(jīng)考慮到了這個問題：通過引入 Hystrix，實現(xiàn)資源隔離和限流，將故障（慢 IO）限制在一定范圍內(nèi)；結(jié)合熔斷策略，可以提前釋放部分線程資源；最終達(dá)到局部異常不會影響整體的目標(biāo)。
然而，隨著公司業(yè)務(wù)的不斷發(fā)展，上述策略的效果逐漸減弱，主要原因有兩方面：
- 業(yè)務(wù)出海：網(wǎng)關(guān)作為海外接入層，部分流量需要轉(zhuǎn)回國內(nèi)，慢 IO 成為常態(tài)
- 服務(wù)規(guī)模增長：局部異常成為常態(tài)，加上微服務(wù)異常擴散的特性，線程池可能長期處于亞健康狀態(tài)
圖片
全異步改造是攜程 API 網(wǎng)關(guān)近年來的一項核心工作，本文也將圍繞此展開，探討我們在網(wǎng)關(guān)方面的工作與實踐經(jīng)驗。
重點包括：性能優(yōu)化、業(yè)務(wù)形態(tài)、技術(shù)架構(gòu)、治理經(jīng)驗等。
二、高性能網(wǎng)關(guān)核心設(shè)計
2.1. 異步流程設(shè)計
全異步 = server端異步 + 業(yè)務(wù)流程異步 + client端異步
對于server與client端，我們采用了 Netty 框架，其 NIO/Epoll + Eventloop 的本質(zhì)就是事件驅(qū)動的設(shè)計。
我們改造的核心部分是將業(yè)務(wù)流程進(jìn)行異步化，常見的異步場景有：
- 業(yè)務(wù) IO 事件：例如請求校驗、身份驗證，涉及遠(yuǎn)程調(diào)用
- 自身 IO 事件：例如讀取到了報文的前 xx 字節(jié)
- 請求轉(zhuǎn)發(fā)：包括 TCP 連接，HTTP 請求
從經(jīng)驗上看，異步編程在設(shè)計和讀寫方面相比同步會稍微困難一些，主要包括：
- 流程設(shè)計&狀態(tài)轉(zhuǎn)換
- 異常處理，包括常規(guī)異常與超時
- 上下文傳遞，包括業(yè)務(wù)上下文與trace log
- 線程調(diào)度
- 流量控制
特別是在Netty上下文內(nèi)，如果對 ByteBuf 的生命周期設(shè)計不完善，很容易導(dǎo)致內(nèi)存泄漏。
圍繞這些問題，我們設(shè)計了對應(yīng)外圍框架，最大努力對業(yè)務(wù)代碼抹平同步/異步差異，方便開發(fā)；同時默認(rèn)兜底與容錯，保證程序整體安全。
在工具方面，我們使用了 RxJava，其主要流程如下圖所示。
圖片
- Maybe
- RxJava 的內(nèi)置容器類，表示正常結(jié)束、有且僅有一個對象返回、異常三種狀態(tài)
- 響應(yīng)式，便于整體狀態(tài)機設(shè)計，自帶異常處理、超時、線程調(diào)度等封裝
- Maybe.empty()/Maybe.just(T)，適用同步場景
- 工具類RxJavaPlugins，方便切面邏輯封裝
- Filter
- 代表一塊獨立的業(yè)務(wù)邏輯，同步&異步業(yè)務(wù)統(tǒng)一接口，返回Maybe
- 異步場景（如遠(yuǎn)程調(diào)用）統(tǒng)一封裝，如涉及線程切換，通過maybe.obesrveOn(eventloop)切回
- 異步filter默認(rèn)增加超時，并按弱依賴處理，忽略錯誤
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 {
//同步&無響應(yīng)，繼承此方法
//場景：常規(guī)業(yè)務(wù)處理
protected void processSync(RequestContext context) throws Exception {}
//同步&有響應(yīng)，繼承此方法，健康檢測
//場景：健康檢測、未通過校驗時的靜態(tài)響應(yīng)
protected T processSyncAndGetReponse(RequestContext context) throws Exception {
process(context);
return null;
};
//異步，繼承此方法
//場景：認(rèn)證、鑒權(quán)等涉及遠(yuǎ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) {
//標(biāo)識同步方法，無需額外封裝
return maybe;
} else {
//統(tǒng)一加超時，默認(rèn)忽略錯誤
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();
}
}- 整體流程
- 沿用責(zé)任鏈的設(shè)計，分為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重復(fù)此邏輯
return new ConcattedMaybe(maybe, sources);
} else {
return maybe;
}
}
}
}
return Maybe.empty();
}
}public class ProcessEngine{
//各個階段，增加默認(rèn)超時與錯誤處理
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);
}) //進(jìn)入outbound
.onErrorResumeNext(e -> {
context.setThrowable(e);
return RxUtil.concat(errorTask).flatMap(response -> {
context.resetResponse(response);
return RxUtil.concat(outboundTask);
});
}) //異常則進(jìn)入error，并重新進(jìn)入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)關(guān)層業(yè)務(wù)不涉及請求體body。
因為無需全量存，所以解析完請求頭header后可直接進(jìn)入業(yè)務(wù)流程。
同時，如果收到請求體body部分：
①若已向upstream轉(zhuǎn)發(fā)請求，則直接轉(zhuǎn)發(fā)；
②否則，需要將其暫時存儲，等待業(yè)務(wù)流程處理完畢后，再將其與initial line/header一并發(fā)送；
③對upstream端響應(yīng)的處理方式亦然。
對比完整解析HTTP報文的方式，這樣處理：
- 更早進(jìn)入業(yè)務(wù)流程，意味著upstream更早接收到請求，可以有效地降低網(wǎng)關(guān)層引入的延遲
- body生命周期被壓縮，可降低網(wǎng)關(guān)自身的內(nèi)存開銷
盡管性能有所提升，但流式處理也大大增加了整個流程的復(fù)雜性。
圖片
在非流式場景下，Netty Server端編解碼、入向業(yè)務(wù)邏輯、Netty Client端的編解碼、出向業(yè)務(wù)邏輯，各個子流程相互獨立，各自處理完整的HTTP對象。而采用流式處理后，請求可能同時處于多個流程中，這帶來了以下三個挑戰(zhàn)：
- 線程安全問題：如果各個流程使用不同的線程，那么可能會涉及到上下文的并發(fā)修改；
- 多階段聯(lián)動：比如Netty Server請求接收一半遇到了連接中斷，此時已經(jīng)連上了upstream，那么upstream側(cè)的協(xié)議棧是走不完的，也必須隨之關(guān)閉連接；
- 邊緣場景處理：比如upstream在請求未完整發(fā)送情況下返回了404/413，是選擇繼續(xù)發(fā)送、走完協(xié)議棧、讓連接能夠復(fù)用，還是選擇提前終止流程，節(jié)約資源，但同時放棄連接？再比如，upstream已收到請求但未響應(yīng)，此時Netty Server突然斷開，Netty Client是否也要隨之?dāng)嚅_？等等。
為了應(yīng)對這些挑戰(zhàn)，我們采用了單線程的方式，核心設(shè)計包括：
- 上線文綁定Eventloop，Netty Server/業(yè)務(wù)流程/Netty Client在同個eventloop執(zhí)行；
- 異步filter如因IO庫的關(guān)系，必須使用獨立線程池，那在后置處理上必須切回；
- 流程內(nèi)資源做必要的線程隔離（如連接池）；
單線程方式避免了并發(fā)問題，在處理多階段聯(lián)動、邊緣場景問題時，整個系統(tǒng)處于確定的狀態(tài)下，有效降低了開發(fā)難度和風(fēng)險；此外，減少線程切換，也能在一定程度上提升性能。然而，由于 worker 線程數(shù)較少（一般等于 CPU 核數(shù)），eventloop 內(nèi)必須完全避免 IO 操作，否則將對系統(tǒng)的吞吐量造成重大影響。
2.3 其他優(yōu)化
- 內(nèi)部變量懶加載
對于請求的 cookie/query 等字段，如果沒有必要，不提前進(jìn)行字符串解析
- 堆外內(nèi)存&零拷貝
結(jié)合前文的流式轉(zhuǎn)發(fā)設(shè)計，進(jìn)一步減少系統(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 服務(wù)器會選擇直接拒絕并返回相應(yīng)的狀態(tài)碼。由于這類問題跳過了業(yè)務(wù)流程，因此在統(tǒng)計、服務(wù)定位和故障排查方面會帶來一些麻煩。通過擴展編解碼，讓問題請求也能完成路由流程，有助于解決非標(biāo)準(zhǔn)流量的管理問題。
- 請求過濾
例如 request smuggling（Netty 4.1.61.Final 修復(fù)，2021.3.30 發(fā)布）。通過擴展編解碼，增加自定義校驗邏輯，可以讓安全補丁更快地得以應(yīng)用。
三、網(wǎng)關(guān)業(yè)務(wù)形態(tài)
作為獨立的、統(tǒng)一的入向流量收口點，網(wǎng)關(guān)對企業(yè)的價值主要展現(xiàn)在三個方面：
- 解耦不同網(wǎng)絡(luò)環(huán)境：典型場景包括內(nèi)網(wǎng)&外網(wǎng)、生產(chǎn)環(huán)境&辦公區(qū)、IDC內(nèi)部不同安全域、專線等；
- 天然的公共業(yè)務(wù)切面：包括安全&認(rèn)證&反爬、路由&灰度、限流&熔斷&降級、監(jiān)控&告警&排障等；
圖片
圖片
- 高效、靈活的流量控制
這里展開講幾個細(xì)分場景：
- 私有協(xié)議
在收口的客戶端（APP）中，框架層會攔截用戶發(fā)起的 HTTP 請求，通過私有協(xié)議（SOTP）的方式傳送到服務(wù)端。
選址方面：①通過服務(wù)端分配 IP，防止 DNS 劫持；②進(jìn)行連接預(yù)熱；③采用自定義的選址策略，可以根據(jù)網(wǎng)絡(luò)狀況、環(huán)境等因素自行切換。
交互方式上：①采用更輕量的協(xié)議體；②統(tǒng)一進(jìn)行加密與壓縮與多路復(fù)用；③在入口處由網(wǎng)關(guān)統(tǒng)一轉(zhuǎn)換協(xié)議，對業(yè)務(wù)無影響。
- 鏈路優(yōu)化
關(guān)鍵在于引入接入層，讓遠(yuǎn)程用戶就近訪問，解決握手開銷過大的問題。同時，由于接入層與 IDC 兩端都是可控的，因此在網(wǎng)絡(luò)鏈路選擇、協(xié)議交互模式等方面都有更大的優(yōu)化空間。
- 異地多活
與按比例分配、就近訪問策略等不同，在異地多活模式下，網(wǎng)關(guān)（接入層）需要根據(jù)業(yè)務(wù)維度的 shardingKey 進(jìn)行分流（如 userId），防止底層數(shù)據(jù)沖突。
圖片
四、網(wǎng)關(guān)治理
下所示的圖表概括了網(wǎng)上網(wǎng)關(guān)的工作狀態(tài)。縱向?qū)?yīng)我們的業(yè)務(wù)流程：各種渠道（如 APP、H5、小程序、供應(yīng)商）和各種協(xié)議（如 HTTP、SOTP）的流量通過負(fù)載均衡分配到網(wǎng)關(guān)，通過一系列業(yè)務(wù)邏輯處理后，最終被轉(zhuǎn)發(fā)到后端服務(wù)。經(jīng)過第二章的改進(jìn)后，橫向業(yè)務(wù)在性能和穩(wěn)定性方面都得到了顯著提升。
圖片
另一方面，由于多渠道/協(xié)議的存在，網(wǎng)上網(wǎng)關(guān)根據(jù)業(yè)務(wù)進(jìn)行了獨立集群的部署。早期，業(yè)務(wù)差異（如路由數(shù)據(jù)、功能模塊）通過獨立的代碼分支進(jìn)行管理，但是隨著分支數(shù)量的增加，整體運維的復(fù)雜性也在不斷提高。在系統(tǒng)設(shè)計中，復(fù)雜性通常也意味著風(fēng)險。因此，如何對多協(xié)議、多角色的網(wǎng)關(guān)進(jìn)行統(tǒng)一管理，如何以較低的成本快速為新業(yè)務(wù)構(gòu)建定制化的網(wǎng)關(guān)，成為了我們下一階段的工作重點。
解決方案已經(jīng)在圖中直觀地呈現(xiàn)出來，一是在協(xié)議上進(jìn)行兼容處理，使網(wǎng)上代碼在一個框架下運行；二是引入控制面，對網(wǎng)上網(wǎng)關(guān)的差異特性進(jìn)行統(tǒng)一管理。
圖片
4.1 多協(xié)議兼容
多協(xié)議兼容的方法并不新穎，可以參考 Tomcat 對 HTTP/1.0、HTTP/1.1、HTTP/2.0 的抽象處理。盡管 HTTP 在各個版本中增加了許多新特性，但在進(jìn)行業(yè)務(wù)開發(fā)時，我們通常無法感知到這些變化，關(guān)鍵在于 HttpServletRequest 接口的抽象。
在攜程，網(wǎng)上網(wǎng)關(guān)處理的都是請求 - 響應(yīng)模式的無狀態(tài)協(xié)議，報文結(jié)構(gòu)也可以劃分為元數(shù)據(jù)、擴展頭、業(yè)務(wù)報文三部分，因此可以方便地進(jìn)行類似的嘗試。相關(guān)工作可以用以下兩點來概括：
- 協(xié)議適配層：用于屏蔽不同協(xié)議的編解碼、交互模式、對 TCP 連接的處理等
- 定義通用中間模型與接口：業(yè)務(wù)面向中間模型與接口進(jìn)行編程，更好地關(guān)注到協(xié)議對應(yīng)的業(yè)務(wù)屬性上
圖片
4.2 路由模塊
路由模塊是控制面的兩個主要組成部分之一，除了管理網(wǎng)關(guān)與服務(wù)之間的映射關(guān)系外，服務(wù)本身可以用以下模型來概括：
{
//匹配方式
"type": "uri",
//HTTP默認(rèn)采用uri前綴匹配，內(nèi)部通過樹結(jié)構(gòu)尋址；私有協(xié)議（SOTP）通過服務(wù)唯一標(biāo)識定位。
"value": "/hotel/order",
"matcherType": "prefix",
//標(biāo)簽與屬性
//用于portal端權(quán)限管理、切面邏輯運行（如按核心/非核心）等
"tags": [
"owner_admin",
"org_framework",
"appId_123456"
],
"properties": {
"core": "true"
},
//endpoint信息
"routes": [{
//condition用于二級路由，如按app版本劃分、按query重分配等
"condition": "true",
"conditionParam": {},
"zone": "PRO",
//具體服務(wù)地址，權(quán)重用于灰度場景
"targets": [{
"url": "http://test.ctrip.com/hotel",
"weight": 100
}
]
}]
}4.3 模塊編排
模塊調(diào)度是控制面的另一個關(guān)鍵組成部分。我們在網(wǎng)關(guān)處理流程中設(shè)置了多個階段（圖中用粉色表示）。除了熔斷、限流、日志等通用功能外，運行時，不同網(wǎng)關(guān)需要執(zhí)行的業(yè)務(wù)功能由控制面統(tǒng)一分配。這些功能在網(wǎng)關(guān)內(nèi)部有獨立的代碼模塊，而控制面則額外定義了這些功能對應(yīng)的執(zhí)行條件、參數(shù)、灰度比例和錯誤處理方式等。這種調(diào)度方式也在一定程度上保證了模塊之間的解耦。
圖片
{
//模塊名稱，對應(yīng)網(wǎng)關(guān)內(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)關(guān)在各種技術(shù)交流平臺上一直是備受關(guān)注的話題，有很多成熟的解決方案：易于上手且發(fā)展較早的 Zuul 1.0、高性能的 Nginx、集成度高的 Spring Cloud Gateway、日益流行的 Istio 等等。
最終的選型還是取決于各公司的業(yè)務(wù)背景和技術(shù)生態(tài)。
因此，在攜程，我們選擇了自主研發(fā)的道路。
技術(shù)在不斷發(fā)展，我們也在持續(xù)探索，包括公共網(wǎng)關(guān)與業(yè)務(wù)網(wǎng)關(guān)的關(guān)系、新協(xié)議（如 HTTP3）的應(yīng)用、與 ServiceMesh 的關(guān)聯(lián)等等。
