每日一博 | Serverless 的运行原理与组件架构
本文重点探讨下开发者使用 Serverless 时经常遇到的一些问题,以及如何解决
过去一年,我们和大量 Serverless 用户进行了线上和线下的交流,了解大家的业务场景、对 Serverless 的看法和使用体验。
大部分用户认为 Serverless 会是云计算下一阶段的必然趋势,但不是现在。 为什么呢?因为构成 Serverless 架构的云函数尽管有引以为傲的自动扩缩能力,但是糟糕的开发体验、让人畏惧的冷启动、原有业务的改造难题等等,均降低了使用者的信心。
因此,尽管不少用户认可 Serverless 的价值,但依然认为其很难承载核心业务。
针对这些关键问题,腾讯云在今年 6 月份发布了 Serverless 2.0,全面升级了产品形态、系统调度以及开发者工具。为了便于大家理解,我们就从云函数的运行原理作为切入点,以解释问题产生的原因以及云函数的应对方法。
首先,我们看一下云函数,或者说 FaaS 和 IaaS、PaaS 的区别。
如下图所示,FaaS 不仅给用户提供了标准的 Runtime,同时在应用层也帮用户管理了请求的调度。开发者只需要聚焦在核心业务逻辑开发,按照函数的粒度去编写代码。而与底层硬件相关的资源维护,则交给更加专业的云厂商来搞定。
因此,对于用户来讲,可以把更多的精力和时间放在业务上。而 IaaS 和 PasS,则均需要用户去运维云主机或者容器集群、搭建业务所需的运行环境。
其次,我们来看下云函数如何构成 Serverless 架构,以及云函数如何帮助用户做资源管理和请求调度。
在这里我们也将解答云函数的冷启、降低核心业务迁移复杂度等问题。
如下图所示,开发者在实际使用时,可以借助 Web IDE 或者本地 IDE 完成代码开发,然后通过插件、工具等方式把代码及其相关依赖,一起打包部署到云函数平台,用户可以自行选择部署为函数形态或者服务形态。
在代码里,用户需要自己实现业务逻辑,比如访问数据库、对象存储、消息队列、第三方服务接口等。计算逻辑和后端服务共同构成了所谓的 Serverless 应用架构。而终端用户根据平台提供的请求方式,去触发部署在云函数平台上的业务代码,比如发送 http 请求,平台会根据用户的请求量去拉起相应的计算资源运行用户代码。
这里需要重点关注函数形态和服务形态的差异,因为服务的形态可以大大降低复杂业务迁移的成本。
- 服务形态支持直接部署基于框架开发的核心业务,如 Node.js 的 express、koa 等框架,不用为了应用 Serverless 而拆分成函数。平台会帮用户启动服务进程、端口监听,同时服务形态不会限制业务的实际运行时长。
- 函数形态和服务形态在收到用户请求的时候,均能实现自动扩缩。
- 函数形态会针对用户的每个请求都分配一个运行实例,因此所有请求的执行体验是一样的。当没有请求的时候,平台是没有实例在运行的,所以可以做到按需请求,但是这也会造成所谓的冷启动 —— 即当用户的首次请求进入平台的时候,平台会临时拉起资源,而这个过程会消耗一定的时间。为了消除冷启,云函数平台会预先初始化一批不同规格的实例放在资源池中,当用户有请求进入时,可以快速从资源池申请一个实例,直接挂载用户的代码运行,从而降低了资源申请时间。同时,针对函数形态,平台会根据历史并发数据进行预测,帮用户预留一定量的实例,这些实例会预先分配到用户的账号下并且加载好了用户的代码,从而不仅直接消除了冷启,也增加了实例复用几率。
- 而服务形态可以至少帮用户预留一个常驻实例,并且把用户的所有请求都投递到首个实例,根据实例的使用情况,自动的动态扩缩。
- 函数形态更适合新建项目,可以敏捷迭代,业务按照函数的粒度开发,不仅可以轻松实现云上多产品的联动,也可以享受函数的高并发及性能一致体验。服务形态更适合已有项目的迁移、重度复杂业务、需要长时运行的业务。
最后讲讲 Serverless 2.0 的组件架构。
如下图所示,用户虽然只需要关注绿色部分和业务相关的代码实现,但是平台也需要提供强大的开发者工具来保障开发和使用体验。如云函数推出的 Serverless 本地开发工具、VS Code 插件,与 CODING 联合推出的 Web IDE、DevOps 平台等,均能很大程度上提升开发、部署效率,实现本次开发、本地调试、联动云端调试、本地部署、版本发布等能力。
同时,云函数也完善了配套的监控和告警机制,提供如调用次数、内存使用、并发使用、超时、代码错误等多维度的监控和告警能力。这些基础设施、资源管理、安全、容灾等能力,是云函数平台必备的基础能力,也是开发者关心的核心能力。
Serverless 不仅仅是计算,还需要不断完善周边生态。
随着用户量的增加,Serverless 必然会面临更多的挑战 —— 怎么帮助用户组织管理代码,怎么解决带状态的业务诉求,怎么实现数据库连接数管理,怎么实现应用级部署等等。我们也在不断探索和优化用户的使用体验,计划提供诸如 Serverless DB、性能监控、日志分析、Serverless 框架、函数编排、高性能调用等功能。
后续的专栏文章也将陆续解读更多核心能力,帮助开发者更好地理解和使用 Serverless。
Serverless is more!
传送门:
- GitHub: github.com/serverless
- 官网:serverless.com
欢迎访问:Serverless 中文网,您可以在 最佳实践 里体验更多关于 Serverless 应用的开发!
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
百度开源业内首个口罩人脸检测及分类模型
抗击疫情,众志成城,人工智能技术正被应用到疫情防控中来。 2月13日,百度宣布免费开源业内首个口罩人脸检测及分类模型。该模型可以有效检测在密集人流区域中携带和未携戴口罩的所有人脸,同时判断该者是否佩戴口罩。目前已通过飞桨PaddleHub开源出来,广大开发者用几行代码即可快速上手,免费调用。 模型可视化效果:绿框为佩戴口罩标注,红框为未佩戴口罩标注 随着本周各企业相继复工,节后经济开始逐渐恢复,人脸口罩检测方案成为返工潮中众多社区、大型厂商、央企的重要需求。如判断工区员工是否佩戴口罩、人流密集的关口运输中心如何识别戴口罩的人脸并测温、佩戴口罩是否也能完成日常刷脸打卡等等……都是新冠肺炎疫情下需要解决的真实痛点。 此次宣布免费开源的自研口罩人脸检测及分类模型,是基于2018年百度收录于国际顶级计算机视觉会议ECCV的论文PyramidBox研发,可以在人流密集的公共场景检测海量人脸的同时,将佩戴口罩和未佩戴口罩的人脸快速识别标注。基于此预训练模型,开发者仅需使用少量自有数据,便可快速完成自有场景的模型开发。 百度研发工程师介绍,口罩人脸检测及分类模型,由两个功能单元组成,可以分别完成口罩...
- 下一篇
Gitee 已支持 OSI 认证的第二版木兰开源许可 MulanPSL-2.0
在木兰宽松许可证第 2 版(MulanPSL-2.0)通过开源促进会(OSI)认证,成为一个国际化开源许可之后,Gitee 平台目前已经新增了对该版本许可的支持。 此前 Gitee 已经支持 MulanPSL-1.0,此次新增支持的 MulanPSL-2.0 在 MulanPSL-1.0的基础上明确了许可证规范语言。开发者可以通过“许可证向导”轻松选用该许可。 2 月 12 日,中国开源云联盟宣布,木兰宽松许可证第 2 版经过严格审批,正式通过 OSI 认证,被正式批准为国际类别开源许可证(Internationallicenses)。OSI 表示“中文版的开源许可证可以鼓励广大中国社区积极参与开源,同时也是对已批准开源许可证列表的宝贵补充”。 通过 OSI 认证意味着 MulanPSL-2.0 正式具有国际通用性,可被任一国际开源基金会或开源社区支持采用,并为任一开源项目提供服务。同时,木兰宽松许可证是首个由中国开源产业界联合编制并通过 OSI 认证的开源软件许可证,也标志着我国开源界立足中国贡献全球方面取得突破性进展。
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Linux系统CentOS6、CentOS7手动修改IP地址
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS6,CentOS7官方镜像安装Oracle11G
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7,CentOS8安装Elasticsearch6.8.6
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作