两大背景，两大优势
1. Serverless
【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取
两大背景
===================
为什么在集团内部能快速实现规模化的落地 Serverless？首先我们有两大前提背景：
第一个背景是 上云 ，集团上云是重要的前提，只有上云才能享受到云上的弹性红利，如果还是自己内部的一朵云，后续的起效降本其实非常难达成，所以 2019 年双十一阿里实现了核心系统 100% 上云，有了上云前提，Serverless 才有了发挥非常作用的空间。
第二个背景是 全面云原生化 ，打造了一个强大的云原生产品的云家族，对集团内部业务进行赋能，帮助业务达成了在上云基础上的两个主要目标：提高效能和降低成本， 2020 年天猫双十一核心系统全面云原生化，效率提升 100%，成本降低 80%。
2. Serverless 两大优势
===================
- 提高效能
一个标准的云原生应用，从研发到上线到运维，需要完成上图中所有标橙色的工作项，才能完成正式的微服务应用上线，首先是 CI/CD 代码构建，另外是系统运维的可视化工作项目，不仅要配置、对接，还需对整体数据链路进行流量评估、安全评估、流量管理等，这显然对人力门槛要求已经非常高。除此以外，为了提升资源利用率，我们还需要对各个业务进行混部，门槛会进一步地提高。
可以看出，整体的云原生传统应用，要实现微服务上线所需要完成的工作项，对于开发者来说非常艰难，需要由多个角色进行完成，但是如果到 Serverless 时代，开发者只要完成上图中标蓝色的框 coding，后续剩下的所有工作项，Serverless 的研发平台可以直接帮助业务完成上线。
- 降低成本
提高效能主要指的是人力成本的节省，而降低成本则针对的是应用的资源利用率。普通应用我们需要为峰值预留资源，但波谷就会造成极大浪费。在 Serverless 场景下，我们只需要按需付费，拒绝为峰值预留资源，这是 Serverless 降低成本的最大优势。
以上两大背景和两大优势，符合技术上云的趋势，所以集团内部的业务方一拍即合，一些大的 BU 已经把 Serverless 落地升级为战役层面，加速业务落地的 Serverless 场景。目前在集团落地的 Serverless 场景已经非常丰富，涉及到了核心的一些应用、个性化推荐、视频处理，还有 AI 推理、业务巡检等等。
Serverless 落地场景
目前，集团内前端场景是应用 Serverless 最快、最广的场景 ，包含淘系、高德、飞猪、优酷、闲鱼等 10+ 以上 BU。那为什么前端场景适合 Serverless 呢？
上图是全栈工程师的能力模型图，一般的微应用中需要有三个角色：前端工程师、后端开发工程师，运维工程师，三者共同完成应用的上线发布。为了提高效能，最近几年出现了全栈工程师的角色，作为全栈工程师，他要具备这三个角色的能力，不仅需要前端的应用开发技术，还需要后端系统层面的开发技能，并且要关注底层的内核、系统资源管理等，这对于前端工程师来说门槛显然非常高。
最近几年 Node.js 技术兴起，能够替代后端开发工程师角色，前端工程师只要具备前端开发能力，就可以充当两个角色，即前端工程师和后端开发工程师，但运维工程师仍然无法被取代。
而 Serverless 平台，解决的就是上图三角形结构中的底部三层，极大降低了前端工程师转变为全栈工程师的门槛，这对前端业务开发者来说非常有诱惑力。
另外一个原因是业务特性符合，大部分的前端应用具有流量洪峰的特性，需要业务评估前置，存在评估成本；同时前端场景更新迭代快，快上快下，运维成本高；且缺乏动态扩缩能力，存在资源碎片及资源浪费。而如果使用 Serverless，平台会自动帮你解决以上所有的后顾之忧，所以 Serverless 对前端场景的诱惑力非常大。
1. 前端落地场景
==========
上图列举了前端落地的几个主要场景和技术点：
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、更丰富的功能配置。