OceaBase开发者大会落地上海!4月20日共同探索数据库前沿趋势!报名戳 了解详情
写点什么

Serverless 系列(二):运行原理与组件架构

  • 2019-09-04
  • 本文字数:2332 字

    阅读完需:约 8 分钟

Serverless 系列(二):运行原理与组件架构

随着越来越多的开发者开始关注并使用 Serverless 技术,开发者也对 Serverless 提出了更高的要求。上一篇文章中我们已经了解到 Serverless 相关的基本知识以及 Serverless 所带来的一些优势,本文就不再赘述。接下来,我们重点探讨下现阶段,开发者在使用 Serverless 时经常遇到的一些问题,以及腾讯云 Serverless,尤其是云函数为此所做出的一些探索。


在过去一年多的时间里,我和大量的 Serverless 用户做过线上、线下交流,了解他们的业务场景、以及对 Serverless 的看法或者使用上的体验。大部分用户认为 Serverless 会是云计算下一阶段的必然趋势,但不是现在。为什么呢?因为构成 Serverless 架构的云函数虽然有引以为傲的自动扩缩能力,但是糟糕的开发体验、让人畏惧的冷启动、原有业务需要改造等等,均降低了使用者的信心。这也是当前不少用户虽然认可 Serverless 的价值,但是认为很难承载核心业务的原因。针对这些关键问题,腾讯云在今年 6 月份的上海 KubeCon & CloudNativeCon 上发布了 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 本地开发工具、VSCode 插件,和 Coding 联合推出的 WEB IDE、DevOps 平台等,均能很大程度上提升开发、部署效率,实现本次开发、本地调试、联动云端调试、本地部署、版本发布等能力。同时云函数也完善了配套的监控和告警机制,提供如调用次数、内存使用、并发使用、超时、代码错误等多维度的监控和告警能力。对于基础设施、资源管理、安全、容灾等能力,是云函数平台必备的基础能力,也是开发者关心的核心能力。​​



Serverless 不仅仅是计算,还需要不断完善周边生态。随着用户量的增加,Serverless 必然会面临更多的挑战,怎么帮助用户组织管理代码,怎么解决带状态的业务诉求,怎么实现数据库连接数管理,怎么实现应用级部署等等。我们也在不断探索和优化用户的使用体验,计划提供诸如 Serverless DB、性能监控、日志分析、Serverless 框架、函数编排、高性能调用等功能。后续的文章也会陆续推出更多的核心能力解读,帮助开发者更好的理解和使用 Serverless。


Serverless is more!


相关文章:


《Serverless 系列(一):基本概念入门》


作者介绍:


黄文俊,腾讯云高级产品经理,负责腾讯云 serverless 产品规划。经历过企业级存储、企业级容器平台等产品的架构与开发,对容器、微服务、无服务器、DevOps 都有浓厚兴趣。对 Serverless 技术感兴趣的读者可关注 ServerlessCloudNative(ID:ServerlessGo)公众号了解最新技术与动态。


2019-09-04 08:3913814

评论

发布
暂无评论
发现更多内容

从软件架构说起

傻傻的帅

架构 架构要素 架构设计原则

架构师训练营-第一周-食堂就餐卡系统设计

Anrika

架构师 极客大学架构师训练营

谈谈阿里云发布新一代容器、Serverless 等云原生产品

关贺宇

阿里云 容器 云原生 中间件

架构师训练营-第一周学习总结

hellohuan

极客大学架构师训练营

ChaosBlade:从零开始的混沌工程(二)

郭旭东

云原生 混沌工程

架构师训练营第1周作业二:学习总结

sunpengjian

基于UML的食堂就餐卡系统设计

王海

极客大学架构师训练营

架构训练营第一周学习总结

陈靓-哲露

食堂就餐卡系统架构设计

任小龙

架构师训练营第1周作业一:食堂就餐卡系统设计

sunpengjian

Week01 学习笔记

任小龙

【话题讨论】「世界上最好的语言」?25周岁的 PHP “配” “不配”

InfoQ写作社区官方

php 写作平台 PHP25周年 热门活动

区块链技术如何应用于版权保护?

CECBC

区块链技术 维权 著作权 版权保护 侵权

设计模式之单件模式

公众号:程序猿成神之路

Java 设计模式

产品路线图–您的产品战略路径指南

涛哥 数字产品和业务架构

敏捷 产品经理

程序员为什么技术这么厉害,赚得钱却不多?

金刚小书童

程序员 职业规划 技术管理

ZooKeeper核心原理及应用场景

古月木易

架构师训练营第一周-食堂就餐卡系统设计

王铭铭

食堂就餐卡系统架构设计文档

hifly

极客大学架构师训练营 UML 架构文档 部署图 时序图

第一周课后作业——食堂就餐卡系统概要设计

jiangnanage

极客时间 - 架构师训练营 - week1 - 食堂就餐卡系统设计

毛聪

极客时间 极客大学架构师训练营 食堂就餐卡系统设计

极客大学架构师训练营第一周学习总结

竹森先生

学习 架构设计 极客大学架构师训练营

我们需要干货吗?

Neco.W

能力提升 经验分享 干货

IT自由职业者是怎么样的感受和体验

古月木易

IT职场

ZooKeeper核心原理及应用场景

奈学教育

zookeeper

《Web全栈实用编程》一书征集意见

老魚

程序员 大前端 Web 后端 全栈

架构师训练营-作业2-学习总结

狂奔嘀兔纸

极客大学架构师训练营

干货|微服务线上生命周期管理

博文视点Broadview

容器 微服务 架构师

食堂就餐卡系统设计

hellohuan

架构 极客大学架构师训练营

架构师训练营第1周_学习总结

方舟勇士

课程总结

week1-食堂就餐卡系统设计

不在调上

Serverless 系列(二):运行原理与组件架构_语言 & 开发_黄文俊_InfoQ精选文章