分库分表中间件系统设计

[flycash]

形态

分库分表中间件，从形态上来说可以分成三种：

• 以 SDK 形式提供的
• 以 sidecar 形式提供的
• 以 Proxy 形式提供的

SDK 形态

优点：

• 性能好。本质上它只是一个本地调用，不涉及网络通信之类的问题，所以性能好；
• 实现简单。同理，它的复杂度就只有分库分表的复杂度，不涉及网络通信以及分布式环境下集群治理等的问题。因此代码更加简洁好维护；
• 可观测性好处理。例如接入 logging, tracing 和 metrics 都很简单。大多数时候只需要利用过滤器或者拦截器就可以实现；

缺点也是很明显：

• 语言强相关：例如为 Go 开发的分库分表中间件，就无法用在 Java 语言上；
• 版本升级困难：企业内部难以控制使用唯一一个版本。在有升级或者降级的需求下，难以快速将所有应用的版本都升级或者降级一遍；

以 SDK 形式提供分库分表功能，大多数时候都是以数据库驱动（driver）的形式提供。

sidecar 形式

sidecar 形式是从近几年开始流行起来的，目前来看业界还没有非常成熟的 sidecar 形式的分库分表中间件。sidecar 借鉴了服务治理的思想，即分库分表本身其实和业务是没有什么关系。站在业务层面上来说，它没有分库分表的概念，那么对于普通的业务开发来说，我们也不希望他们被分库分表的各种细枝末节或者注意事项所困扰。

因此希望将分库分表相关的东西完全从应用中剥离出来，做成一个类似于网格 service mesh 的东西。

sidecar 本身的优缺点都介于 SDK 形态和 proxy 形态中间，优点：

• 性能较好：虽然不如 SDK 的形态，但是相比 proxy 性能又要更好一点；
• 不存在集群管理问题：sidecar 都是和应用一起部署，即便考虑到共享的问题，也不需要专门设计集群管理的功能。同时也不存在单点故障或者单点瓶颈的问题；
• 和语言无关：即任何语言都可以使用 sidecar
• 版本管理方便：公司可以统一管理，统一升级或者降级

缺点：

• 可观测性较差：难以将分库分表的过程嵌入到请求的整个执行上下文里面；

Proxy 形态

Proxy 形态和 sidecar 比起来更进一步，它不再是和应用一起部署。大多数时候它都是专门独立部署，并且是部署一个集群。所以相比之下，Proxy 额外引入了集群管理的问题。

优点：

• 可以独立部署和升级

缺点：

• 性能差：proxy 形态有两段网络通信，sidecar 虽然理论上也有两段通信，但是应用到 sidecar 之间的那一段，并不需要经过真实的网络，所以实际上性能很好；
• 集群难管理：proxy 部署了集群之后，就要考虑负载均衡，容错等问题
• 性能瓶颈：如果不启用 proxy 集群，那么 proxy 本身就会成为瓶颈或者单点

架构

三种形态都可以纳入一种统一的抽象之下，即可以把分库分表中间件设计成一个核心 + 三层皮。

其中核心暴露一个统一的接口，它是真实处理查询的地方。三层皮则分别对应三种不同的形态：

• SDK：将核心包装成一个 driver
• sidecar：负责和应用通信，并且调用核心模块
• proxy：负责应用通信，集成集群管理的相关功能，而后调用核心模块完成分库分表的功能

从这三层皮里面又可以看到，sidecar 和 proxy 都要解决一个通信的问题。如果我们考虑使用 socket 来通信，那么就意味着 sidecar 和 proxy 都可以使用同样的 socket 实现的代码。

所不同的是，对于 sidecar 来说，它能使用独有的 UDS 通信，而 proxy 不能。