曹伟是淘宝数据库研发组的成员，前不久他在内部分享了低成本、高性能 MySQL 云数据的架构分析和探索，包括架构的演变过程、系统中的角色和组件等。该文章被褚霸转发在“Erlang 非业余研究”上。
在一开始，曹伟指出：
虽然近两年来 NoSQL 的发展很快，新产品层出不穷，但在业务中应用 NoSQL 对开发者来说要求比较高，而 MySQL 拥有成熟的中间件、运维工具，已经形成一个良性的生态圈等，因此从现阶段来看，MySQL 占主导性，NoSQL 为辅。
接下来，曹伟介绍了他们的工作成果：
我们（阿里集团核心系统数据库团队）……设计和实现了一套 UMP(Unified MySQL Platform) 系统，提供低成本和高性能的 MySQL 云数据服务。开发者从平台上申请 MySQL 实例资源，通过平台提供的单一入口来访问数据，UMP 系统内部维护和管理资源池，以对用户透明的形式提供主从热备、数据备份、迁移、容灾、读写分离、分库分表等一系列服务。平台通过在一台物理机上运行多个 MySQL 实例的方式来降低成本，并且实现了资源隔离，按需分配和限制 CPU、内存和 IO 资源，同时支持不影响提供数据服务的前提下根据用户业务的发展动态的扩容和缩容。
曹伟分析了该系统的架构演变过程：
第一版基于 mysql-proxy 0.8 版修复若干 bug，并对 proxy 插件中管理用户连接和数据库连接的状态机流程进行一些修改，同时编写 Lua 脚本实现去中心数据库获取用户认证信息和后台数据库地址，对用户进行验证，建立到后台数据库的连接和转发数据包等逻辑。
图：UMP 系统第一版架构
他提到第一版的几个问题：
- mysql-proxy 0.8 版对多线程的支持比较简单粗暴，导致几个恶劣后果：
- 造成“惊群”现象，多个线程被唤醒但只有一个线程需要去任务；
- 任务的 CPU 亲缘性比较差，在同一个状态机上触发的事件会在多个处理器上来回切换执行；
- mysql-proxy 中还使用了全局 Lua 锁，同时仅允许一个工作线程执行 Lua 脚本，因此 mysql-proxy 多线程模式下的性能远不能同 CPU 核数保持线性增长，甚至在 16 核上的性能还不如 4 核。
- 以上原因导致单进程模式时，一台物理机上需要部署多个进程才能有效利用机器的处理能力，但给部署、监控和服务的升级带来麻烦。
- 其次，限于 mysql-proxy 的框架，功能上不容易扩展，实现用户的连接数限制、QPS 限制、以及主从切换、读写分离、分库分表等一系列功能比较困难。
- 最后，mysql-proxy 的社区近些年来并不活跃，而且 C 语言对开发者功底的要求比较高，很难要求团队所有成员协同开发出兼顾优雅和正确性的代码。
因此，他们决定用 Erlang 重写，原因在于：
- 和操作系统的进程 / 线程相比，Erlang 进程同样是并发执行的单位，但特别的轻量级，它是在 Erlang 虚拟机内管理和调度的“绿进程”，即用户态进程。
- Erlang/OTP 很好的抽象了开发一个分布式的、高容错性的应用程序所需的要素，包括：网络编程框架、序列化和反序列化、容错、热部署。
在设计当前的 UMP 系统架构时，团队遵循了以下原则：
- 系统对外保持单一入口，对内维护单一的资源池。
- 保证服务的高可用性，消除单点故障。
- 保证系统是弹性可伸缩的，可以动态的增加、删减计算与存储节点。
- 保证分配给用户的资源也是弹性可伸缩的，资源之间相互隔离。
图：UMP 系统现有架构
UMP 系统中有如下角色：
- controller 服务器：向 UMP 集群提供各种管理服务，实现元数据存储、集群成员管理、MySQL 实例管理、故障恢复、备份、迁移、扩容等功能。
- proxy 服务器：向用户提供访问 MySQL 数据库的服务，它完全实现了 MySQL 协议；除数据路由的基本功能外，Proxy 服务器中还实现了资源限制、屏蔽 MySQL 实例故障、读写分离、分库分表、记录用户访问日志的功能。
- agent 服务器：部署在运行 MySQL 进程的机器上，用来管理每台物理机上 MySQL 实例，执行创建、删除、备份、迁移、主从切换等操作，收集和分析 MySQL 进程的统计信息、bin log、slow query log。
- API/Web 服务器：向用户提供了系统管理界面。它们是基于开源项目 Mochiweb 与 Chicago Boss 开发的 Mochiweb 提供 http/https 服务。
- 日志分析服务器：存储和分析 Proxy 服务器传入的用户访问日志，并实现了实时索引供用户查询一段时间内的慢日志和统计报表。
- 信息统计服务器：定期将采集到的用户的连接数、QPS 数值，以及 MySQL 实例的进程状态用 RRDtool 进行统计，可以画图展示到 Web 界面上，也可以为今后实现弹性的资源分配和自动化的 MySQL 实例迁移提供依据。
依赖的开源组件有：
- Mnesia：Mnesia 是 OTP 提供的分布式数据库，支持事务，支持透明的数据分片，利用两阶段锁实现分布式事务，可以线性扩展到至少 50 个节点。Mnesia 更倾向于牺牲可用性来换取强一致性，但它也提供了脏读、脏写操作，可以绕过事务管理去操作数据。
- LVS：实现负载均衡，用户应用重连后会被 LVS 定向到其他的 proxy 上。
- RabbitMQ：提供 UMP 系统中各节点间的通信（不包括 SQL 查询、日志等大数据流的传输，这些还是直接走 TCP 的）
- ZooKeeper：主要发挥配置服务器、分布式锁，以及监控所有 MySQL 实例的作用
对于该系统的作用，曹伟总结到：
在多个组件的协同作业下，整个系统实现了对用户透明的容灾、读写分离、分库分表功能。系统内部还通过多个小规模用户共享同一个 MySQL 实例，中等规模用户独占一个 MySQL 实例，多个 MySQL 实例共享同一个物理机的方式实现资源的虚拟化，降低整体成本。在资源隔离方面，通过 Cgroup 限制 MySQL 进程资源，以及在 proxy 服务器端限制 QPS 相结合的方法，UMP 系统实现了资源虚拟化的同时保障用户的服务质量。此外，UMP 系统综合运用 SSL 数据库连接、数据访问 IP 白名单、记录用户操作日志、SQL 拦截等技术保护用户的数据安全。
对于该系统的应用，曹伟指出：
UMP 系统的一些组件，例如 proxy 服务器和日志分析服务器，目前已经运用在天猫的聚石塔平台中，为电商和 ISV 提供安全的数据云服务。此外，UMP 系统还运用在淘宝的店铺装修平台中，为开发者提供数据服务。下一阶段，我们希望 UMP 系统可以为进一步降低集团内部数据存储的成本做出贡献。
注册/登录 InfoQ 发表评论