怎么理解 dbmesh sidecar？

传统的 service mesh 主要由 sidecar 和 控制面构成。如果 service mesh 是支撑起业务对数据库的访问，则称之为 db mesh。

1 数据中间件 vs newsql

很多人以为有了 NewSQL，就没必要再搞分库分表，此大谬也。很多 NewSQL 商业产品处于宣传需要，宣传自己的大数据处理能力，宣传自己的全球跨机房能力，其实吧，某很有名的 NewSQL DB 真实情况是：

• 数据量在 1TB ~ 10TB 之间时，性能马马虎虎，再多就开始拉胯
• 数据多于 450PB，完全跑不动
• 跨机房事故频发，业界没有跨机房使用案例
  • 最根本的瓶颈是那个所谓的全局序列分发器 PD，这个东东跨机房部署后，很容易脑裂，性能又低下，无法满足生产需要
• 到处宣传自己的自动扩缩容能力，但是扩缩容期间很容易造成系统 RT 波动

虽然 NewSQL 可以 hash 或者 range 两种方式自动扩缩容，貌似但是扩缩容期间很容易造成系统 RT 波动，上层应用的稳定性受影响。相比来说，分库分表的数据中间件由于采取的预分配【预先分库分表】机制，不会存在这个问题。

除了上面这个根本区别外，数据中间件的优势如下：

• 多语言
  • 通过支持事实上的 SQL 方言 MySQL 协议，解决了多语言问题
• 多云
  • 同时支持多个云服务厂商，如阿里云、华为云、腾讯云、AWS
• 多机房
  • 以阿里内部为例，生产环境上是每个 DB 集群一般都在一个机房部署，很少跨机房部署，当应用需要跨机房访问多 DB 集群的时候， 是通过数据中间件 tddl 进行跨机房数据访问的
  • 有利于在中间件层面，控制 DB 升级
  • 有利于控制爆炸半径。当一个集群出问题的时候，可以在数据中间件层面迅速切换流量
• 异构 DB 支持
  • 在数据中间件层面支持 Oracle、MySQL、PolarDB、PostgreSQL 等多种 DB，对上层应用屏蔽掉 DB 架构差异
• 更大的数据容量
  • NewSQL 集群单机房部署，支撑的数据量有限，容量太大容易造成集群性能下降。需要更大容量时，往往是通过数据中间件 tddl 访问 多机房多DB集群 实现大容量数据访问。
• 更多的 DB 之上的 feature 的开发
  • 一些功能做到 DB 之中会导致 DB 过于复杂
    • 流量管理
    • 数据安全
    • 分布式 Sequence
    • HTTP --> SQL

2 sidecar vs proxy

sidecar 本质是一个 proxy，但是一种特殊的 proxy：client-side-proxy。service mesh 对 sidecar 这种 proxy 要求更高：

• 1 它跟应用部署在同一个 pod 内，资源使用有限，不能显著地跟同 Pod 内的 app 争抢 cpu、memory、network 等资源；
• 2 整个网络链路延迟不能明显增加；
• 3 对 pod 内的应用来说，把外部的分布式系统幻化为一个本地的单机系统，譬如 db pool 对 app 来说只是一个单机 db；
• 4 进行流量劫持，方便 限流、熔断、分流、tracing 和 安全审计；

从 devops 角度来看，其中最重要一条：sidecar 资源使用。譬如 一般规格的 sidecar 机器资源占用不要超过 2c4g or 4c8g，不要影响 pod 内的 app 性能。但是一个独立的 proxy，它不一样，它可以独立占用一个 pod，用 8c16g or 16c32g 都可以。

数据库是比较重的有状态的应用，2016 年云原生概念刚兴起时，很多大公司都不敢把 数据库部署在虚机或者容器内，其中一个原因是当时虚机或者容器对物理机器性能浪费严重，使得 db 无法充分利用物理机器资源。还有一个原因是，云原生的一个重要特性是 弹性，要求极致快速的扩缩容，而有状态特别是 db 这种重状态系统的扩缩容速度是无法跟无状态应用媲美的。而 dbmesh sidecar 在一定程度上解决了这个问题。

db 应用启动慢占用资源多，可以按照资源池规划预先启动部署。相对 db 来说，占用资源有限的 db sidecar 则是一个近似于无状态的或者称之为若状态的应用，弹性十足：可以进行快速扩缩容。

                                                                                                     20220529  于雨