本文是 serverless 入门与实践 的第7篇, 是学习笔记的第7篇
说说关系型数据库与Serverless
近秋
阿里云开发者
关于serverless
- Serverless相关的产品: 数据库领域的Aurora Serverless、RedShift Serverless、Azure SQL Database等
- 学术界对Serverless的研究热度也不亚于工业界对商业化方案的追求: 从 why -> how
伯克利: 预测了云计算2.0的形态Serverless作为下一代基础设施
- 资源的解耦和服务化
- 自动弹性伸缩
- 按使用量计费
Serverless关键技术路径包括：
- 统一的标准运行环境支持多语言的运行时统一管理
- 轻量级/蝇量级安全容器（安全和隔离的重要性）
- 冷热容器池设计做极致的多租户复用能力
- 高效的函数调度能力
数据库的Serverless
- 数据库: State-heavy -> State-heavy applications will remain as BaaS
数据库做Serverless有若干难点，总结如下：
- Serverless没有内置的持久化存储，需要依赖远端存储，这就会导致在延时上较高；
- 客户端是基于连接的方式访问数据库，在客户端往往会维护连接池的方式供应用访问，而函数计算往往具备飘忽不定的网络地址，与数据库传统的IP+User+password鉴权的方式迥异；
- 很多高性能的数据库使用共享内存技术，而FAAS本身不具备共享内存的能力，会使得计算和数据库之前的资源动态扩展能力不一致
针对第2点, 还需要注意: 连接建立 连接保持 鉴权信息多租户下的安全问题
他山之石
2018 Aurora Serverless V1:
- 以ACU的方式去统一底层的资源，不再对上层暴露底层具体的机型和代数: 1ACU = 2GiB的RAM
- 支持自动启停，在无负载的情况下支持将计算节点降低至“0”
- 数据库弹性过程中内核相关buffer pool等参数随着资源配合的变化而发生变化
- 2019年推出Data API功能，补全了数据库作为BAAS接入FAAS的能力
2020 Aurora Serverless V2:
- 将V1中弹性能力继续提升至秒级
- 去除了V1中关于自动启停的能力，用户可以手动启停实例
- 将弹性缩容的策略做得更加保守，以保证业务压力情况下对业务的影响尽可能小
在开源托管产品上要做到Serverless的能力，要比在云原生自研产品上的难度大很多
未来可期
云的本质是资源的池化
对Aurora Severless未来的发展方向做一些大胆的预测:
- 智能化加持: 让“响应式”扩容升级为“响应式兜底，智能化加持”的双引擎驱动
- 资源解耦和极致的弹性
- 更多的Serverless手段
- 自动的横向扩展能力
- 低成本硬件大规模使用
