这里是普通文章模块栏目内容页
我建议你了解一点儿Serverless

一个新技术的出现不是无中生有,从石头中凭空蹦出来的,而是在原有基础上的继承和发展。

我建议你了解一点儿Serverless

Serverless也不例外,我们回顾下IT基础设施的发展,就会发现,Serverless自然就会浮现出来,你自己就可以发明它(但是却实现不了它)。

局域网时代

上世纪90年代,你是一家IT部门的负责人,公司需要建立一个信息管理系统,

这时候的系统都是局域网的, 是C/S模式的, 业务逻辑主要在客户端软件中, 需要被安装到各个电脑上去,然后访问同一个数据库。

我建议你了解一点儿Serverless

在部署这个系统之前,你需要做很多的工作:

搭建局域网, 购买交换机,路由器。

买服务器,安装操作系统,比如Window NT

安装数据库软件,例如Oracle。

然后再把那些Delphi/VB/PowerBuilder写的客户端安装到电脑上, 整个系统跑起来了。

我建议你了解一点儿Serverless

数据中心

C/S模式的很大弊端就是客户端更新特别麻烦,服务器能支撑的用户也不大。

Web兴起后,你们公司的应用也与时俱进,从C/S模式变成了B/S模式,用户主要使用浏览器来访问应用,业务逻辑在服务器端运行。

这时候,你还需要买服务器,然后放到数据中心去托管,毕竟那里的条件更好,更稳定。

网络不需要自己来搭建了, 掏钱买数据中心的网络带宽就好。 还需要自己安装软件, 比如Linux操作系统,Tomcat, Ngnix, MySQL等等。

随着功能的增加,你还需要新的服务器来处理缓存,搜索等功能。 为了应对高并发,还需要分布式,负载均衡,数据复制。

我建议你了解一点儿Serverless

你需要仔细地规划, 看看这些缓存,搜索,数据库, 负载均衡等都需要什么样的服务器,有些要求CPU很强,有些要求内存很大,有些要求硬盘很快。

总之,运维这样一套系统,非常麻烦。

虚拟化

但是,如果你的网站没人访问了,这一套复杂的系统,这些昂贵的服务器就会变成摆设,你想卖都很难卖掉,这是巨大的浪费。

一个想法就会浮现出来:为什么要用物理服务器? 谁要是能提供虚拟机给我就好了! 用完了就可以“扔掉”!

于是那些有实力的大厂就这么做了,把这些物理服务器的计算能力,存储能力统一管理,统一调配,对外提供的就是虚拟机。

他们把这种方式叫做云计算,你使用了云计算以后,有很多好处:

物理服务器不用买了,申请虚拟机就可以了。什么样的CPU, 多少内存,多大的硬盘,对应的价格也不同。

操作系统会按照你的要求自动给你安装好。网络自然不用操心, 要多大带宽直接买就行。

对于PaaS来讲,连运行时环境都安装好了,直接使用就行。

这些虚拟机可以包月,包年计费。但是,如果没有人访问你的应用,没有流量,你也得掏钱。

理想模式

想必你的脑海中已经浮现出了解决方案:

不要再考虑什么物理服务器/虚拟机了, 把代码上传到云端,直接运行。

按使用情况(如CPU时间、内存大小)来收费

(IBM: 我的大机一直按使用情况收费,你们玩了几十年,终于回到我这里了 ^-^)

如果没有人访问你的应用,就不要部署它,这样只会占用一点点存储空间,不用使用CPU和内存;如果有人访问,把应用部署到某个服务器上,执行这次请求,返回给用户,然后卸载这个应用。

和之前的方式相比,最大的特色是即用即走,不会在服务器/虚拟机中常驻。

但是这么做可能吗? 不行,应用的粒度太大,一个应用几十、上百模块,每个请求来了就部署整个应用,只执行那么一点儿代码, 然后就卸载掉。 如果每个请求这么来回地部署和卸载,你是疯了吗,兄弟?

那微服务呢?粒度还是太大 ! 如果是微服务中的一个API,或者说就是一个“函数”呢? 这个粒度应该差不多了。

这里说的函数到底是什么? 需要看具体的业务来划分,比如搜索产品,图像转换, 它需要足够小,足够单一,能快速启动,运行,卸载。

我建议你了解一点儿Serverless

#p#分页标题#e#

一个“函数”真的只做一件事情,并且不保持状态。 这样一来它可以轻松地被扩展到任意多的服务器/虚拟机/docker容器中去。请求多了就扩容,请求少了,就收缩,请求没了,就卸载,实在是太爽了。

这种方式现在称为Serverless,并不是说没有服务器,而是说服务器对用户来说是透明的。 应用的装载、启动、卸载,路由是需要平台来搞定。

Serverless 的特点

Serverless的开发模式和运行模式类似这样:

1. 程序员编写完成业务的函数代码

2. 上传到支持Serverless的平台,设定触发的规则。

3. 请求到来,Serverless平台根据触发规则加载函数,创建函数实例,运行

4. 如果请求比较多,会进行实例的扩展,如果请求较少,就进行实例的收缩。

5. 如果无人访问,卸载函数实例。

如果有多个函数,怎么确定调用哪一个? 肯定需要一个东西来转发一下。

(微服务: 我就是这么玩儿的啊!)

我建议你了解一点儿Serverless

如果业务比较复杂,一个函数搞不定怎么办? 可以把多个函数给编排起来!

(SOA: 我早就这么做了!)

我建议你了解一点儿Serverless

按需装载,自动伸缩,不用你苦逼地去规划硬件,安装软件,还可以按照使用情况付费,这么好的东西,我们是不是马上投入serverless的怀抱?

慢着!

为了达到上面的目标,你必须得牺牲一个很重要的东西:状态。

函数没有状态的,每次启动都可能会被部署到一个全新的“服务器”中,这就有两个问题:

用户的会话状态肯定是无法保持的,像session sticky 这样的功能就别想了。

函数无法做本地的持久化,没法访问本地硬盘的任何东西(服务器看不见了,怎么能看见硬盘呢?)。

所有想持久化的东西必须得保存到外部的系统或者存储中,例如Redis,MySQL等。 很明显,这些东西也应该以“服务”的方式来呈现,即Backend as a Service (BaaS)。

如果你的应用无法拆分成无状态的函数,是无法享受Serverless带来的种种好处的。

Serverless更适合那些无状态的应用,例如图像和视频的加工,转换, 物联网设备状态的信息处理等等。

我建议你了解一点儿Serverless

收藏
0
有帮助
0
没帮助
0