写点什么

Serverless 如何在阿里巴巴实现规模化落地?

作者:Java高工P7
  • 2021 年 11 月 11 日
  • 本文字数:3606 字

    阅读完需:约 12 分钟

上图列举了前端落地的几个主要场景和技术点:


BFF 转换成 SFF 层:?BFF 主要是 Backend For Frontend,前端工程师做主要运维,但到了 Serverless 时代,运维完全交于 Serverless 平台,前端工程师只需要写业务代码,就可以完成这项工作。


瘦身:?把前端的业务逻辑下沉到 SFF 层,由 SFF 层去做逻辑的复用,把运维的能力也交给 Serverless 平台,实现客户端轻量化,提效功能下沉。


云端一体化:?一处代码多端应用,这是非常流行的开发框架,同样需要 SFF 作为支撑。


CSR/SSR:?通过 Serverless 满足服务端渲染、客户端渲染等,来实现前端首屏的快速展现,Serverless 结合 CDN 整体可以作为前端加速的解决方案。


NoCode:?相当于在 Serverless 平台上做了封装,只需拖拽几个组件,就可以搭建一个前端页面,每个组件都可以用 Serverless 进行包装、功能聚合等,达到 NoCode 的效果。


中后台场景:?主要是单体的富应用场景,单体应用可以完全用 Serverless 模式进行托管,完成中后台应用上线,这同样也可以节省运维能力、减少成本。


2. 前端 Coding 变化


================


在前端场景应用 Serverless 之后,coding 有哪些变化呢?



对前端有一定了解的都知道,前端一般分三层:State、View 和 Logic Engine,同时会把一些抽象的业务逻辑下沉到 FaaS 层云函数上,然后用云函数作为 FaaS API 来提供服务,在代码编写上可以抽象各类 Aaction,每个 Aaction 可以有 FaaS 函数 API 提供服务。



上图以一个简单的页面为例,页面左侧是一些渲染接口,可以获取商品详情、收货地址等,这是基于 Faas API 实现的;右侧的是一些交互逻辑,比如购买、添加等,这也是 Faas API 可以继续完成的任务。


页面设计中,所有的 Faas API 不是只能为一个页面所使用,它可以为多个页面复用。复用这些 API 或者进行拖拽之后,就可以完成前端页面的组装,这对于前端来说是非常方便的。


3. 前端轻应用研发提效:1-5-10


====================



在前端应用 Serverless 之后,我们把 Serverless 对前端的研发效能的提效简单总结为 1-5-10,其含义是:


1 分钟的快速开始?:我们把各类主要场景做一个总结,将其归类为应用模板,每个用户或者业务方新起一个业务时,只需要选择相应的应用启动模板,就会帮助用户快速生成业务代码,用户只需要写自己的业务函数代码就可以快速开始。


5 分钟上线应用?:完全复用 Serverless 的运维平台,利用平台天然能力,帮助用户完成灰度发布等能力;并且配合前端网关、切流等完成金丝雀测试等功能。


10 分钟排查问题?:基于上线之后的 Serverless 函数,提供业务指标或系统指标的展示,通过指标不仅可以设置报警,还可以在控制台上给用户推送错误日志等,帮助用户快速定位问题、分析问题,10 分钟内掌握整个 Serverless 函数的健康状态。


4. 前端落地 Serverless 效果


======================


前端实现 Serverless 的场景后效果如何?我们将 3 款 APP 在传统应用研发模式下所需要的性能和工时与应用 Faas 场景之后进行对比,可以明显看到,在原有的云原生基础上,?效能还能提升 38.89%?,这对于 Serverless 应用对前端应用来说效果非常可观,目前 Serverless 场景已经几乎覆盖整个集团内部,帮助业务方实现 Serverless 化,实现?提高效能?和?降低成本两个主要目标。


技术输出,拓展新场景


在集团的 Serverless 落地过程中,我们发现了很多新的业务诉求,比如存量业务如何快速实现迁移并节省成本?执行时间是否可以调大或者调长?资源配置是否可以调高?等等,针对这些问题我们提出了一些解决方案,基于这些解决方案我们抽象出了产品的一些功能,接下来介绍几个比较重要的功能:


1. 自定义镜像


=========



自定义镜像主要目的是实现存量业务的无缝迁移,帮助用户实现零代码改造,并且把业务代码完全迁移到 Serverless 平台上。


存量业务的迁移是非常大的痛点,在一个团队内,不可能长期存在两种研发模式,这会造成极大内耗。想让业务方迁移到 Serverless 研发体系下,必须推出彻底的改造方案,帮助用户实现 Serverless 体系改造,不仅需要支持新业务使用 Serverless,还要帮助存量业务实现零成本快速迁移,所以我们推出了自定义容器功能。



传统 Web 单体应用场景特性:


  • 应用现代化细粒度责任拆分、服务治理等运维负担;

  • 历史包袱不易 Serverless 化:云上云下业务代码,依赖、配置不统一;

  • 容量规划,自建运维、监控体系;

  • 资源利用率低 (低流量服务独占资源)。


函数计算 + 容器镜像优势:


  • 低成本迁移单体应用;

  • 免运维;

  • 无需容量规划,自动伸缩;

  • 100% 资源利用率,优化闲置成本。


自定义容器功能,可以让传统 Web 单体应用(比如 SpringBoot、Wordpress、Flask、Express、Rails 等框架)不需任何改造,就可以以镜像的方式迁移到函数计算上,避免低流量业务独占服务器造成资源浪费。同时也可以享受到无需为应用做容量规划、自动伸缩、免运费等效益。


2. 性能实例


========



高性能实例,减少使用限制,拓展更多场景。比如:代码包从原来的 50M 上升到 500M,执行时间从原来的 10 分钟提高到 2 小时,性能规格比原先提升 4 倍多,能够最大支持 16G 和 32G 的大规格实例,来帮助用户运行一些非常耗时的长任务等等。



函数计算服务了很多场景,在服务过程中我们收到了很多诉求,比如约束条件多、使用门槛高、计算场景资源不足等问题。所以针对这些场景,我们推出了性能实例功能,目标是减少函数计算应用场景的使用限制,降低使用门槛,并且在执行时长上、各种指标上,用户可以灵活配置、按需配置。


目前我们支持的 16 核 32G 完全具备不同规格 ECS 一模一样的计算能力,可以适用于高性能的业务场景如 AI 推理、音视频转码等。这个功能对后续拓展应用场景来说非常重要。


挑战:


  • 弹性实例约束条件多,有一定使用门槛,如执行时长、实例规格等;

  • 传统单体应用、音视频等重计算场景下,业务需要拆分改造,增加负担;

  • vCPU、内存、带宽等资源维度,弹性实例未给出明确承诺。


目标:


  • 减小函数计算的使用限制,降低企业使用门槛;

  • 兼容传统应用和重计算场景;

  • 给用户明确的资源承诺。


做法:


  • 推出更高规格、资源承诺更明确的性能实例;

  • 未来,性能实例将具备更高的稳定性 SLA、更丰富的功能配置。


主打场景:


计算型任务、long-running 任务、弹性伸缩不敏感任务。


  • 音视频转码处理;

  • AI 推理;

  • 其它需求高规格的计算场景。


优势:


性能实例除放宽限制外,仍保留当前函数计算产品所具备的所有能力:按量付费、预留模式、单实例多请求、多种事件源集成、多可用区容灾、自动伸缩、应用的构建部署及免运维等。


3. 链路追踪


========



链路追踪功能包括:链路还原、拓扑分析、问题定位。


一个正常的微服务,不是一个函数就能完成所有工作,需要依赖上下游服务。在上下游业务都是正常的情况下,一般不需要链路追踪,但是如果下游服务出现了异常,如何定位问题?这时就可以依赖链路追踪功能,迅速分析上下游的性能瓶颈或者定位问题的发生点等。


函数计算也调研了很多集团内外的开源技术方案,目前已经支持 X-trace 功能,并且兼容了开源方案,拥抱开源,提供了兼容 OpenTracing 的产品能力。




上图是链路追踪的 Demo 图,通过计算 tracing 可以可视化看到后端服务的数据库访问开销,避免大量服务间的复杂校验关系增加问题排查的难度等。函数计算还支持函数代码级的链路分析能力,帮助用户优化冷启动、关键代码实现等。


Serverless 产品在业务角度上带来了巨大收益,但是封装也带来了一个阶段性难题——黑盒问题。当我们向用户提供链路追踪技术,同时也把黑盒问题暴露给用户,用户也可以通过这些黑盒问题提升自身的业务能力。这也是 Serverless 未来提高用户体验的方向,后续我们会在这方面继续加大投入,降低用户使用 Serverless 的成本。


挑战:


  • Serverless 产品在业务角度有巨大收益,但封装带来黑盒问题;

  • Serverless 连接云生态,大量的云服务造成调用关系复杂;

  • Serverless 开发者依然有链路还原、拓扑分析、问题定位等需求。


FC + x-trace 主要优势:


  • 函数代码级链路分析,帮助优化冷启动等关键代码实现;

  • 服务调用级链路追踪,帮助串联云生态服务,分布式链路分析。


4. 异步配置


========



在 Serverless 场景下,我们提供了离线任务处理、消息对立消费等功能,在函数计算中这类功能的使用率占比 50% 左右。在大量消息消费中,存在很多异步配置问题经常被业务方挑战,比如,这些消息是从哪里来?又去到哪里?为什么服务消费?消费的时间?消费的成功率如何?等等。这些问题的可视化/可配置,是目前需要主要解决的重要课题。



上图为异步配置的工作原理,首先从用户指定的事件源开始触发异步调用,函数计算立即返回请求 ID,同时也可以调用执行函数,返回执行结果到函数计算或者消息队列 MNS


【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开:qq.cn.hn/FTf 免费领取
复制代码


里面。然后通过事件源可配置触发器等等,这些效果或者主题消费,可以进行消息的再次消费。比如,如果一个消息处理失败了,可以配置一下进行二次处理。



用户头像

Java高工P7

关注

还未添加个人签名 2021.11.08 加入

还未添加个人简介

评论

发布
暂无评论
Serverless 如何在阿里巴巴实现规模化落地?