每年的11月底到12月初，全世界云计算领域，乃至整个科技产业的目光都会整齐划一地聚焦到拉斯维加斯：全球一年一度最大规模的盛会——亚马逊云科技re:Invent在这里举办。

在11月28日-12月1日的四天时间里，2023亚马逊云科技re:Invent再一次如约而至，带来了这家引领全球云计算风潮与趋势走向的公司对数字技术的最新洞察和应用实践。

开启Serverless之旅

作为Serverless的开创者和引领者，亚马逊云科技不断加大投资，为客户的Serverless之旅保驾护航。以“Road to Serverless”为主题，亚马逊云科技高级副总裁Peter DeSantis开启了当天的主题演讲。在他看来，开始这段旅程最好的地方理应是关系数据库。

从理论上来看，数据库的Serverless必然会大有用武之地。然而由于数据机制以及技术等方面的桎梏，在数据库上实现Serverless一直是非常困难，直到Amazon Aurora。

在Amazon Aurora的诸多创新中，有一项意义重大却又容易为外界忽视的功能，即内部数据库优化分布式存储系统，亚马逊云科技内部将之称为Grover。

Grover允许将数据库和存储本身分开，听起来并不令人印象深刻。表面上看，Amazon RDS使用EBS与存储解耦，EBS所做的几乎与Grover一样。

实际上呢，EBS只是提供了为数据库配置更好实例的能力，而Grover能做的远远不止于此。与Amazon Aurora一样，Grover架构的重点围绕着日志。

作为数据库必不可少的元素，日志记录了数据库里发生的所有事件，用户可以快速运行查询并高效进行交易，而不是确保每一个修改过的内存页面立即被同步。

数据库引擎使用以下方法仔细记录其采取的每一个步骤，一种叫做直接预先记录的技术。得益于此，日志释放了数据库引擎的其余部分，使之专注于性能，同时不必担心保持一致性和耐用性，还可以在任何时间点恢复数据库。

数据库会将每条日志条目发送给Grover，通过将条目复制到多个可用区来记录，Grover保证它们的耐用性和可用性。不过，这也只是Grover强大的一部分。

Grover不只是在存储日志，实际上它是在处理日志，在远程系统创建数据库内部存储器结构的相同副本，这些数据结构可以发回去，在需要时随时访问Amazon Aurora数据库，因此可以将它们加载到数据库的内存中。

这样做的好处，是可以降低主数据库多达80%的I/O需求。与传统数据库不同，Amazon Aurora不再需要将内存页写入，只需要登录Grover存储和处理日志，就可以非常高效地完成工作。

Grover还提供了多个可用区的耐用性，用户无需为应用程序设置数据库。如果某个可用区出现故障，用户可以在其他可用区立即重新启动数据库。

Amazon Aurora还允许用户通过添加副本，轻松地扩大规模。当然，用户也可以使用Serverless扩展数据库存储，因为每个数据库都拥有到Grover的多租户分布式存储服务的访问权限，可以无缝高效地从单一表单扩展到大型数据库。

Amazon Aurora的推出，意味着亚马逊云科技往前迈出了一大步，减少了关系数据库服务满负荷的情况。神奇的Grover，为数据库的Serverless化，打下了必不可少的基础。

百尺竿头再进一步

Grover带来的从0到1的突破固然意义重大，但是仍没有达到亚马逊云科技的最终要求。之所以能够本次推出真正Serverless化的Amazon Aurora Limitless Database，在感谢Grover之外，我们需要首先为同样的幕后英雄Caspian记一大功。

Caspian是亚马逊云科技新开发的一个虚拟层，是跨越新虚拟机管理程序、热能量管理系统的创新组合，并且对数据库引擎进行了一些更改……所有这些创新促成了一系列的定制，能够以毫秒为单位来调整数据库的大小，响应数据库中发生的任何负载变化。

我们来看看一台运行Caspian的实例，与Amazon Nitro有何不同。该实例配备256GB内存，不过其中只有16GB用于数据库，因此Caspian热能量管理系统要求并授权该存储器，让它可以运行多个数据库并且允许这些数据库高效共享底层主机的资源。

与通常不同，由于Caspian的存在，我们获得了虚拟机管理程序的所有安全性和隔离性。那么在数据库需要更多内存时，以上的实例会发生什么变化？

据Peter介绍，Caspian热能量管理系统负责着管理底层物理主机的资源。当数据库想要扩展时，它就必须首先向热能量管理系统发起申请，索要资源。

在有更多资源可用时，热能量管理系统可以简单说“是”，数据库就可以立即扩展。在内存已经耗尽时，热能量管理系统的答复就成了“请稍候”，随即将Caspian实例发送到另一台具有可用容量的物理主机，高速的传输几乎不会对性能造成任何影响。

本质上，Caspian热能量管理系统是在不断预测哪些数据库将需要内存，继而优化队列，根据负载的变化来扩大和缩小规模，提供可扩展的数据库，并高效运行基础架构。

在这个过程中，亚马逊云科技开发的轻量化工具Request Routing Layer，由于身兼快速反应扩充、分区弹性扩充设计等特性，可以保证跨区域的数据库切片与重组，并确保其完整性和可靠性，真正实现了数据库的自动分配和弹性扩充。

就这样，亚马逊云科技向着数据库的Serverless化，又迈进了一大步——不过，这还不是全部。

（在本次大会上，Amazon Aurora Limitless Database正式发布，允许系统每秒高性能地写入数百万个事务，并在单个数据库中管理PB级的数据，为数据库的Serverless化真正指明了方向。）

时间就是无价之宝

“我们还没有完成任务。”Peter说。

前面，我们已经列举和说明过日志对于数据库的重要性。通常情况下，在单一服务器上，日志时间的序列维护非常简单和高效。那么，在分布式数据库中，我们是不是还能够确保日志中的事件以物理时间的先后来严格排序呢？

其实，摆在面前的选项并不多。

第一个是通过一台独立的时间服务器，让所有的数据库与之协调，但是这样做的效率非常低，而且几乎不具备扩展性。其二就是选择使用逻辑时钟，虽然避免了串行时钟的扩展限制，但是分布式逻辑时钟挑战太大。

最后一个笨办法就是通过一个同步的时钟，所有的服务器就都可以与之比较时间戳来对事件进行排序。不过服务器中的时钟每个月偏移差不多一秒，听起来似乎不多，但是已经足以使作为序列号的时间一钱不值。

与此同时，从一台服务器向另一台服务器发送消息所花费的时间各不相同，在不知道这个传播时间的情况下，时钟就不可能被精确同步。

亚马逊云科技采用了“笨”办法，通过最新一代支持自定义硬件的Nitro芯片，根据时间准确同步它们的本地时钟，脉冲由定制的时间同步网络传输。在这样一个架构里，机架顶部是专门的参考时钟，精确的时间来自基于卫星的原子钟，可以在世界上任何地方提供精确到十亿分之一秒误差的同步时钟。此外，每个机架还备有一个本地原子钟，防止那颗卫星暂时不可用。

据介绍，亚马逊云科技在每个可用区都设置了多个以上的时间分配机架。在这个机架下面，安装了专门的时间同步网络，它会分配定时脉冲，其中包括了Nitro片和FPGA，再加上Amazon EC2主机中的专用卡，一起用于实现时间同步网络。

该网络将定时脉冲直接分配给每两台服务器，这个分发的每一步都是在硬件中完成，没有驱动程序、操作系统或网络缓冲区来增加可变量，因此是一个专门定制用来同步时钟的网络。

这就是亚马逊云科技几周以前发布的新版Amazon Time Sync Service，它可以在协调全球时间（UCT）里以非常精准的方式为客户同步处理时钟，不论在世界哪个角落，都能精确到百万分之一秒。

显然，如此精确的时间足以让我们为应用程序事件进行排序、测量单向网络延迟，并提高分布式应用程序的事务速度。在这种情况下，拥有Amazon Aurora Limitless Database，也就意味着客户可以每秒处理成千上万个订单事件……

你敢想象，亚马逊云科技居然为了一个在其他很多厂商看来可能根本不值一提的小小功能上面，花费了如此大的心思和资源，做了如此多的努力与尝试？

事实上，围绕着Serverless的每一步，亚马逊云科技一直致力于为客户提供万无一失的应用环境，不遗漏任何的可能，全面保证客户业务的韧性和可持续性。

说到这个，不由得想起最近一段时间某些大的云服务商和共享服务供应商频繁宕机的事件，不仅影响了诸多云上企业的业务与创新，还让习惯了数字生活的我们吃尽了苦头……

言归正传。

正是这种在Serverless领域的持续创新与不懈探索，亚马逊云科技为企业的应用创新提供了足够强大、足够坚韧、足够安全的平台，不断帮助企业消除无谓的冗余成本，解决业务创新的复杂难题，助力更多企业迈向更大的商业成功。