DDB Driver模式架构
管理操作以建表为例：
DBA通过DBAdmin的窗口创建表，或者用isql执行建表语句之后，向master发起实际的建表请求，master完成用户认证和合法性校验之后，先在各个数据节点上创建新表，然后将新表元数据记录在系统库中，最后由master将新表元数据同步给各个DBI模块。
对于建表语句中DDB特有的语法，会由isql或dbadmin在解析DDL时完成相应处理，如自增ID的设置。
在DDB中，master用于元数据管理，同步以及报警监控。在DBI模块启动时，会第一时间向master注册，并拉取元数据，之后master对元数据的同步保障了DBI模块元数据的更新。在DBI执行SQL，以及创建DB连接的过程中，不会涉及到与master的交互。
在分库分表中间件中，与DDB Driver模式同样类型的还有阿里TDDL，优势是部署简单，成本较低，容易理解和上手。劣势也非常明显：只支持JAVA客户端，版本难以管理，问题难以追踪，DB连接难以归敛等，另外一点是，中间件与应用绑定在一起，对应用本身是个巨大侵入，而且分库分表的过程是比较耗费CPU资源的，所以在Driver模式下，无论是运维还是性能开销上都存在不可控的因素。
Proxy模式
相比于Driver模式在多语言，版本管理，运维风险上存在的问题，Proxy模式很好地弥补了这些缺陷。所谓Proxy，就是在DDB中搭建了一组代理服务器来提供标准的MySQL服务，在代理服务器内部实现分库分表的逻辑。本质上说，DDB Proxy作为一组独立服务，实现了MySQL标准通信协议，任何语言的MySQL驱动都可以访问，而在Proxy内部，依赖DBI组件实现分库分表，Proxy与DBI的关系如下所示：
DDB Proxy模块简图
应用通过标准数据库驱动访问DDB Proxy，Proxy内部通过MySQL解码器将请求还原为SQL，并由DDB Driver，也就是DBI模块执行得到结果，最后通过MySQL编码器返回给应用。
从上图可以看出，Proxy在DBI上架设了MySQL编解码模块，从而形成独立标准的MySQL服务，而在MySQL编解码模块之上，DDB Proxy也提供了很多特色命令支持，例如：
- show processlist：查看Proxy所有连接状态，与MySQL相关命令高度一致
- show connection_pool：查询Proxy到数据节点的连接池状态
- show topsql..：查询按照SQL模式聚合的各项统计结果，如执行次数，平均执行时间
- . from..：查询过去各个时间段内的吞吐量
此外，DDB Proxy内还提供了slow log等辅助功能，给运维带来很大的便利。
DDB Proxy模式完整架构如下所示：
DDB Proxy模式架构
与Driver模式架构相比，除了QS（DDBProxy的内部称谓，下同）取代了DBI的位置，还在多个QS节点之上部署了LVS或haproxy + keepalived的组合做负载均衡，从而实现多个DDBProxy节点的热备，由于DDBProxy无状态，或者说状态统一由Master同步，在数据库节点没有达到瓶颈时，可以通过简单地增设QS服务器实现服务线性扩展。
私有云模式
在网易私有云项目启动之前，DDB一直以一个个独立集群为不同业务提供服务，不同DDB各自为政毫不相干，这样的好处是业务之间完全隔离，互不影响，不好之处在于随着使用DDB的产品数目不断增多，一个DBA往往同时运维数个甚至数十个DDB集群，而之前我们一直缺乏一个平台化的管理系统，在DBA在各个集群之间应接不暇时，我们没有平台化的统筹运维帮助应用及早发现问题，或是优化一些使用方法。例如版本管理，2013年我们在一个大版本中做了个hotfix，并通知所有DBA将相关的版本进行升级，但是最后由于管理疏漏，有个别集群没有及时上线，为业务带来了损失。当时如果我们有平台化的管理方案，可以提供一些运维手段帮助和提醒运维人员及时更新所有有问题集群，另外，平台化的管理工具也可以定制一些自动化功能，如自动备份，报警组等。