极客视点
极客时间编辑部
极客时间编辑部
113245 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/06:08
登录|注册

Serverless的两种错误打开方式

讲述:丁婵大小:8.41M时长:06:08
你好,欢迎收听极客视点。
自 2014 年 AWS 发布 Lambda 以来,Serverless 技术的采用率逐年上升。但是,在 Serverless 的应用过程中,开发者发现一些错误的使用方式会让它引发很多问题。
此前,软件工程师萨吉尔·优素福(Sarjeel Yusuf)发文揭示了那些困扰 Serverless 体系架构的反模式以及如何规避他们,从而推动 Serverless 应用的成功,提升其采用率。公众号“架构头条”对原文进行了翻译,极客视点摘录了其中的两点,供你参考。

一、异步特性中的瑕疵

在异步的场景中,Serverless 应用程序往往最合适。
不过,受到追捧的异步特性也是 Serverless 最大的反模式。Serverless 是即付即用的模式,因此当一个 function(Serverless 中,每个函数被称为 function)或者一个服务在等待另一个异步调用的 function 或者服务返回响应结果时,第一个 function 是处在空闲状态的。只需要等待第二个 function 的响应即可。
这是从单体架构转换到无服务架构过程中,不关注细节导致的结果。
每个 function 都有可能会超时,又或者只完成了他们剩余的任务,之后变成空闲状态等待回调。结果就是这个处在空闲状态的 function 也会被收费,因为在技术层面上它是活跃状态的。尽管 function 只是在等待,仍有一个 worker 节点使用所有必需的基础架构为该 function 提供服务。
当很多 function 连接在一起的时候,这个问题会更加严重。在流程中,一个 function 对另一个 function 进行异步调用,等待响应。而第二个 function 对另一个 function 进行调用,又或者在对存储服务进行读写操作。
这大大增加了出现不可靠情况的概率,因为第一个 function 有可能会超时。当函数调用的是云服务供应商之外的存储设备或者本地存储服务时,这个情况有可能会更糟糕。
解决方案
解决方案并不是放弃异步的模式,因为问题的关键点不在于异步调用,而是在于合并此类调用的方式。例如,在分解单体系统时,通常存在控制器的 function,这只会增加不必要的开销,而且还会增大超时带来的 function 不可靠的概率。
在这个例子里面,解决方案很简单,只需要重新考虑控制流程。
可以存在三个执行一般任务的 function,每个 function 都是由流程中的前一个 function 触发。除了 Serverless 之外,在任何平台上面拥有三个单独的 function 都可能会被认为是效率低下的。但是,必须记住的是,在 Serverless 的场景下,成本取决于执行的时长,而不是 CPU 的资源。
可以了解到,异步按照正确的方式来处理时会带来极大的好处。它可以减少执行的时长,同时在必要的地方支持并行化。不过,如果不加考虑,异步不仅会损害系统的需求,而且还会损害 Serverless 的整个收益模型。

二、共享不是收养

使用 Serverless 进行构建的目标是用独立且高度分离的 function,来拆解业务逻辑。不过说起来容易做起来难。而且开发人员经常会遇到必须在 function 之间共享某些库或者业务逻辑,又或者只是一些基础代码的场景。从而导致了某种程度的依赖和耦合关系,违背了 Serverless 架构的初衷。
不同的 function 之间依赖于一些共享的代码和逻辑,会带来一系列的问题。最突出的问题就是影响到了伸缩性。随着系统规模和功能之间不断地相互依赖,错误、停机和延迟的风险成倍增加。
解决方案
在研究解决方案之前,必须要承认的是,在某些场景下可能没有解决方案,不得不共享代码逻辑或者代码库。此类问题出现在机器学习的应用程序中,其中大型库必须在用于处理测试、验证以及训练数据的各种 function 之间共享。在这个过程中需要使用相同的模型,在训练的数据集上进行验证和强化。
在大多数情况下,共享代码库和逻辑需求不仅是一种反模式,而且也同样是 Serverless function 的一种技术限制。例如,AWS 的 Lambda function 在 /tmp 目录下存储上的限制是 512MB。这意味着,开发人员在构建他们 AWS Lambda function 代码的时候,必须要意识到这件事情并且合理运用。毕竟,/tmp 目录主要用于临时存储,因此,一旦 Serverless 节点被移除,/tmp 目录下的内容也会不复存在。
AWS 最近通过发布备受期待的 Amazon EFS 和 AWS Lambda 集成解决了这个问题。这种新的集成方式允许 function 通过集成 Amazon EFS 实例的方式,访问共享的类库或者数据。然而,这不能成为 function 之间相互依赖合理性的一种依据。目前可以实现某些事情并不意味着它是上述反模式陷阱的最佳解决方案,它只是一个最基本而且有效的解决方案,是一个需要不断构建架构意识的起点。
以上就是应用 Serverless 的两种错误打开方式,了解更多 Serverless 的核心知识及应用部署实操可以关注极客时间《Serverless 入门课》,帮助你从运行原理到应用实践一站通关。以下是这个专栏的目录,供你参考。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

精选留言

由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论
显示
设置
留言
收藏
10
沉浸
阅读
分享
手机端
快捷键
回顶部