正文
我们正处在一个蓬勃发展的云计算 2.0 阶段。在这个阶段，关系型数据库在云托管环境逐渐暴露出一些问题，作为在云计算时代的先行者，Amazon 于 2014 年 11 月 12 日 的 AWS re:Invent 2014 大会，发布 Aurora 云托管关系型数据库就是为了解决这些问题。这个新一代的数据库的发布，也昭示着云计算时代，传统的 IT 技术核心产品将揭开自我进化的序幕。
而 2017 年 SIGMOD 数据大会， Amazon 发布了论文”Amazon Aurora: Design Considerations for High Throughput Cloud Native Relational Databases”, 更加开放的解释了基于云环境的 Cloud-Native 设计的关系型数据库是如何应孕而生的。
在我们回顾了关系型数据库以及云计算的背景之后，我们不难发现, 云计算 1.0 虽然解决了用户和计算的连接的问题，但是还需要进一步解决在一个共享计算的环境下，传统关系型数据库和公有云服务环境的融合问题。
云计算 1.0 用低廉的成本，灵活快速的部署、弹性和扩展能力，获得了传统 IT 计算上云的转换动力。在低成本享受普惠科技成为常态之后，随着用户业务的增长，用户新的痛点开始出现，例如，如何从根本上解决用持续低的成本，享受和传统 IT 计算力一样，甚至更好的云服务，成为迫切需要。
这初看起来像伪命题，仔细分析之后，却淋漓尽致的体现了螺旋式上升的哲学思想。就好像在 PC 服务器涌现的时代，PC 服务器首先用低廉的价格提供了和小型服务器接近的计算能力，然后在保持成本和性价比优势的基础上，实现了超越小型服务器的性能优势，直至终结了小型服务器时代，开始了 PC 服务器时代。
所以说云计算时代还远远没有到达鼎盛时期，除非它通过自身进化演变，在不断保持性价比优势的同时，在具有快速灵活弹性的内在属性基础上，拥有超过传统 IT 计算力的能力之后，云计算才会真正进入它所主宰的时代，这只是个时间问题。
也就是说今天不只是阿里云要做这样一款关系型数据库，而是所有的云计算厂商都不可避免的要经历这样一个阶段。那就是云计算时代传统 IT 计算力的重建和进化！只不过 Amazon 走在了最前面，而阿里云紧跟其后，都需要经历这进化到蜕变的过程。
在这个过程中，新一代关系型数据库是关键的里程碑之一。同理，接下来应该有更多更加高级的云服务，比如智能云操作系统出现，来融合为云时代设计的硬件芯片和网络互联等等。
在 IT 时代，传统的计算力（例如用关系型数据库来处理结构化数据等）是服务于系统硬件隔离环境下的多用户使用场景的。而云计算时代是多客户 Self-Service 租用环境，各种计算负载场景更加复杂，在这种计算负载变迁的环境下，如何解决 IT 时代的技术产物和云计算时代应用环境的适配矛盾，正是云计算自我进化的内在推动力。
例如，在公有云环境下，随着用户的增多，以及用户业务和数据的增长，备份、性能、迁移、升级、只读实例、磁盘容量、Binlog 延迟等相关问题渐渐显现出来。这背后大部分原因是由于 I/O 瓶颈（存储和网络）导致，亟须通过技术革新以及新的产品架构解决这个问题。另一方面，从产品形态来讲，阿里云 RDS 目前的产品形态各具优势，在下一节会详细介绍。
但是从产品架构的发展来看，除去数据库存储引擎的类型之外，对于关系型数据库，考虑到工程效率以及运维成本，最好有一种通用的产品技术架构能兼顾不同用户场景的需求，而不是针对每一个场景都实现一种对应的技术架构。
在接下来的内容，通过讲述阿里云 RDS 的不同产品形态的特点，我们会更加清晰的了解到，PolarDB 的产品形态正是在吸收了之前几种产品形态的优点而孕育而生的。
作为云托管的关系型数据，除了关系型数据库的核心特征之外。PoalrDB 更多的关注于如何提供满足用户业务需求的云服务，并且通过技术革新，不断进化，在提供更好的数据库计算力的同时，满足用户以下业务需求：上云成本、OLTP 性能、业务连续性、在线业务扩展、数据安全。
另一方面云计算除了成本优势之外，弹性和可扩展性也是云计算的天然属性。为了用户业务的扩展，更好的 Scale Up 以及故障恢复，计算和存储分离的架构成为云资源环境更好的选择。这一点将在下一节 RDS 产品架构的演进中得到进一步的诠释。
如上所述，阿里云 PolarDB 和 Amazon Aurora 数据库进化的方向是一致的，然而进化的路径各有不同。本身来讲，这是由于各自的数据库云服务实现方式不同所决定的。阿里云 RDS MySQL 有如下几个版本。这些产品形态满足不同的用户业务场景，具有不同的特点，可以进行优势互补。
MySQL 基础版采用数据库计算节点和存储节点分离的方式，利用云盘数据本身的可靠性和多副本的特性，同时也利用了 ECS 云服务器虚拟化来提升标准化部署、版本和运维的管理效率，能够满足低端用户不太注重高可用服务的业务场景。
