关于高性能:Serverless-over-Storage

1次阅读

共计 3545 个字符,预计需要花费 9 分钟才能阅读完成。

什么是 Serverless?

从英文的字面意思,跟 Serverful 比照,看起来如同是无服务器?但这显然不可能,毕竟无论如何,任何的程序最终都要在机器上执行。

要想了解 Serverless,咱们有必要回顾一下咱们通常的 Serverful 服务运行形式。

从 Serverful 到 Serverless 的演变

物理机的应用形式仿佛素来都没有变动,无论是 10 年前,还是当初。典型的流程就是硬件洽购、拆箱、上电、做 Raid、插网线、调整交换机、做全面的配置查看,顺便还得查看一些内存、硬盘、固件的品质等等,因为说不定跑两天就挂了。整个环境上线,就是体力活。

虚拟化

感触到了苦楚,就会促使工程师们去扭转。

曾经辛苦地筹备了硬件,当一个开发小哥须要一台机器的时候,作为 IT 管理人员,难道还要再次反复这个过程?

能够说虚拟化解放了 IT 管理者,通过在一台物理机上运行更多的虚拟机,晋升了资源利用率以达到更好的财务收益之外,虚拟化还给部署以及运行一台“机器”提供了极大的便当。

通过操作系统虚拟化一套硬件,再联合虚拟机模板镜像的机制,意味着在物理机上创立和挪动虚拟机也只是分分钟的事件而已。

以往的机器上线沉重、反复的膂力工作隐没殆尽。

单机的虚拟化无奈满足大规模的场景,包含对调度,网络虚拟化的需要等等。此时,云横空出世,你既能够抉择私有云,也能够抉择本人搭建公有云,如 OpenStack。

甚至你都不须要关怀底层的硬件,只有是通用的架构即可,操作系统、网络、存储等均能够自动化装置、扩大进去。

然而,即便在云时代,应用软件的运行形式也没有变动,无非是软件看到的是一个虚构的硬件环境而已。对于使用者而言,不同的一点只是为软件筹备根底环境的过程变快了。

容器化

只管虚拟化充分利用了资源,极大的进步了便利性,但技术倒退的车轮滚滚向前,工程师们总是得寸进尺。虚拟化仍旧存在比拟“重”的问题,镜像太大,多个虚拟机根本都蕴含反复的操作系统,物理机上无奈运行过多的虚拟机。

容器化,尤其是 2017 年以来 Kubernetes 的风行,又一次带来了扭转。容器只是一个轻量级的过程,而软件提供者只有保护一个 Dockerfile , 生成一个小得多的镜像,在容器平台部署即可。利用的上线不再关怀依赖、抵触,以及诸如“我这里运行没问题,必定是你的环境问题”等等困扰。

Serverless,更容易了解的一个名字是 functions-as-a-service,我想这样起名的一个初衷是让你不再关怀服务器,也不须要思考他们,只有执行你的代码就好。

构想一下即便是在容器化加持的状况下,利用开发者仍然要关注诸如 RestAPI 框架如何搭建、工作流怎么解决、压力来了怎么进行负载平衡、消息中间件如何解决等问题,有可能还要关怀平安降级、破绽扫描这些与业务逻辑关联不大的琐事。

2019,UC 伯克利大学发表了一篇“Cloud Programming Simplified: A Berkeley View on Serverless Computing”的论文 (https://www2.eecs.berkeley.ed… 论文中有一个很形象的比喻,形容如下:

In the cloud context, serverful computing is like programming in low-level assembly language whereas serverless computing is like programming in a higher-level language such as Python. An assembly language programmer computing a simple expression such as c = a + b must select one or more registers to use, load the values into those registers, perform the arithmetic, and then store the result. This mirrors several of the steps of serverful cloud programming, where one first provisions resources or identifies available ones, then loads those resources with necessary code and data, performs the computation, returns or stores the results, and eventually manages resource release. The aim and opportunity in serverless computing is to give cloud programmers benefits similar to those in the transition to high-level programming languages.

那么总结起来什么是 Serverless 呢?其实就是你只须要关怀的业务逻辑,所有其余的全副交给外围所运行的平台工具等去解决。

实现形式

各大公有云有各自的实现形式,例如 AWS Lambda, 阿里的 BatchCompute, Azure Function 等等,但每家都有不同的应用形式,存在 Lock-in 的危险。那么如果在公有环境上实现,有什么抉择呢?

Fn project

Fn project 是 Oracle 开源的一个我的项目,看起来是非常简单间接的,有一个 Docker 即可运行起来。问题就是不够沉闷,半年内仿佛都没有新的 commit。

Kubeless

听起来最正统的名字,是由 Bitnami 奉献的一个我的项目,基于原生的 Kubernetes,通过自定义资源 CRD 的形式来实现,但因为受到 Knative 的影响,前途不太清朗,连创始人都倡议敞开掉这个我的项目。

由 Platform9 奉献的一个我的项目,它既能够利用到 Kubernetes 的丰盛性能,也能够在须要时候取得更好的性能,例如冷启动。这个也是笔者在 Fn project 之后跑起来的第二个我的项目。

Fission

Knative

名门出品,集大成者。Google 开源的我的项目,目前参加的公司次要是 Google、Pivotal、IBM、RedHat, 基于 Kubernetes 以及 Istio。

Serverless Over 存储

阿里王坚博士的《在线》里有一句话说的特地好,“需要才是竞争力”,想到,做到;做到,用到。在与 AI 的同仁交换过程中,压迫整个工作流过程中的每一点性能,都是对整个后果的很大晋升,这不禁促使咱们思考如何能力更加高效的存储和解决数据。

先不提 Computable Storage , 以 AI 的场景为例,AI 作为一种新的数据处理技术,它涵盖了采集、筹备、训练和推理四个阶段,每个阶段都随同着数据的流动以及解决。

数据采集阶段 :数据从不同起源聚拢并存储起来,数据的大小和格局存在各种差别,数据类型往往是文件模式的非结构化数据。

数据筹备阶段 :因为数据的大小和格局不一样,为了便于进行 AI 模型训练,必须改为对立格局,以便后续训练阶段应用,这一过程要对不同格局和尺寸的数据进行规范化解决。

训练阶段 :AI 训练过程的工作负载十分密集,往往须要高性能的 GPU 或者加速器等来执行一系列的数学函数,对资源要求十分高,在做特定训练时,AI 训练所需的工夫更加取决于所部署的存储的性能。

推理阶段 :推理过程是测验人工智能的阶段。推理基础设施依据不同的场景,所需配置的处理器、内存、存储不尽相同。

通常的数据筹备阶段,都是利用 Hadoop 等批量解决工具对数据进行荡涤,在 Hadoop 计算节点与分布式数据存储节点拆散的状况,一个典型的过程就是,读出、计算、写入,意味着数据要流出存储集群,再流入存储集群,是否尽量避免数据的流动,让计算离存储更近一些呢?

基于 Serverless 框架,咱们在 YRCloudFile 的根底上,能够运行更加实用的性能,例如数据复制,数据压缩,数据解压等等更适宜产生在存储端的操作。

以下示例演示了向 Serverless 框架提交一个数据拷贝的申请(函数),让这个申请在后端存储主动执行,提交请求者无需关怀后端数据的处理过程。

利用对应的框架创立 Function 以及 Trigger 之后,只有拜访对应的 URL 即可实现相应的动作。

如果你的动作够快,进入到对应的 Function 容器内,你会看到外面存在的对应的目录对存储的援用。

这只是一个最简略的数据拷贝例子,咱们能够编写更简单的数据处理函数(Function),并间接提交到 Serverless 框架上,由后端的数据存储去针对简单操作实现相应优化和解决。工程师们能够疾速地实现用户须要的性能,甚至能够实现工作流你 Pipeline,从而赋予利用更多可能。

正文完
 0