关于后端:Serverless-在阿里云函数计算中的实践

35次阅读

共计 2698 个字符,预计需要花费 7 分钟才能阅读完成。

简介:近日,阿里云 aPaaS&Serverless 前端技术专家袁坤在 CSDN 云原生 meetup 长沙站分享了 Serverless 在阿里云函数计算 FC 的实际。作者:CSDN 云原生 近日,阿里云 aPaaS&Serverless 前端技术专家袁坤在 CSDN 云原生 meetup 长沙站分享了 Serverless 在阿里云函数计算 FC 的实际。互联网软件架构演进 咱们先简略回顾下互联网软件架构的演进之路。单机部署 在单机部署中,将所有的业务和数据库都部署在一台主机中。

 此架构的长处是:开发、部署以及运维都非常简单。毛病是:一旦遇到流量过大或者机器故障,整个零碎瘫痪,甚至失落业务数据,造成微小业务损失。集群化部署 针对上述架构问题,罕用的解决方案是采取程度扩容的形式进行集群化部署。引入 SLB 的流量网关路由,进行负载平衡。集群化部署实质上是单体架构,开发人员在我的项目开发的时候须要额定留神,比方要应用 cookie 进行鉴权,session 就不能存储在本地,须要引入 Redis 进行独自存储。集群化部署能够通过疾速程度扩容解决流量突增或机器故障的问题。

微服务拆分 随着业务的倒退以及团队规模的扩张,单体架构这样紧耦合的形式会带来越来越多的问题,架构的灵活性和可扩展性成为妨碍业务倒退的重大挑战。微服务架构应运而生。

 

比照单体架构,微服务架构远比其简单,也衍生了很多新技术,比方:API 网关、服务注册、服务发现、RPC 通信。Serverless 架构 从单体架构到微服务架构,从单机部署到集群化部署,互联网软件架构越来越简单,公司须要投入大量精力和老本进行底层技术的降级和保护。下图是 Serverless 架构,和单体架构不同的是将对应的组件换成 Serverless 云产品。

 

 技术演进的实质是更好服务业务,传统开发方式使企业破费更多的精力打磨底层技术细节,而 Serverless 架构就是让开发者专一业务实现从而发明更大的业务价值。Serverless 架构的劣势很显著:不关注底层基础设施,专一业务价值发明 主动弹性,从容面对突增流量 按资源应用计费,防止资源闲置节约 Serverless 架构探讨 先来看一下 FaaS 的执行过程。蓝色局部是用户手动治理,只须要交付代码,其余的启动、运行、运维等都是在 FaaS 平台进行。

 

然而此架构会产生一些问题:代码碎片化,无奈对立治理和部署 本地环境和线上环境不统一,无奈解决依赖兼容性问题 进行本地 Debug 和线上调试艰难 FaaS 厂商对代码包有限度,无奈部署大代码包 没有对立的规范,导致厂商锁定问题 Serverless Devs 针对上述问题,Serverless Devs 能够帮忙开发者更好地开发治理 Serverless 利用,它具备以下几个特点:无厂商锁定,Serverless Devs 帮忙开发者将利用部署在各个厂商下面 开源凋谢,代码逻辑无任何黑洞 性能可插拨,Serverless Devs 通过组件的模式提供,开发者齐全能够依据需要,疾速开发适宜本人的工具套件 我的项目全生命周期治理能力,Serverless Devs 是用户进行我的项目初始化创立、开发、调试、部署等全生命周期治理的工具,简化 Serverless 利用开发 如果说 Serverless 架构能够帮忙开发者开发利用,那么 Serverles Devs 就是帮忙 Serverless 开发者更好地开发 Serverless 利用!Serverless 架构实际 Serverless Devs 官网实际 通过下面的介绍能够看出 Serverless Devs 开发者工具并没有提供业务,业务的实现由组件提供,而组件自身扩散在不同的 GitHub 仓库中。Serverless Devs 官网有上面几个诉求:不同仓库下 GitHub 源中的文档会集在一个界面进行展现 组件开发者专一组件文档编写,文档主动实时同步到官网 组件一旦有变动,官网可能主动部署和构建 整体计划如下:

 开发者在 GitHub 更新文档,触发 webhook 钩子配置的 Http Serverless 函数。这里须要留神的是:因为组件的文档数目不定以及 GitHub 网络不稳固等问题,如果所有的工作都在 Http 函数中解决,非常容易导致超时,所以将所有的解决逻辑放在异步调用中,执行完后将解决的后果投递到钉钉或者邮件等渠道。阿里云函数计算控制台实际 阿里云函数计算 FC 控制台是用户应用函数计算产品的第一站,控制台的用户体验至关重要。在架构上面临几个问题:后端采纳中心化部署模式,用户在海内拜访延时十分高 须要用户手动建设监控、日志、灰度等能力,导致运维老本偏高 研发效率较低,开发过程中前后端须要协调沟通,合作老本较大 整体解决方案如下:

 

左侧是阿里云通用的网关,负责对立鉴权和平安等逻辑,抽离出 BFF(Backend for Frontend)层,这部分的特点如下:整体 BFF 部署在阿里云函数计算 FC 上,开发者无需手动运维 BFF 层由前端工程师负责,前端工程师更好地深刻业务,提供优良的用户体验 后端工程师专一于底层稳定性和原子能力的提供,通过 SDK 的形式进行交付给 BFF 

 

通过 Serverless 实现的 BFF 不仅给业务带来了极大的灵活性,对于前端工程师这个群体也有质的扭转:从之前的技术视角转变到更加关注业务价值和用户体验晋升。CD 构建实际 惯例的自建 CD 构建集群计划通过 Jenkins 或 Tekton 框架实现业务逻辑的编排,资源层面应用 K8s 部署,实现弹性伸缩。如果须要实现简略的云端构建 CD 计划,采纳上文的架构略显简单。CI/CD 的业务场景有以下几个个性:通过事件触发执行 流量无奈提前预估 须要长时间在后盾运行,对延时不敏感 因为网络时延等问题,须要设计失败重试机制 这些个性齐全是为 Serverless 量身打造的。实现计划还应用了异步函数,将构建的所有流程导到异步函数中解决,整个编排逻辑通过 Serverless Devs 进行,完满实现了一个性能稳固的 CD 构建集群。阿里云函数计算利用核心这款产品的底层的 CD 能力齐全基于上述的原理进行实际,大家能够自行体验。

 

 异步函数 实际中有十分多应用到异步函数的场景,这里简略介绍下异步函数。

 总结来看,异步函数有四个特点:1、可长时间运行,两个小时到一天不等 2、能够设置主动终止,自在调节工夫,节约资源 3、可把触发后果分发给各个事件兑现核心 4、有三次机会可在失败的状况下主动重试原文链接:http://click.aliyun.com/m/100… 本文为阿里云原创内容,未经容许不得转载。

正文完
 0