云数据库的无服务化

当前，云上服务的无服务化是一个大趋势，在应用程序方面有Lambda，在一些数据分析工具和服务上，AWS也都推出了无服务版本，例如ETL服务Glue，数仓服务Redshift，Hadoop服务EMR，本篇文章针对无服务化的云数据库Aurora Serverless做了一些整理。

提到数据库，我们知道，传统的基于IDC、On-premises的有很多商业的或者开源的数据库，例如Oracle、SQL Server、MySQL、PostgreSQL等，随着云计算的发展，云厂商也都在云上提供了数据库服务，阿里的RDS，AWS的RDS、Aurora，均属于此类。我们谈论数据库的时候，不得不提现代应用的发展，数据库通常来说对最终用户是不可见的，是面向开发人员的底层服务，与应用配套。现代应用的特点，从商业上来说，需要提升客户体验，提高开发人员效率，提升业务敏捷性，提高投资回报率，降低总拥有成本（TCO），从技术角度来说，需要具备扩展到百万/千万用户的能力，全球可用，能够在毫秒级别响应，能够处理PB/EB级别数据量。近十几年，随着应用的复杂度不断提高，微服务也逐渐普及，一个巨大的单体应用，在迭代中不断被拆分成一个一个松散耦合的微服务，微服务与前端之间通过HTTP Restful接口通信，微服务之间通过HTTP/RPC进行通信，也有了如Spring Cloud、Dubbo之类的微服务治理框架。

拿亚马逊电商举例，早在2001年以前，也是一个单体应用（Monolithic application），随着业务的发展，这种架构限制了创新速度和灵活性，每一次新功能和产品的发布，都需要内部充分的协调，在单体应用上修改大量代码，升级时对整个业务也有比较大的影响。2002年开始逐步向微服务架构演变，并用两张披萨团队来改造团队（两张披萨能够喂饱的团队规模来负责一个或几个微服务），拆分组织和应用，得以让亚马逊的创新与业务更加灵活敏捷。截止2020年，亚马逊已经运行有超过10万个微服务，服务间高度解耦合，微服务开发团队可以独立迭代、发布，同时出故障时的爆炸半径可以最小化。

应用程序在云上的部署已经向无服务化（Serverless）演进，从IDC的裸机、到虚拟机、再到容器化、无服务化，实际上对计算资源的划分粒度是越来越细的趋势，我一直拿建筑材料来类比，虚拟机类似于砖块，容器化类似于石子，无服务化则相当于沙子，粒度越细，越容易做到资源的最有效利用，有统计数据显示，传统的裸机，平均负载大概在20%-30%, 虚拟机也仅能达到50%左右，因为购买了机器的企业或个人，很难在24*7的时间段里，都把机器的性能有效利用，如果从全球范围看，这种浪费就相当可观了。无服务化的计算，在AWS上最早推出，叫做Lambda，很多人把这种服务形象的称为FaaS（Function as a Service，对应的有IaaS、PaaS、SaaS），实际就是把一个方法或者叫函数通过Lambda服务快速部署，对外提供服务，无需管理服务器，并且Lambda能根据负载动态伸缩，自动故障恢复，并按量计费（调用次数），这种方式，大大节省了客户的成本，也可以免去复杂的运维，让客户更加专注于业务创新。

随着应用被拆分成一个一个的微服务，应用底层的数据库也需要拆分，传统的集中式的关系型数据库已经难以满足快速交付的需求，应用程序需要专库专用，也就是每个微服务都对底层数据存储和访问有自己的特定需求，拿一个电商系统来举例，搜索框的背后可能是搜索服务，搜索服务的底层很可能是ElasticSearch来提供数据层服务，购物车因为涉及到事务，依旧使用支持ACID的关系型数据库，推荐模块背后可能有图数据库的支撑，用户评价部分可能是键值数据库，总之不同的微服务搭配不同的数据库来满足业务需求是当前的最佳实践。AWS云上针对不同的数据库需求，也都有不同的数据库产品提供，例如关系型数据库有Aurora、RDS，键值数据库有DynamoDB，文档数据库有DocumentDB，内存缓存、内存数据库有Elasticache和MemoryDB，图数据库有Neptune等等。云上的数据库带来了一些好处，比如不用考虑备份还原、安全、合规、故障恢复、补丁、监控、日常维护等琐碎事务，可以专注于数据库的模式设计、查询构建、查询优化等，我们这里所说的「云上数据库」是指预分配资源的数据库（Provisioned），也就是通过在云控制台创建数据库时，需要我们选择实例类型、实例大小，配置副本数量、备份策略等等，可以理解为半自动化的云上数据库服务，而后面要讲的无服务化的云上数据库服务可以称得上是全自动化的云上数据库服务。

为什么云上的数据库服务需要从Provisioned预分配资源的模式走向Serverless无服务化呢？我们拿电商案例来说，我们知道电商有高峰期有低谷期，618和双11尤其明显，如果我们维持较低的数据库配置，则面对高峰期，会面临服务卡顿甚至宕机的可能性，客户体验很差。如果我们按峰值来配置机器容量，成本非常高，很容易理解，双11的单量可能是平时的几百上千倍，如果平时用1台服务器，峰值1000台，我们配置1000台，则在大多数时间里999台服务器的资源都是浪费掉的，因此面对这种可变而且不可预测的工作负载，原先的Provisioned预分配资源的数据库集群很难满足需求，于是Serverlesss数据库服务应运而生，资源选型、资源的自动扩展都由云平台接管，客户可以更加专注业务，相当于「拎包入住」，「用就完了」，再也不用管资源层的事情。

亚马逊Aurora数据库服务从设计上是计算和存储分离的架构，数据6副本，每个可用区2份，写4读3成功返回，一个可用区失效可以保障可写，1个可用区加1个节点失效可以保障可读，另外还有Global database的设计，跨区域的数据同步功能，可以实现跨区域的灾备。Aurora Serverless v1 最早于2018年发布MySQL兼容版本，2019年发布PostgreSQL兼容版本，当时的扩展机制是有一个Warm Pool，池子里有不同实例类型，因为Aurora是计算存储分离的模式，从较小的实例升级到大的实例通过故障转移可以实现（Failover），那么每一次扩容，实际都是一次Failover，这个过程会有5-50秒对服务的影响，并且扩容的粒度较大，每次都是x2倍的扩，对负载变化的响应速度不够敏捷，成本也不够优化。v2版本的Aurora Serverless是2020年预览，2022年初正式发布，它能够在1秒内原地扩展，不会影响正在进行中的事务，扩容的粒度也很细，0.5个ACU（Aurora Capacity Unit），每个ACU代表2GB的内存及计算能力，扩容会根据CPU、内存、网络吞吐的情况自动进行，缩容的速度是v1版本的15倍，也就是瞬时负载的高峰来临时，可以很快在1秒内将数据库的计算能力拉起来，匹配业务负载，高峰过后，哪怕只有几秒的高峰，也能快速缩容，数据库能力的曲线对业务负载曲线有一个很好的贴合，无论从业务响应角度还是成本优化角度都更加理想。

Aurora Serverless的应用场景主要是负载变化难以预测，或者负载变化常常剧烈变动的应用，比如电商、游戏，多租户Saas应用，在应用初次上线时，对未来用户数量和负载无法预估时，通常可以采用无服务数据库，等到用户和负载稳定和规律时，综合评估后也可以采用Provisioned预分配资源的数据库，总体来说，用量曲线平稳的情况下，Provisioned的价格更有优势，用量曲线不平稳，高峰低谷负载差异大的情况，Serverless无服务化的数据库更加体现优势，考虑到目前大多数应用，尤其是互联网应用的负载都很难预估，同时无服务化的数据库还免去了我们选择实例、扩展实例以及一些运维的负担，给客户带来更好的敏捷性、安全性以及相对的低成本，因此无服务化的数据库会是云上服务越来越主流的一个趋势。