2023 re：Invent上，亚马逊云科技副总裁Peter DeSantis大谈如何构建Serverless服务的话题。

他表示，Amazon S3、Amazon Lambda以及Amazon DynamoDB都属于比较成熟的Serverlss服务，但数据库服务的Serverless程度还不够。

随后的主题演讲环节，Peter DeSantis以关系型数据库的Serverless为例，介绍了亚马逊云科技是如何一步一步提高云服务的Serverlss化程度的。

有意思的是，在解决数据库Serverless化问题时摸索出来的技能，还被用到了其他服务，不得不让人对亚马逊云科技的工程化，产品化实力发出感慨。

数据库Serverless化的初级阶段：Aurora数据库

故事的开始，面对数据库，大家都习惯了自己动手，主打一个事必躬亲。

选择EC2云主机，SSH远程登录，安装配置数据库。日常使用中，会定期做备份，打补丁，偶尔还会升级或者迁移数据库。

如果对性能要求高，还得升级硬件或者设置读写分离。对可用性要求高，还会设置灾难恢复计划。

2009年，亚马逊云科技发布了关系型数据库服务Amazon RDS。Amazon RDS改变了人们在云中设置、管理和扩展数据库的模式。

点几下鼠标就能拥有一台能稳定运行，各个设置像被老师傅开过光的一样好用的数据库，而且自带高可用的属性。

然而，Amazon RDS这种托管服务只是省去了自己管理数据库的麻烦。

为了更进一步，亚马逊云科技在2014年推出了为云优化的Aurora数据库，它与PostgreSQL和MySQL完全兼容，它可以提供更高的性能、可用性、持久性和可扩展性。

Peter DeSantis表示，Aurora最大的创新是其内部的，面向数据库优化的，与日志相关的分布式存储系统，内部叫做“Grover”。

就像Amazon EBS块存储是Amazon RDS的底层存储，Grover则是Aurora的底层存储。但Grover不只是数据库存储，它还可以存储和处理Aurora数据库的日志数据。

众所周知，日志对数据库非常重要，没有日志，关系型数据库会少很多关键功能特性。

事实上，Aurora会将日志都交给Grover管理，Grover利用多可用区来提供持久性和可用性。

与此同时，Grover还会在远程创建一个数据库内部内存结构（Database Internal Memory Structure）的副本，需要的时候，Grover会把它加载到Aurora数据库的内存中。

不同于传统数据库的多步写入过程，Aurora 让 Grover 根据日志进行后续处理，大大减轻了Aurora主数据库引擎的IO压力。

事实上，Grover可以将Aurora 数据库存储系统的IO 减少80%，这是Aurora的性能是开源数据库三到五倍的主要原因。

Grover的引入，让Aurora数据库的存储部分具备了弹性扩展的能力，性能也得到了优化。

而Aurora 也因为支持这些特性，初步具备了一些Serverless服务的特征，可以根据负载变化自动扩展存储容量，而且是无需人工干预的那种方式。

Serverless中等阶段：具备动态资源分配能力的Amazon Aurora Serverless

虽然 Aurora 可以通过添加读副本来提高读性能，但当用户需要更强的写入性能时，还是需要升级一下硬件。

升级硬件问题不大，问题是，要么得关机重启服务器，要么得对数据库进行故障转移，这非常不Serverless！

于是，2018年，亚马逊云科技推出了 Aurora Serverless 。

Aurora Serverless 支持无缝扩展和缩小，当数据库负载发生变化时，无需重启或者故障转移即可进行扩容和收缩。这是怎么做到的呢？

想要具备扩容配置的能力，可以在高配的裸金属服务器上运行数据库。这样虽然获得了扩容的自由，但会很浪费。

为了避免浪费，就得多运行几个数据库，为了安全考虑，还要用Hypervisior技术来做强隔离。然而，Hypervisior在给数据库扩容时也还是要重启。

为了避免重启，亚马逊云科技推出了一个叫Caspian的技术，Caspian使Aurora Serverless数据库能够在几毫秒内调整内存大小，而且无需重启，这种能力就是传说中的动态调整资源能力。

动态调整前，内存占用都比较低

动态调整后，资源被占满了

Caspian的动态资源分配能让数据库服务器随时提升规格，所以，就不需要一开始就分配很多额外的内存容量，能节省很多资源。

可是，当这台服务器上的资源被分配完，还想再继续扩容怎么办呢？

Caspian的做法是将这台物理服务器中的一个实例，迁移到别的有空余资源的服务器上，迁移过程几乎不影响数据库的性能表现。

64GB的数据库服务器被迁移到了别的服务器上

迁移完成后，原来满载主机的就有闲置资源给数据库扩展资源了。同样的，这里也不需要重启，不需要故障迁移，直接动态扩容内存。

更高的连续性，更优雅的操作，Amazon Aurora Serverless在Serverless的道路上又迈进一步。

Caspin进一步提高了Aurora的Serverless程度，但这还是不够。比如，当一台数据库对配置要求特别高，高到物理主机都满足不了的时候该怎么办？

当我们意识到仍受物理服务器大小的限制时，应该知道，这还是不够Serverless。

这时候应该想到数据库Sharding（分片）技术，它可以把数据库“切分”为多个较小、更易管理的切片，把切片散布到多台服务器之后，就可以同时让多台服务器处理负载，以此来提高数据库的性能。

此时，我们就破解了物理服务器大小不够的难题。

然而，数据库切片管理是一个让很多人失眠的问题。

比如，管理分片的时候要能避免某些分片过载而出现性能下降或一致性等问题。又比如，尽量要让相关联的数据存储在同一个分片上，从而减少跨分片查询，提高数据库的处理效率和性能表现。

具体操作层面要做起来确实很麻烦。

你需要自己定义路由和编排层；你需要设置和管理所有分片，这些分片可能会非常多，可能需要根据负载来做出调整；有时候还需要跨多个分片执行事务性操作（比如，更新或插入数据）。

过程中还要随时保持一致性，操作起来会很复杂。

如果不想自己进行这些复杂的操作，可以选择Aurora Limitless Database。

这是2023年re:Invent上最新发布Serverless服务，是亚马逊云科技最高级的Serverless数据库服务，有了它，你可以完全不用管理分片，也不用自己想办法优化性能。

因为，Aurora Limitless Database可以自动扩展到每秒数百万次写入事务，性能上限非常高。

而且，单个数据库管理的数据量能达到不可思议的PB级，这种性能这种容量级别的数据库，定然在分片、分布式架构等方面有不一般的操作。

Peter总结了Aurora Limitless Database的三大创新：

第一个，构建新的请求路由层。

路由层本身采用了轻量化的设计，可以快速扩展，并且通过跨越多个可用区实现高可用。另外，将Aurora 数据库用作路由，从而实现了跨多个分片的复杂查询，并且能汇总查询结果。

第二个，构建了弹性的Serverless分片技术。

它可以自动管理所有的Shards，解决用户自己管理大量分片的挑战。而且，由于每一个Aurora Limitless 数据库的分片都运行在Caspin主机上，这使得每个分片都可以自由扩展和缩小。这就很神奇！

当数据库达到Caspin主机的上限，无法继续扩容

此时，如果当某个数据库分片扩展到非常大，达到了Caspin所能支持的上限的时候，Grover会克隆这个数据库分片。

然后，系统会对这两个数据库分片进行重新分区，最终，将一个大的分片拆分成两个分片。

分片扩容到一定程度就分拆，一眼看过去，全是比较小的数据库分片。总之，弹性的Serverless分片技术化解了大型数据库带来的挑战，让Aurora Limitless数据库具备了超强的弹性和扩展性。

第三个创新，利用高精度时钟同步网络提高了数据库集群的日志记录的效率，进而提升了分布式数据库的TPS性能。

时间同步设备，外号:时间守护者

具体而言，亚马逊云科技构采用Nitro和FPGA芯片在本地构建了超高精度时钟同步网络硬件。

它一方面会接收来自太空卫星上的原子时钟发送的精准时钟信息。另一方面，它在本地服务器集群中发送脉冲信号来精准同步时间。

这套方案解决了服务器的时钟漂移问题。

在一个集群中，如果服务器时钟之间的偏差过大，就无法准确地确定操作的先后顺序。

对于数据库来说，为了确保一致性，就经常得等，直到可以确认一个操作发生在另一个操作之后。当然，等的时间越多，TPS就越低。

此前，亚马逊云科技为了解决EC2集群的同步问题，推出了Amazon Timesync服务，此时的时钟同步精度为1毫秒。

基于新的高精度时钟同步网络，亚马逊云科技推出了新的Amazon Timesync服务，将时钟同步精度提高到了微秒级，于是，数据库的性能也起飞了。

在高精度时钟同步服务的支持下，Aurora Limitless Database现在可以每秒支持数十万的个事件，在大规模分布式数据库集群中，将事务处理的性能提高到了新的高度。

以上内容，介绍了Aurora数据库的Serverless进化之旅。

在三大创新技术的帮助下，Aurora数据库进化到了Serverless数据库的最高阶段，也是目前Serverless化程度最高的云上数据库服务。

看到这里，是不是觉得亚马逊云科技的创新还挺有意思的，甚至有点“上头”？

是的，不只是观众上头，估计亚马逊云科技的人可能也有点上头，于是，他们还把这些精髓用到了Amazon ElasticCache上，对它进行了Serverlss改造。

Amazon ElasticCache是托管的缓存服务，跟Amazon RDS类似，省去了用户自己管理Redis和Memcached这种开源内存数据库系统的麻烦。

然而，想用Amazon ElasticCache的第一步还是选Amazon EC2主机，这很不Serverless。

作为缓存系统或者说内存数据库，其性能表现主要跟内存容量相关。内存小了性能有限，内存大了性能好，但是容易浪费。

于是，如何挑选合适内存大小的主机成了一个难题。

为了解决这个难题，亚马逊云科技想到了Caspian的动态调整资源的能力，根据需求自动调整内存大小，这很Serverless。

对了，这个服务叫做Amazon ElasticCache Serverless，性能不错，内存容量容量上限5TB。有了它，再也不用担心怎么选一台合适的主机搭建缓存服务了。

最后想问一句，为啥Caspian的形象是一只海豹？