所谓 Serverless,你理解对了吗?

随着 DevOps 和微服务的理念日渐被IT业界所接受,另一个新名词 Serverless 也开始进入人们的视野。尤其在今年4月份国内两大云服务厂商阿里云、腾讯云先后推出各自的 Serverless 产品之后,Serverless 一时洛阳纸贵。那到底什么是 Serverless,它跟 DevOps 和微服务又有什么样的联系呢?本文将尝试揭开 Serverless 的神秘面纱,让你一睹为快。

1 Serverless != No Server

首先,必须澄清的是 Serverless 并不能按字面上理解为无服务器,而是说对应用开发者而言,不再需要操心大部分跟服务器相关的事务,比如服务器选购、应用运行环境配置、负载均衡、日志搜集、系统监控等,这些事情统统交给 Serverless 平台即可,应用开发者唯一需要做的就是编写应用代码,实现业务逻辑。为了避免歧义,本文将保留使用 Serverless,而不是其通常的中文翻译无服务器。

Serverless 最早由 Amazon 提出,第一个 Serverless 平台是 2014 年年底推出的 Amazon Lambda,应用开发者只需要上传代码或者应用包,即可发布一个应用。之后全球各大云服务厂商都纷纷推出各自的Serverless平台,比如 Google Cloud FunctionsAzure FunctionsIBM Cloud Functions,以及前面提到的阿里云函数计算腾讯云无服务器云函数等。在云服务厂商之外,开源社区也涌现出很多优秀的Serverless框架,比如Apache OpenWhiskSpring Cloud FunctionLambada Frameworkwebtask等。

根据 Serverless Architectures一文,Serverless 应用可以细分为 BaaS 和 FaaS 两类,

  • BaaS:Backend as a Service,这里的 Backend 可以指代任何第三方提供的应用和服务,比如提供云数据库服务的 FirebaseParse,提供统一用户身份验证服务的 Auth0Amazon Cognito 等。
  • FaaS:Functions as a Service,应用以函数的形式存在,并由第三方云平台托管运行,比如之前提到的 Amazon Lambda,Google Cloud Functions 等。

本文主要讨论的是 FaaS,这也是目前各类 Serverless 平台和框架主要支持的类型。

2 函数即应用

当我们讨论函数时,我们到底在讨论什么?

函数,往大了说可以是一个应用的 main 函数,往小了说也可以是一个简单的加法函数,那到底该如何理解 FaaS 中的函数呢?先来看张图。

左侧的 Monolith 即我们常说的单体应用,中间是微服务,右侧就是 FaaS 中的函数(为了避免歧义,如不特殊指明,下文提到的函数都是指代 FaaS 中的函数)。如同一个单体应用可以按业务模块拆分成多个微服务,一个微服务也可以按使用场景拆分成多个函数。比如一个广告微服务,至少可以拆分出实时竞价、展示计数、报表查询等多个函数。也就是说,FaaS 中的函数和微服务中的 API 是同一粒度的。但不同于 API,在 Serverless 架构下,每个函数都是独立部署,按需执行。那这样的拆分有意义吗?接着往下看。

3 搞懂 Serverless 的 4 把钥匙

和其他架构相比,Serverless 有以下 4 个特点。

3.1 运行成本更低

无论是过去的 IDC,还是如今的云主机,本质上都是一种包月计费模式,也就是说,不管有没有用户访问你的应用,也不管你有没有部署应用,你都要付相同的钱。但对于 Serverless 应用,你只需要根据实际使用的资源量(比如 Amazon Lambda 是按内存大小*计算时间计算资源量)进行付费,也即用多少,付多少,相当于移动网络的按流量计费模式。那为什么说使用这种模式就能降低运行成本呢?

红线以下的长方形面积代表了传统包月计费模式下你所需要支付的成本,而蓝色区域的面积则代表了按流量计费模式下的成本,显然后者要远低于前者。根据福布斯 2015 年发布的一份研究报告,从全年来看,一个典型的数据中心里的服务器平均资源使用率只有可怜的 5% 到 15%,也就是说如果全部使用 Serverless,理论上至少可以节省 80% 的运行成本。

按流量计费的另一个隐藏的好处是任何的性能提升都可以直接的反应到运行成本上,这让技术人员的价值也有了更充分的体现。

3.2 自动扩缩容

Serverless 第二个常被提及的特点是自动扩缩容。前面说了函数即应用,一个函数只做一件事,可以独立的进行扩缩容,而不用担心影响其他函数,并且由于粒度更小,扩缩容速度也更快。而对于单体应用和微服务,借助于各种容器编排技术,虽然也能实现自动扩缩容,但由于粒度关系,相比函数,始终会存在一定的资源浪费。比如一个微服务提供两个 API,其中一个 API 需要进行扩容,而另一个并不需要,那么这时候扩容,对于不需要的API就是一种浪费。

3.3 事件驱动

函数本质上实现的是一种 IPO(Input-Process-Output)模型,它是短暂的,是即用即走的。这点是函数区别于单体应用和微服务的另一个特征。不管是单体应用,还是微服务,都是系统中的常驻进程,套用一句流行语,就是你来或不来,我都在这里,不舍不弃。而函数不一样,既不发布任何服务,没有请求时也不消耗任何资源,只有当请求来了,才会消耗资源进行响应,服务完立刻释放资源。正是由于这一点,函数天然的适用于任何事件驱动的业务场景,比如广告竞价,身份验证,定时任务,以及一些新兴的 IoT 应用。

OpenWhisk 给出的一个 IoT 电冰箱的案例

3.4 无状态性

函数的 IPO 本质决定了函数的另一个特征,无状态性。无状态一方面有助于提高函数的可重用性和可迁移性,但另一方面也带来了一些性能上的损失。第一,函数不是常驻进程,这就意味着每来一个请求,函数都要经历一次冷启动,这对编译型语言编写的应用不啻为一场噩梦(以 Spring Boot 为例,即便是一个最简单的 Hello World 应用,至少也需要 5 秒钟才能启动完毕)。第二,每服务完一个请求,函数所在的进程就会被杀掉,也就是说使用内存进行缓存对函数而言不再有意义。第三,由于每次启动都可能被调度到新的服务器上,任何基于本地磁盘的缓存技术也就不再适用。从第二点和第三点可知,函数只能使用外存(比如 Redis,数据库)进行缓存,而操作外存都需要通过网络,性能跟内存、本地硬盘相比差了一到两个数量级。

4 DevOps => NoOps

如果说 Agile+IaaS 促成了 DevOps,那么 Agile+PaaS 就孕育了 Serverless。

理解了什么是 Serverless,再来看看它和 DevOps 的关系。DevOps 虽然做了很多 Dev 的事,但底牌还是 Ops(好比猫熊虽然长得像猫,但实际上还是熊)。但 Serverless 不同,从本质上说,它是把 Ops 外包给第三方平台,让 Dev 专注于业务逻辑的实现而不用操心 Ops 相关的工作,最终的结果就是绝大多数企业不再需要 Ops 这个岗位。它和 DevOps 最大的共同点就是帮助企业缩短产品上市的时间。

5 参考

0

如何写好产品中的提示文案

产品中的提示文案往往并不显眼,许多人投入精力优化大标题、Slogan,却忽视了产品中无处不在的提示文案。无论是点击按钮的反馈,还是针对一项功能的注释说明,这些文字反而是和用户沟通最频繁的存在,在潜移默化中输出着整体的品牌形象,影响了用户对产品的认知。

不同功能模块往往由不同的人负责,而每个人都有各自的语言风格,长期下来,就会在同一个产品中形成不同风格的提示文案,造成一定的割裂感。因此,有必要提前达成共识,以一个共同的准则去输出产品中的提示文案。

我们往往可以从发声者(Voice)、语言规范(Language)、语调情感(Tone)三个层面来制定一个完整的准则。发声者强调确认产品文案的主体人格,究竟是谁在和用户沟通;语言规范则帮助我们形成简单、易懂、明确的表达方式;而语调情感则是在主体人格确立的前提下,进一步探讨文案的情感表达,是偏活泼或沉稳,偏中立或引导。

一、发声者

发声者是谁

我们首先需要确定的是,在不同情景下,究竟是谁在为产品文案发声。往往我们有三种选择:

  • 一个没有存在感的客观形象:这可能是大多数产品在大多数情景下的选择,将产品认为是一个整体性的客观主体,它尽可能地降低自身的存在感。在这种情境下,产品中多使用「你」作为沟通语言,仿佛是有一个人在和你对话,但这个人并不显露身份,也因此尽可能地避免使用「我们」。
˟需要我们帮你撤回该消息吗?
✓你确认撤回该消息吗?
  • 一个有鲜明人格形象的客观形象:在人格化运营尝试中,我们往往赋予产品以一个鲜明的人格形象,如小管家、小帮手,以拉近和用户的距离感。我们往往会赋予这个形象以具体的姓名、语气、常用语,来进一步强化它的人格特征。
˟你的搜索结果已保存到收藏夹
✓小度已经把搜索结果塞进收藏夹啦
  • 将用户作为主体代入:也有部分产品,尤其是游戏类的应用,往往会舍弃客观形象的存在,而为了给用户营造更强的浸入感,完全使用用户作为表达的主体,仿佛每一句话,都是用户自己的心声。
˟你要攻打这座城池?
✓我要攻打这座城池

不同发声者,可以在一个产品中共存

根据场景不同,不同的发声者,是可以在一个产品中共存的。例如,一个选择客观形象作为主要发声者的产品,在一定情境下,也可以完全转换到第一人称的表达。在某些情境下,我们希望能引起用户强烈的认同感,或者明确操作的自主自愿性,都可以临时转换到第一人称「我」的表达。

˟你同意上传个人资料
✓我同意上传个人资料

不要在一个页面或流程中混入不同的发声者

在同一个表达、页面或流程中,混入不同的发声者,会造成强烈的割裂感,甚至增加理解的复杂度。因此,应该尽可能保持主体的一致性。

˟去「我的设置」修改你的主页可见性
✓去「我的设置」修改我的主页可见性

又比如,在上述同意上传个人资料的操作下,如果想要告知用户,会有专人来审核,下面一行的小字,应该避免如下表达:

˟我们将安排专人审核你的资料,并通知你结果

这样的表达,不仅用户的代入感从「我」又切换回了「你」,在理解中,还额外增加了发声者「我们」和第三方「专人」。我们可以尝试这样的提示:

✓资料经审核后,会通知我结果

二、语言规范

完整的语言规范涉及到了表义规范、写作规范、标点规范、用词规范等等,不一而足,在这里没法面面俱到,就挑几个最重要的说。

提高信息熵

我们常常说,用户没有耐心去仔细阅读我们精心放置的提示文字。很多时候,是我们写得太过啰嗦了。一般来说,在手机屏幕上,超过两行的提示文字,就已经让人不想阅读了。

在写作提示文字时,我们必须尽可能提高信息熵,即在表达信息量相同的情况下,尽可能减少内容量。要做到这一点,不必过于拘束,而可以先把你想表达的意思写下来,再开始精简。

你可能会发现,许多时候可以精简的内容量是惊人的。假设现在我们想告诉用户,他的消息已经发送成功了,我们可能会这么写:

˟你的消息已经发送成功

显然,「你的消息」过于啰嗦了,在实际操作中,用户刚刚发送完一条消息,自然能和这条提示文字对应上,我们可以精简成:

˟已经发送成功

现在,我们再来想一下,我们提示用户这条信息已经发送出去了,成功应该是大概率的情况,如果发送失败,显然我们需要更强烈的引导和提示。那么,「信息已经发送」在理解上和「信息已经发送成功」应该是无差别的。因此,它还可以进一步缩减成为:

˟已经发送

更进一步的,在这句话中,「已经」作为状语,缩写成「已」,不仅语义是一致的,在语感上也没有任何区别(「可以」缩写为「可」常常会产生语感上的区别)。因此,这个提示可以进一步变成:

✓已发送

你看,从最初的 10 个字,已经变成了最后的 3 个字。事实上,只要我们认真审视每句话里面的主谓宾定状补,就总能发现各种精简后并不影响理解和表达的成份。

从目的出发

向用户提示时,就像我们和人沟通一样,表达目的应该先行。用户不应该需要阅读大段的操作性说明,来了解最终可以实现什么目标。相反,应该是获知目标后,再决定是否需要进一步了解。

˟只要提现金额大于 1,000 元,就能当日到账;
✓若想当日到账,提现金额须大于 1,000 元;

使用用户的语言

使用用户的语言和他们沟通,避免使用内部代号、技术性描述等语言。

˟对方服务器没有响应,将重试 POST 该消息,请等待返回结果;
✓发送失败,将尝试重发,请等待;

使用主动语态

在写作提示文字时,如果不是出于特别强调的目的,尽量使用主动语态。简单一点来说,在你的提示文字中,少出现「被」字。

˟密码被输入后,将向对方转账
✓输入密码以完成转账

使用阿拉伯数字

阿拉伯数字在视觉上更加醒目,试试比较下面两句话:

˟若想当日到账,提现金额须大于一千元;
✓若想当日到账,提现金额须大于 1,000 元;

三、语调情感

在明确发声者和语言规范后,我们还应该进一步丰满其形象,通过设立语气、表达方式、常用语等特征,最终映射到品牌或产品形象上。感受一下,下面三种表达,在用户脑海中呈现出的形象,是截然不同的。

小度已经把搜索结果添加到收藏夹
小度已经把搜索结果添加到收藏夹啦
小度已经把搜索结果塞进收藏夹啦

显然,第一种给人的感觉是严肃、平淡的,第二个仅仅通过添加了语气助词「啦」,就让整体形象稍显活泼,第三个在使用了「塞进」这样的表达后,在活泼之余,又增添了一份趣味性。

语调情感并没有绝对的好坏,需要根据产品面向的用户群体和使用场景,来差异化地制定。不过,有一些基本通用的准则,可以供你参考:

产品和用户的关系定位

在产品中指代用户时,使用「你」还是「您」,实际上是产品和用户的关系定位决定的。

在杏仁医生中,由于我们的用户群体是医生,抱以最大的尊重,我们对用户的称谓,一律都是使用「您」的。而在服务患者的微信公众号上,由于平台和用户之间更多的是平等的关系,我们则使用「你」来称呼。

除了人称代词外,确立了关系定位后,还会影响谦词、敬词的使用。感受一下:

对不起,没有找到对应结果,请稍后再试
没有找到对应结果,请稍后再试
没有找到对应结果,你可以稍后再试

使用积极的表达方式

在语言规范中,我们强调多使用主动语态。而在语调情感中,我们则应该多使用积极的表达方式,从肯定视角进行描述。感受一下:

˟上传的头像不要超过 2MB;
✓上传的头像须在 2MB 以内;

除了避免使用否定视角,我们还应该尽可能地突出正面意义,避免恐吓用户。例如:

˟常时间开启高性能模式会加快电量消耗,直至关机
✓为了节省电量,你可以关闭高性能模式

慎用感叹号

感叹号实际上是一个非常强烈的情感表达,你可以想像着如果和用户面对面,会不会这么说话。比如,在针对新用户的提示中,我们使用如下表达来展现我们的热情洋溢,是可以接受的:

✓欢迎来到杏仁医生!

不过,如果是错误提示、操作引导,滥用感叹号,就不免让人觉得有喝斥责怪之感,感受一下:

˟页面已经到底了!
0