本文介绍了携程机票前端基于Server-Sent Events(SSE)实现服务端推送的企业级全链路通用技术解决方案。深入探讨 SSE 技术在应用过程中包括方案对比、技术选型、链路层优化以及实际效果等多维度的技术细节,为类似使用场景提供普适性参考和借鉴。该方案设计目标是实现通用性,适用于各种网络架构和业务场景。
一、概述
在如今互联网应用中,实时数据推送已成为很多业务场景的关键技术解决方案。携程机票业务作为在线旅游行业的核心场景,面临着航班数据实时性要求高、信息维度复杂等挑战。Server-Sent Events(SSE)技术作为一种基于 HTTP 长连接的服务器推送方案,非常适用于机票业务"服务端主动推送、客户端实时展示"的需求特点。相较于 WebSocket 等双向通信协议,SSE 在实现简单性、协议轻量级和浏览器兼容性等方面具有显著优势,适合机票列表页这类以服务端数据为主导的业务场景。
二、SSE介绍
2.1 SSE 是什么?
Server-Sent Events(SSE)服务器发送事件,是一种基于 HTTP 长连接,允许服务器单向实时推送数据到客户端的技术。
SSE 的工作原理非常简单直观。客户端通过与服务器建立一条持久化的 HTTP 连接,然后服务器使用该连接将数据以事件流(event stream)的形式发送给客户端。这些事件流由多个事件(event)组成,每个事件包含一个标识符、类型和数据字段。客户端通过监听事件流来获取最新的数据,并在接收到事件后进行处理。
2.2 SSE 的使用场景
SSE 使用场景非常广泛,大家熟知的 Chatgpt 对话的交互形式使用的就是 SSE 技术。SSE 在服务器单向实时推送数据的场景非常适用:
三、应用实践
机票前端首次在核心业务中(机票航班列表)使用 SSE 技术,机票列表页由原先客户端串行请求获取多批次航班数据变为一次请求由服务持续推送数据给客户端。在调研了公司内外各种实现方案,最终联合携程框架、SRE、机票前后端团队共同实现了全公司通用的SSE技术解决方案(详情见下文中的全链路支持部分)。
使用 SSE 前(如下图)
这样的流程和技术方案无疑会提升前后端的代码复杂度,服务端需要额外增加一层缓存来提升响应时间,客户端无法感知服务到底有多少批次数据,需要不断问询。
使用 SSE 后(如下图)
客户端发送一次 SSE 请求,服务端实时推送数据到客户端,服务间上下游同样采用流式传输,实现客户端到服务端全链路流式通信。
SSE 为前后端带来的价值
SSE 对性能有提升吗?
通过分析请求流程(建立链接 -> 发送请求 -> 响应数据传输)和其原理,发现 HTTP 1.1 和 2 支持链路复用,因此链接建立的次数本质上没有变化。在传输通道和数据压缩方式保持不变的情况下,响应数据传输的耗时也不会有明显变化。
SSE 的核心性能优势在于减少了请求发送的次数,其性能增益取决于具体的使用场景:
使用 SSE 与传统串行请求的性能实验数据对比:
四、方案对比
目前市面上很多服务端推送的技术解决方案:SSE、轮询/串行、Websocket 等,我们从易用性,资源开销,使用场景等多维度对比了几个使用较多的主流方案,最终选择了 SSE。
4.1 服务端推送(SSE、轮询、Websocket)
SSE 使用
简单几行代码实现服务端推送
数据传输格式
SSE 的数据传输规范中有 4 个关键字段 event、data、id 和 retry,用于定义和传输事件数据。
even:定义消息的事件类型,客户端可以根据事件类型触发不同的处理逻辑。
data:消息的主体内容
id:为消息设置一个唯一的 ID,用于客户端断线重连时标识最后接收的消息。
retry:服务端指定客户端在连接断开后重新连接的时间间隔(单位为毫秒)。
这些字段共同构成了 SSE 消息的基本格式,每条消息以两个换行符 \n\n 结束,确保客户端能够正确解析和处理事件数据。
前端使用样例
// 创建 EventSource
const evtSource = new EventSource("接口地址");
// 监听服务端推送的数据
evtSource.onmessage = function (event) {
console.log("接收到的消息:", event);
};
// 监听连接建立
evtSource.onopen = function () {
console.log("连接已建立");
};
// 监听报错
evtSource.onerror = function (err) {
console.error("发生异常:", err);
};
服务使用样例(以 Nodejs 为例)
const http = require("http");
http
.createServer((req, res) => {
// 设置Response Header
res.writeHead(200, {
"Content-Type": "text/event-stream",
"Cache-Control": "no-cache",
Connection: "keep-alive",
});
// 不断推送数据给客户端
const pushData = setInterval(() => {
res.write(data);
}, 1000);
req.on("close", () => clearInterval(pushData));
})
.listen(3000);
4.2 内部SSE实践方案
调研发现公司内部有两套实践方案:
通用性:绕开公司链路层,没有通用性。
完整度:轮询位置发生变化,并未实现全链路的流式通信。
在携程企业级网络生态架构下,从通用性和完整度分析对比了两套方案,并没有真正意义上从前到后打通整条链路。仅仅只是简单接入SSE是远远不够的,离不开全链路(SSE技术选型,多层网络架构的适配,服务间的流式通信等等)的支持,所以最终决定联合携程框架、SRE、机票前后端团队共同来实现对SSE全链路的适配,真正意义上实现全公司通用的普适方案。
4.3 SSE 技术选型(原生 SSE vs fetch-event-source)
确定好整体技术方案后,我们在实际测试过程中发现了 2 个 Web 原生 SSE 的局限性问题:
1)仅支持 Get 请求:对需要传递一些复杂请求体的场景不友好。
2)不支持自定义 http header:无法支持自定义 header 透传,鉴权等场景,目前市面大部分解决方案是使用 Cookie 来携带自定义参数。
针对上述问题,调研发现微软开源的 SSE 网络库 @microsoft/fetch-event-source(以下简称 fes)能够很好的解决。fes 是基于 Fetch 和 ReadableStream 来实现的 SSE 功能,旨在提供更加灵活便利的调用方式。
原生 SSE 和 fes 的对比
fetch-event-source 详解
fes 的核心原理是通过 Fetch 发送请求,ReadableStream 读取响应流,在 JS 侧实现字节流数据的解析。通过对比原生 SSE(chromium 内核中 EventSource)和 fes 的代码,发现整体流程与实现方案大致相同,关键区别在于流的解析,原生 SSE 在浏览器内核由 C++实现,fes 在 JS 侧实现。
fes 的流解析
核心方法:getBytes、getLines 和 getMessages
getBytes:通过 ReadableStream 读取响应字节流,获取每个字节块。
getLines :将 getBytes 获取到的字节块解析为 EventSource 行缓冲区,处理这些字节块并解析为行,然后调用 onLine 回调函数处理每一行。
getMessages:创建 EventSourceMessage 对象,将行缓冲区数据解析并进行组装,处理完成后回调给调用方。
export async function getBytes(stream: ReadableStream<Uint8Array>, onChunk: (arr: Uint8Array) => void) {
const reader = stream.getReader();
let result: ReadableStreamDefaultReadResult<Uint8Array>;
while (!(result = await reader.read()).done) {
onChunk(result.value);
}
}
export function getMessages(
onId: (id: string) => void,
onRetry: (retry: number) => void,
onMessage?: (msg: EventSourceMessage) => void
) {
let message = newMessage();
const decoder = new TextDecoder();
// return a function that can process each incoming line buffer:
return function onLine(line: Uint8Array, fieldLength: number) {
if (line.length === 0) {
// empty line denotes end of message. Trigger the callback and start a new message:
onMessage?.(message);
message = newMessage();
} else if (fieldLength > 0) { // exclude comments and lines with no values
// line is of format "<field>:<value>" or "<field>: <value>"
// https://html.spec.whatwg.org/multipage/server-sent-events.html#event-stream-interpretation
const field = decoder.decode(line.subarray(0, fieldLength));
const valueOffset = fieldLength + (line[fieldLength + 1] === ControlChars.Space ? 2 : 1);
const value = decoder.decode(line.subarray(valueOffset));
switch (field) {
case 'data':
// if this message already has data, append the new value to the old.
// otherwise, just set to the new value:
message.data = message.data
? message.data + '\n' + value
: value;
break;
case 'event':
message.event = value;
break;
case 'id':
onId(message.id = value);
break;
case 'retry':
const retry = parseInt(value, 10);
if (!isNaN(retry)) {
onRetry(message.retry = retry);
}
break;
}
}
}
}
export function getLines(onLine: (line: Uint8Array, fieldLength: number) => void) {
let buffer: Uint8Array | undefined;
let position: number; // current read position
let fieldLength: number; // length of the `field` portion of the line
let discardTrailingNewline = false;
return function onChunk(arr: Uint8Array) {
if (buffer === undefined) {
buffer = arr;
position = 0;
fieldLength = -1;
} else {
buffer = concat(buffer, arr);
}
const bufLength = buffer.length;
let lineStart = 0; // index where the current line starts
while (position < bufLength) {
if (discardTrailingNewline) {
if (buffer[position] === ControlChars.NewLine) {
lineStart = ++position; // skip to next char
}
discardTrailingNewline = false;
}
let lineEnd = -1; // index of the \r or \n char
for (; position < bufLength && lineEnd === -1; ++position) {
switch (buffer[position]) {
case ControlChars.Colon:
if (fieldLength === -1) { // first colon in line
fieldLength = position - lineStart;
}
break;
case ControlChars.CarriageReturn:
discardTrailingNewline = true;
case ControlChars.NewLine:
lineEnd = position;
break;
}
}
if (lineEnd === -1) {
break;
}
onLine(buffer.subarray(lineStart, lineEnd), fieldLength);
lineStart = position; // we're now on the next line
fieldLength = -1;
}
if (lineStart === bufLength) {
buffer = undefined; // we've finished reading it
} else if (lineStart !== 0) {
buffer = buffer.subarray(lineStart);
position -= lineStart;
}
}
}
关于SSE原生流解析 与 fes流解析是不同语言实现的这一点,我们也思考了语言差异对性能的影响,所以对响应数据的解析耗时做了实验,在相同机器和网络环境下,对比了原生 SSE 和 fes 处理数据流的耗时,实验结论是两者在耗时上没有明显差异(毫秒级)。从后续在机票列表页大规模应用后的监控数据上看也印证了这一点。
fes 在使用上更适用于现代 Web 应用和 Node.js 环境,解决了原生 EventSource 的局限性,提供了更丰富的功能和更细粒度的控制。
本文系作者在时代Java发表,未经许可,不得转载。
如有侵权,请联系nowjava@qq.com删除。