聊聊云原生数据库的分布式架构本质

近日，跟一用户学习了某数据库，其使用的部署架构如下图，生产中心3副本服务器集群，同城3副本服务器集群，异地3副本服务器集群。单台服务器配置了4块3.84TB NVMe SSD，做VG，LV，但是不做RAID，也没做条带均衡（业务可能就压在某一块盘上，这块盘读写频繁，可能较短时间寿命就写废了），承载了一个系统的子模块，独享这些硬件资源。采用集中架构部署，只有主节点承担交易，节点配置为全能型选手，主节点故障了，可以自动切换到其它从节点，1主8从。

生产中心3台服务器，每台服务器同时部署了代理模块和数据库模块，没有分开，OB是基于表的粒度来分片操作主从写，本次400多张表，写一主8从，数据库是可以基于表级负载均衡到各节点。负载均衡器F5是把流量均匀分发给这三台服务器，如果发现访问的这个表本节点不是主节点，代理模块通过元数据识别主节点是谁，就转发给主节点，绝大部分请求是要转发的。这个就是类似A-A/A架构，对外各节点都是可以访问，但是内部进行转发到此表对应的主节点即工作节点，再写从节点，只是要多转发一次，再写从节点，时延增加一倍。

客户反馈说部署成本太高，就主节点在承担业务，另外8台都闲得很心疼，国产化服务器也不便宜。数据库容量合计就约500GB，但单节点消耗了近15TB空间，3%的利用率，剩余的也用不起来，还有8个从节点资源，都绑在服务器内，利用率太低，也不能再减少盘的数量，晚上跑批压力可能大。服务器是标准配置，采购前很难确定这台服务器要上的系统具体应用需求，就不可避免造成了资源浪费。而且8个从节点16颗CPU在那闲着观看，不是更是浪费吗？

经过跟客户学习，了解清楚某数据库内部架构的本质，称最云原生的分布式数据库，其实也就是存储系统10几年前玩剩下的A-A/A架构，存储厂商是玩真的A-A架构，见下图。另外，成本反而更高再次得到验证，资源管理要精细化，要共享，成为平台，才集约精简，独享一定带来巨大浪费，利用率低，成本反而更高。