走进RDS说说关系型数据库与Server

关于Serverless

看到如今Serverless在云计算行业喷薄欲出的态势,像极了《星星之火,可以燎原》中的描述:虽然不能预测未来的发展和变化,但对于云计算来说这是个相对确定的方向。

从GoogleTrends的Serverless关键字的趋势可以看到,对于Serverless的搜素一直居高不下,并且在未来的一段时间内也会保持相当的热度。从年开始,以AWS为代表的国外云计算大厂也在不断的布局Serverless相关的产品,AWSLambda、AliyunFAAS,数据库领域的AuroraServerless、RedShiftServerless、AzureSQLDatabase等。

学术界对Serverless的研究热度也不亚于工业界对商业化方案的追求,文末列出了一些相关文章作为参考。对于云计算往Serverless演进的趋势,学术界也经历过一些质疑,年“ServerlessComputing:OneStepForward,TwoStepsBack”[3]文章曾经对Serverless的发展给现在IT基础设施带来的冲击表示过担忧,但年同一拨人在这个方向上又表现出了支持和乐观的态度。从Serverless领域被引用次数较多的论文上看到,主流科研机构对Serverless的趋势和方向研究上趋于一致,研究重点也慢慢从“why”转变为“how”[6]。

何为Serverless?为什么Severless是个趋势?“CloudProgrammingSimplified:ABerkeleyViewonServerlessComputing”[5]这篇文章为代表做了一个比较全面的分析和预测。同样是Berkeley在年发表的另一篇文章“AbovetheClouds:ABerkeleyViewofCloudComputing”[7]预测了云计算作为IAAS基础设施的观点。该篇文章延续了之前的风格,分析了现状和难点,预测了云计算.0的形态Serverless作为下一代基础设施,也定义了Serverless的主要三个特征:

资源的解耦和服务化:弱化了存储和计算之间的联系。服务的储存和计算被分开部署和收费,存储不再是服务本身的一部分,而是演变成了独立的云服务。这使得计算变得无状态化,更容易调度和扩缩容,同时也降低了数据丢失的风险。

自动弹性伸缩:代码的执行不再需要手动分配资源。不需要为服务的运行指定需要的资源(比如使用几台机器、多大的带宽、多大的磁盘等),只需要提供一份代码,剩下的交由Serverless平台去处理就行了。当前阶段的实现平台分配资源时还需要用户方提供一些策略,例如单个实例的规格和最大并发数,单实例的最大CPU使用率。理想的情况是通过某些机器学习算法来进行完全自动的自适应分配。

按使用量计费:Serverless按照服务的使用量(调用次数、时长等)计费,而不是像传统的Serverful服务那样,按照使用的资源(ECS实例、VM的规格等)计费。

值得一提的是[5]这篇文章有众多云计算厂商的背书,包括AWS、Micorsoft、Google、Alibaba等,同时文章也直接以AWSLambda服务作为样板去分析Serverless的问题。Serverless本身的技术难度,这篇文章罗列了多项内容,这里不做赘述,可以具体读一下文章。

关于Serverless的技术实现[3]给出了一个可行的系统实现方式,当然还是以FAAS为背景。其中提到Serverless关键技术路径包括:

统一的标准运行环境支持多语言的运行时统一管理轻量级/蝇量级安全容器(在[4]中额外提到安全和隔离的重要性)冷热容器池设计做极致的多租户复用能力高效的函数调度能力

其中,函数计算的实现方式,却与数据库Serverless息息相关。

数据库的Serverless

数据库品类繁多,关系型数据库自年E.F.Codd对于关系模型的描述[7]开始,后来者大多只是模仿,而尚未在用户接受度和规模上有超越。

数据库不仅仅是一个“stateful”的应用,而且是一个“state-heavy”的应用。数据库是Serverless最不友好的应用之一,包括云原生基础设施kubernates对于stateful应用的支持,也是等到StatefulSet和operator之后才有一个比较好的解决方案。而在这之前数据库都是作为Serverless对状态做解耦和状态下沉的工具,也是全栈Serverless解决方案中最难攻坚的最后一个堡垒。

对于Serverless的定义,文章给出来一个公式:Serverless=FAAS+BAAS。将FAAS(FunctionsasaService)定义为事件、API、消息驱动的计算层;将BAAS(BackendsasaService)定义为类似数据库、消息队列等后端服务。

“State-heavyapplicationswillremainasBaaS”是目前对于数据库的一个基本认知,但这与数据库本身是否具备一定程度的Serveless能力其实是两回事。前者强调的是在应用向Serverless做架构转型的过程当中,数据库的大量状态存储做不到FAAS这样即开即用的能力,只能作为“+”来对接Serverless生态;后者说的是在某种程度上也能够满足“资源解耦”、“自动弹性”、“按使用量付费”的特点,某种程度上也可以认为是Serverless。

数据库Serverless的难点究竟在哪里?

数据库做Serverless有若干难点[4],总结如下:

Serverless没有内置的持久化存储,需要依赖远端存储,这就会导致在延时上较高;客户端是基于连接的方式访问数据库,在客户端往往会维护连接池的方式供应用访问,而函数计算往往具备飘忽不定的网络地址,与数据库传统的IP+User+password鉴权的方式迥异;很多高性能的数据库使用共享内存技术,而FAAS本身不具备共享内存的能力,会使得计算和数据库之前的资源动态扩展能力不一致

其中尤其要注意的是第点,在应用进FAAS之后,当前的数据库访问方式已经不适用于Serverless生态:

服务器与DB做连接保持,这就意味着访问状态是由客户端和数据库共同维护,而FAAS无法做到连接持续保持的能力;服务器通过driver和连接池的方式访问数据库,每次的连接初始化相对较重,FAAS上无法承受如此重的连接初始化工作;服务器访问鉴权通过user/password/ip的方式访问数据库,而FAAS多租户场景所有用户共享IP地址池,user/password内置到FAAS当中也暴露了极大的安全风险;

数据库需要一种新的访问方式,直接影响到数据库能否作为Serverless生态当中的一部分,直接影响到当前Serverless应用做全栈Serverless改造。其重要程度甚至大于数据库Serverless(资源解耦、极致弹性、按使用量付费等)本身。

当然数据库本身要做的事情远远不止如此,数据库本身要实现高效的弹升弹降,涉及到更多的管控和内核紧密的联动。

他山之石

行业翘楚AWS在Serverless相关的布局从年推出Lambda开始,引领着这个方向的发展。这里更多的


转载请注明:http://www.aierlanlan.com/rzdk/5376.html