软件系统架构的设计存在一些通用性的原则和实践，例如众所周知的 C/S、B/S、微服务架构等。以 MySQL 等数据库系统为例，数据访问接口和服务器引擎之间就是典型的 C/S 架构。数据库的服务器引擎通常又可以设计为两个相对分离的大模块：SQL 引擎与存储引擎。从进程/线程结构的角度看，单机的服务器引擎又可以被设计为多进程结构、单进程多线程、多进程多线程、嵌入式函数库等各种形式。

前面提到的都是设计数据库系统的一些常识，但实际上，很多系统是采用类似搭积木的方式来实现的，谈不上对这些设计方向的选择。本文采用不那么严谨的方式，对数据库系统的搭积木方法做一个粗略的分类和总结，希望对理解现有系统有一点帮助。实际上，搭积木的方法也被广泛的用于其他的软件领域。

数据库系统设计的常见套路可以分为：

1. 直接采用某个现成的系统，不做改动或极少改动，例如采用 MySQL 原生版本为基础的各种发行版。有的是从内核、驱动到工具照单全收，有的只做内核的改动。
2. 以某个现成的系统为基础，独立发展为新的系统，例如 MariaDB、Aurora for MySQL。PostgreSQL 系列的可能更多，因为 BSD 协议的限制相对更少，著名的系统有 Greenplum、HAWK 等等。
3. 以某个现成的系统为基础，给它提供重要的扩展模块，例如给 MySQL 做新的存储引擎，典型的有 TokuDB、MyRocks 等。
4. 以多个现有的系统为基础，例如用 PostgreSQL 的 SQL 层加上 InnoDB 等存储引擎。
5. 在现有系统的外围加上代理，例如采用 Proxy + MySQL 扩展为分库分表的系统。
6. 把多个现有的系统整合到一起，例如采用分布式 SQL 引擎加上一个现有的单机系统。这里的组合情况就更多了。
7. 完全重头搞起，自成体系，例如 VoltDB、MemSQL、Spanner 等，部分产品可能因为各种原因会选择兼容 MySQL 或 PostgreSQL 等现有的产品。

设计产品的套路这么多，那么我们怎么判断一个实际的产品采用的是什么套路呢？首先，开源的产品大多比较容易判断，作者会明确的说明系统的设计和来源，只要认真阅读文档就够了；其次，走传统销售路线的商业产品也比较好判断，架构文档和手册都比较完备；再次，云计算类产品可能稍微难判断一些，架构文档和源代码都可能不容易获得；最后，有些产品不仅闭源，手册也未必完善，甚至不同版本采用的是不同的套路，给我们分辨它的架构带来了不必要的困难。