文章标题: 阿里云、Amazon、Google 云数据库方案架构与技术分析

新文章标题: 主流云计算平台的云数据库方案架构与技术分析

"一切都会运行在云端"。云时代早已来临，本文着眼于顶级云服务商阿里云、Amazon、Google的云数据库方案背后的架构，以及笔者最近观察到的一些对于云数据库有意义的工业界的相关技术的进展，希望读者能有所收获。

现在越来越多的业务从自己维护基础设施转移到公有（或者私有）云上， 带来的好处也是无需赘述的，极大降低了 IaaS 层的运维成本，对于数据库层面来说的，以往需要很强的 DBA 背景才能搞定弹性扩容高可用什么的高级动作，现在大多数云服务基本都或多或少提供了类似的服务。

Amazon RDS

其实说到公有云上的云数据库，应该最早 Amazon 的 RDS，最早应该是在 2009 年发布的，Amazon RDS 的架构类似在底层的数据库上构建了一个中间层（从架构上来看，阿里云 RDS，UCloud RDS 等其他云的 RDS 服务基本是大同小异，比拼的是功能多样性和实现的细节）。

这个中间层负责路由客户端的 SQL 请求发往实际的数据库存储节点，因为将业务端的请求通过中间层代理，所以可以对底层的数据库实例进行很多运维工作，比如备份，迁移到磁盘更大或者 IO 更空闲的物理机等。这些工作因为隐藏在中间层后边，业务层可以做到基本没有感知，另外这个中间路由层基本只是简单的转发请求，所以底层可以连接各种类型的数据库。

Amazon DynamoDB

对于刚才提到的水平扩展问题，一些用户实在痛的不行，甚至能接受放弃掉关系模型和 SQL。比如一些互联网应用业务模型比较简单，但是并发量和数据量巨大，应对这种情况，Amazon 开发了 DynamoDB，并于 2012 年初发布 DynamoDB 的云服务。其实 Dynamo 的论文早在 2007 年就在 SOSP 发表，这篇有历史意义的论文直接引爆了 NoSQL 运动，让大家觉得原来数据库还能这么搞。

Dynamo 对外主打的特点是水平扩展能力和通过多副本实现（3副本）的高可用，另外在 API 的设计上可以支持最终一致性读取和强一致性读取，最终一致性读取能提升读的吞吐量。

阿里云 DRDS

但是那些 RDS 用户的数据量也是在持续增长的，对于云服务提供商来说不能眼睁睁的看着这些 RDS 用户数据量一大就走掉或者自己维护数据库集群。比如对于 RDS 的扩展方案，我介绍两个比较典型的：第一个是阿里云的 DRDS （不过现在好像从阿里云的产品列表里拿掉了？），DRDS 其实思路很简单，就是比 RDS 多一小步，在刚才提到的 RDS 的中间层中加入用户配置的路由策略，比如用户可以指定某个表的某些列作为 sharding key 根据一定规则路由到特定的实例，也可以垂直的配置分库的策略。

Amazon Aurora

后来时间来到了 2015 年，Amazon 走了另外一条路。在 2015 年，Amazon Aurora 发布。Aurora 的资料在公网上并不多，Aurora 提供了 5x 于单机 MySQL 5.6 的读吞吐能力，不过最大也就扩展到 15 个副本，副本越多对写吞吐影响越大，因为只有一个 Primary Instance 能提供写入服务，单个副本最大支持容量 64T，而且支持高可用以及弹性的扩展。

值得一提的是 Aurora 的兼容性。其实做数据库的都知道，兼容性是一个很难解决的问题，可能实现上很小的差异就会让用户的迁移成本变得很大，这也是为什么中间件和分库分表的方案如此反人类的原因，我们大多都在追求用户平滑的迁移体验。

Google Cloud BigTable

Google 作为大数据的祖宗一样的存在，对于云真是错过了一波又一波：虚拟化错过一波让 VMWare 和 Docker 抢先了（Google 早在十年前就开始容器的方案，要知道容器赖以生存的 cgroups 的 patch 就是 Google 提交的）；云服务错过一波让 Amazon 抢先了（Google App Engine 真是可惜）：大数据存储错过一波让开源的 Hadoop 拿下了事实标准，以至于我觉得 Google Cloud BigTable 服务中兼容 Hadoop HBase API 的决定，当时实现这些 Hadoop API for BigTable 的工程师心中应该是滴血的 :)

Google Cloud Datastore

在 2011 年，Google 发表了 Megastore 的论文，第一次描述了一个支持跨数据中心高可用 + 可以水平扩展 + 支持 ACID 事务语义的分布式存储系统。 Google Megastore 构建在 BigTable 之上，不同数据中心之间通过 Paxos 同步，数据按照 Entity Group 来进行分片。Entity Group 本身跨数据中心使用 Paxos 复制，跨 Entity Group 的 ACID 事务需要走两阶段的提交，实现了 Timestamp-based 的 MVCC。

Google Spanner

虽然 Megastore 慢，但是架不住好用。在 Spanner 论文中提到，2012 年大概已经有 300+ 的业务跑在 Megastore 上，在越来越多的业务在 BigTable 上造 ACID Transaction 实现的轮子后，Google 实在受不了了，开始造一个大轮子 Spanner，项目的野心巨大，和 Megastore 一样，ACID 事务 + 水平扩展 + SQL 支持。

Google F1

在 Spanner 项目开始的同时，Google 启动了另外一个和 Spanner 配套使用的分布式 SQL 引擎的项目 F1，底层有那么一个强一致高性能的 Spanner，那么就可以在上层尝试将 OLTP 和部分的 OLAP 打通。F1 其实论文题目说是一个数据库，但是它并不存储数据，数据都在 Spanner 上，它只是一个分布式查询引擎，底层依赖 Spanner 提供的事务接口，将用户的 SQL 请求翻译成分布式执行计划。

Open source cloud-native database

2016 年在硅谷突然有个新词火了起来 GIFEE，Google Infrastructure For Everyone Else，大家意识到好像随着新一代的开源基础软件的繁荣发展，原来在 Google 内部的基础设施已经有很多高质量的开源实现。

Kubernetes + Operator

刚才提到了一个词 Cloud-Native，其实这个词还没有准确的定义，不过我的理解是应用开发者和物理设施隔离，也就是业务层不需要再去关心存储的容量性能等等一切都可以透明水平扩展，集群高度自动化乃至支持自我修复。

老司机简介

黄东旭，PingCAP 联合创始人/CTO，资深 infrastructure 工程师，擅长分布式存储系统的设计与实现，开源狂热分子，著名的开源分布式缓存服务 Codis 的作者，对于开源文化和技术社区建设有独到的理解。

今日荐文

点击下方图片即可阅读

腾讯QQ团队开源

分布式后台毫秒服务引擎全解析：

引擎架构、RPC、灰度……