<p>作者：辛八</p> 前言
阿里云轻量消息队列（原 MNS）【1】是一款易集成、高并发、弹性可扩展的消息队列服务，助力开发者在分布式组件间高效传递数据，构建松耦合架构。它凭借轻量化架构、高可靠性及动态弹性优势，在业务异步处理、AI 场景（如 LLM 推理调度、GPU 资源调度）中实现规模化应用，服务涵盖零售、金融、汽车、游戏等领域的数千家企业客户。
本文将从开发者视角出发，深入解析轻量消息队列中一项关键能力——“无损发布”的核心优势、技术实现以及实践经验，如果您的业务也有类似需求，本文将为您提供一套经过生产环境验证的实践参考。
- “无损发布”的核心优势与业务价值
（1）核心优势
“无损发布”并非一个新概念，在业内有各种各样的方案。相比之下，轻量消息队列的”无损发布”具备以下几个关键优势：
- 百万 TPS 级无感知、无报错的服务发布：大多数”无损”方案依然会造成一部分流量的业务中断，而本方案经百万 TPS 生产实践验证，在发布过程中，客户侧不会有任何业务中断。
- 兼容存量用户：客户侧无需任何改造，避免”要求客户端升级”这类难以推行的操作。
- 高鲁棒、低维护：方案简洁、鲁棒性强，在不改动架构的情况下无须进行维护。
- 通用性强：可适配绝大多数基于 HTTP 协议的无状态应用。
（2）业务价值
面对发布期间可能出现的分钟级概率性报错，我们不禁会问：是否有必要投入资源去解决？我们的业务是否需要借鉴本文方案进行改造？
通过业务改造前后对比（见下图）可见，实现”无损发布”带来的业务收益远超多数人的预期，下方清晰地展示了其业务价值，为上述问题提供了明确的答案。
接下来，将从开发者视角出发，依次介绍轻量消息队列”无损发布”的网络架构、核心实现以及落地实践。
- 阿里云轻量消息队列”无损发布”方案解析
（1）网络架构
轻量消息队列”无损发布”的网络架构简化模型如上图所示，其设计有以下几个核心点：
- 聚焦网络入口层：对于无状态应用（MNS 实际存在有状态部分，本文暂不涉及），升级过程中只需考虑如何将待发布的应用进行 TCP 连接优雅摘除即可，故重点聚焦于架构的网络入口层。
- 架构通用性强：该架构与大部分 HTTP 业务架构类似，因此具备良好的通用性，可被广泛采用。
- 方案兼容性强：在方案落地过程中，我们遇到了多种不同的部署形态及组件，如 ACK（阿里云 Kubernetes 服务)、ECS 的不同部署形态，LB 多种不同组件的不同版本，ACK 的不同网络架构等。尽管过程中面临诸多挑战，但最终实现了全面兼容，验证了该方案具备组件可替换、通用性好的优点。
- 与应用解耦：该实现与应用解耦，不需要对应用进行改造（注：如不存在 nginx proxy，也可将对应能力移植到应用上），可适用于大多数场景下的应用。
- 客户端无感知：这是本方案的一大优势，仅需在服务侧进行改造即可，Client 无须任何变动，因此可以很好地兼容存量用户。
（2）核心实现流程
轻量消息队列（原 MNS）”无损发布”的核心实现流程如上图所示，简化描述如下：
阶段一：摘除待发布应用的连接
- 步骤一：摘除 TCP 建连请求，且保证残余连接正常转发以及应用正常响应（实现参考下文 4.（1）部分）。
- 步骤二：优雅关闭残余连接（实现参考下文 4.（2）部分）。
阶段二：发布应用
- 步骤三：确认应用已无连接以及请求后，进行发布。
- 步骤四：流量引入发布完成后应用。
在技术方案的设计过程中，我们始终遵循”奥卡姆剃刀法则”：极简的往往最鲁棒、通用，而本实现流程正是这一原则的体现。
在技术方案的落地过程中，尽管轻量消息队列（原 MNS）历史较长，架构、组件情况较为复杂，遇到了多种部署架构（如 K8S、ESC），各类组件（如 client、LB、nginx、kube-proxy）的配置与兼容性等问题，该方案在轻量消息队列（原 MNS）的架构中最终得以成功落地，充分验证了其通用性与鲁棒性。
- 百万 TPS 轻量消息队列”无损发布”实践
（1）摘除 TCP 建连请求
概述
摘除 TCP 建连请求的方式，简单理解就是使用 LB（负载均衡）将对应 RS（后端服务器）摘掉，但要实现真正”优雅”的无损发布（即客户侧无任何报错与感知），需要解决以下几个关键技术问题：
-
如何摘除新建连请求？ — 需要明确摘除 RS 的管控方式，如果基于 API 可能会因为组件依赖导致可迁移性差。
-
如何保证优雅？ — 摘除 RS 后，新建连接请求会被拒绝，但存量 TCP 连接也会因路由规则被移除而中断，从而导致流量受损。
-
如何兼容 K8S 架构？ — 在 K8S 架构下，LB 与 POD 之间多了 kube-proxy 这一网络组件，且这个组件在 ACK 不同网络架构下又有不同表现，该如何兼容？
为了解决以上问题，我们针对 K8S、ECS 架构及不同版本组件，都提出了相应的解决方案。
实现方案
- ECS
- K8S（阿里云容器服务 ACK）
在 ACK 架构下，由于多增加一层 K8S 的网络架构，实现过程经历了较多曲折。最终方案的实现原理涉及 K8S 的 kube-proxy 网络组件，下面的每个配置几乎都是都是经过权衡后的标准化配置。为了简洁说明，下面将重点阐述实现方式。
（2）优雅断连
“优雅断连”指的是在业务无中断前提下关闭 TCP 连接，这一实现是本方案中的核心技术难点，也是最重要的部分。
概述
实现”优雅断连”，我们需要重点关注两个核心点：
-
TCP 连接只能由客户端关闭
- 原因：TCP 网络链路为 client -> LB (-> kube-proxy) -> tengine -> 应用，若断连 LB 下游任一连接，都会导致 client 侧依然认为与 LB 的连接存在，会继续往对应连接发送 http 请求，由于下游连接已中断，从而导致业务中断。
-
不能要求客户升级客户端
- 原因：无法要求所有客户升级，无损改动无意义。
