彩虹桥架构演进之路性能篇
一、前言
一年前的《彩虹桥架构演进之路》侧重探讨了稳定性和功能性两个方向。在过去一年中，尽管业务需求不断增长且流量激增了数倍，彩虹桥仍保持着零故障的一个状态，算是不错的阶段性成果。而这次的架构演进，主要分享一下近期针对性能层面做的一些架构调整和优化。其中最大的调整就是 Proxy-DB 层的线程模式从 BIO 改造成了性能更好的 NIO。下面会详细介绍一下具体的改造细节以及做了哪些优化。
阅读本文预计需要 20～30 分钟，整体内容会有些枯燥难懂，建议阅读前先看一下上一篇彩虹桥架构演进的文章（彩虹桥架构演进之路）以及 MySQL 协议相关基础知识。
二、改造前的架构
先来复习一下彩虹桥的全景架构图：
图片
Proxy三层模块
针对 Proxy 这一层，可以大致分成 Frontend、Core、Backend 三层：
Frontend-服务暴露层：使用 Netty 作为服务器，按照 MySQL 协议对接收&返回的数据进行编解码。
Core-功能&内核层：通过解析、改写、路由等内核能力实现数据分片、读写分离、影子库路由等核心功能。
Backend-底层DB交互层：通过 JDBC 实现与数据库交互、对结果集改列、归并等操作。
BIO模式下的问题
这里 Core 层为纯计算操作，而 Frontend、Backend 都涉及 IO 操作，Frontend 层使用 Netty 暴露服务为 NIO 模式，但是 Backend 使用了数据库厂商提供的传统 JDBC 驱动，为 BIO 模式。所以 Proxy 的整体架构还是 BIO 模式。在 BIO 模型中，每个连接都需要一个独立的线程来处理。这种模型有一些明显的缺点：
- 高资源消耗：每个请求创建独立线程，伴随大量线程开销。线程切换与调度额外消耗 CPU。
- 扩展性受限：受系统线程上限影响，处理大量并发连接时，性能急剧下降。
- I/O阻塞：BIO 模型中，读/写操作均为阻塞型，导致线程无法执行其他任务，造成资源浪费。
- 复杂的线程管理：线程管理和同步问题增加开发和维护难度。
我们看最简单的一个场景：在 JDBC 在发起请求后，当前线程会一直阻塞直到数据库返回数据，当出现大量慢查或者数据库出现故障时，会导致大量线程阻塞，最终雪崩。在上一篇彩虹桥架构演进文章中，我们做了一些改进来避免了 BIO 模型下的一些问题，比如使用线程池隔离来解决单库阻塞导致全局雪崩的问题。
图片
但是随着逻辑库数量的增多，最终导致 Proxy 的线程数膨胀。系统的可伸缩性和吞吐量都受到了挑战。因此有必要将现有的基于 JDBC 驱动的阻塞式连接升级为采用 NIO（非阻塞 I/O）方式连接数据库。
三、改造后的架构
- BIO->NIO
想把 Proxy 整体架构从 BIO->NIO，最简单的方式就是把传统的 BIO 数据库驱动 JDBC 换成 NIO 的数据库驱动，但是在调研过后发现开源的 NIO 驱动并不多，而且基本上没有什么最佳实践。最后在参考 ShardingSphere 社区之前做的调研后（https://github.com/apache/shardingsphere/issues/13957），决定使用 Vertx 来替换 JDBC。最开始使用 Vert.x 的原因，第一是 Vertx 的异步编码方式更友好，编码复杂度相对较低，第二是因为它实现了主流数据库的驱动。但最终的结果不尽人意，由于 Vertx 相关抽象化的架构，导致链路较长时，整个调用栈深非常夸张。最终压测出来的吞吐量提升只有 5% 不到，而且存在很多兼容性问题。于是推倒重来，决定自研数据库驱动和连接池。
- 跳过不必要的编解码阶段
由于 JDBC 驱动会自动把 MySQL 的字节数据编解码成 Java 对象，然后 Proxy 再把这些结果集经过一些加工（元信息修正、结果集归并）后再进行编码返回给上游。如果自研驱动的话，就可以把编解码流程控制的更细致一些，把 Proxy 不需要加工的数据直接转发给上游，跳过无意义的编解码。后面会介绍一下哪些场景是不需要 Proxy 对结果集进行加工的。
