开发者学堂课程【Serverless Develpoer Meetup 课程：Serverless Developer Meetup 深圳站】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/943/detail/14746
Serverless Developer Meetup 深圳站
五. 简化 For 开发者
发展阶段
Serverless 有哪些边界的限制、弹性越来越清晰
绿色代表已经成熟但还在试点的圈内，试点用没有问题，但线上环境有许多边界问题。
1.简化 For 开发者：Serverless 只是运维域过渡态
终局思想，无穷接近终局，过渡形态长期化
未来面向终局思考是 NoOps,对 Serverless 终局的猜想，终局未必是一定达到的，可能一直处在过渡的状态，终局只是理想状态，尽可能无限接近终局未必能达到终局的状态。终局是 NoCode 不用写代码，LowCode 是写少量的代码前身是 ProCode 。LowCode 概念正在攀高峰对它充满了想象力，LowCode 是解决 UI 搭建的问题，并不是教大家写更少的代码，是解决特定域的问题。
之前提供数据接口要面向前端开发工程师写大量后端的数据接口。现在有 BFF/SFF 函数编排，可以用现在的状态写，理想状态是模型驱动，不需要写接口。后端服务之前是 SOA 面向服务的编程，现在是微服务的概念，未来全部 BaaS 化，提供一个后端服务不需要了解有多少后端服务器。
2.简化 For 开发者：Serverless+
结合 Serverless 做技术变革
现在是用 Serverless 做变革的阶段，LowCode+Serverless 会让 LowCode 搭建的页面快速的部署上线。
FaaS 在复杂业务场景下的提效实践
大纲：
第一点前端 FaaS 演进之路，怎样从业务系统构建 FaaS 能力。第二点在实际的业务场景里怎样把 FaaS 与传统的服务结合在一起。第三点以非常实际的业务场景的例子介绍怎样在复杂的业务场景做提效实践。最后做总结和展望。
Part1：1688 的 FaaS 演进之路
Part2：Business with FaaS
Part3：复杂业务场景的实践
Part4：总结与展望
简介：
.1688 商品详情业务简介
B 类商品的详情业务很复杂，首先是面向 B 类的交易，不像传统的 C 类交易的买卖关系，可能有很多交易渠道比如现货、分销、加工定制，每个渠道的交易方式价格都不一样，这样导致交易渠道是复杂的。
第二有很多垂直业务定制的需求，比如 B 类里消费品的赛道有工业赛道，不同的行业需要定制，不同的产品详情的样式与功能完全不一样，像新做的功能。电商的促销，天天要应对促销的活动、大促营销氛围多变。几个因素叠加在一起成为一个复杂的业务场景。
技术架构，在没有改造之前一个典型的业务逻辑组织团队。
底层是商品的基础产品，部门基础的商品中心的产品，对接集团的中台，商品的能力沉淀领域模型的服务和一些核心的商品逻辑，往上面对商品逻辑的业务场景的服务端就是无线服务端，面向前台的页面去设计视图模型，做一些轻量的逻辑和字段映射的编排，再往上的搭建机制，搭建平台有对应的页面路由控制组建的顺序
Intro
阿里集团-国内贸易事业部（CBU）
主要负责 1688.com 以及手机端阿里巴巴的 app,这两个业务是 B2B 的业务，更多的消费者接触不到。
面向 B2B 电商业务(批发、分销、加工定制）场景为小型企业提供零售批发、分销、加工定制等。国内最大的 B 类电商交易平台阿里最早的业务
For APP 端
大量的电商导购类业务场景负责 CBUServerless 和工程效能参与集团 FaaS 统一战役。
站在业务和技术结合的视角分享 Serverless 落地的实际经验。
Part1：1688 的 FaaS 演进之路
阿里集团在 14、15 年时主要的战役，大目标 All in 无线。业务状态的背景是移动互联网刚刚兴起，需要将大量存在的 PC 端业务复制到移动端，设立无线服务端，将 PC 端存在的业务通过微服务体系进行调用，面向前排的移动端业务进行轻量业务逻辑编排和 UI 层映射，最后经过移动端网关像搬运工一样将这些业务从 PC 业务搬运到移动业务。
移动互联网的功能迭代非常快，业务的迭代速度比之前快很多。传统的微服务体系构建、发布、调试时间效率与需要非常频繁的迭代业务逻辑层的编排和 UI 层相关的改动 match 不上。需要一种新的能力支持更好的业务，在 15 年探索类似 Serverless 的技术。
整个 1688 主要以 FaaS 能力为主，FaaS 能力主要落地有两个阶段，第一个阶段 2015 年部门内部自研一套 JVM 动态加载系统来实现快速发布快速上线部署的效果，第二阶段 2020 年 FaaS 能力上行到阿里云函数计算。
1.第一阶段 MBOX:基于 JVM 动态加载机制的 FaaS 系统
MBOX 主要特点、核心思想是充分利用了 JVM 的热加载特性，JVM 可以在线上不重启,动态的将外部的 Class 字典码加载进去，成为 JVM 正在运行的实例，在此技术之上构建了自己业务的 FaaS 容器，FaaS 容器可以从外部接受一段代码，可能是脚本、函数，对代码进行实时的语法编译，在做代码加固，注入集团内部中间件，通过自定义的 Class Loader 加载成线上正在运行的 JVM 中，实际运行的 Class 对外提供服务，实现了类似热加载机制的函数效果。在整个无线端需要快速迭代，需要寻找类似 FaaS 的能力。
系统的特点相对于传统服务在线开发脚本式编程，写一段代码实时编辑所见即所得，研发效率非常高。热加载更新的机制实现秒级的发布，业务服务上线的迭代效率高。
对于使用系统的人来说其实是 Serverless 的服务，因为所有的运维、机器的部署包括服务需要多少时令,都由 MBOX 的提供商承担。担任了类似云厂商的角色，对于使用 MBOX 且服务的开发来说不需要关心任何事情只关心写代码。
在这套机制下迈出了 Serverless 的第一步，在长达五年的时间系统承载了包括 1688 超过十万的 QPS 业务并且线上最高超过 1500 个函数，在整个无线扩张业务阶段立下了非常大的功劳。
随着时间的推移，系统的弊端也明显的体现，第一个隔离性问题，根据 JVM 做热加载机制，JVM 的隔离性约等于没有。
对于 MBOX 的维护来说成为吃资源的怪兽，有非常多的资源占用，但没办法判定是哪个服务资源占用，因为做了业务集群的隔离，因为 JVM 的隔离性，拆了很多物理集群尽可能实现服务的隔离，导致应用变成了有状态的应用，每一个集群加载的脚本服务是不一样的，没办法做弹性，不是无状态的应用。在这样的背景下要进行技术的换代和升级，18 年开始探索 Serverless BaaS 相关的成熟实现。最终与阿里云 FC 团队进行共建，阿里云团队在建设和收拢整个集团内部统一的 FaaS 能力。作为 JVM FaaS 能力的先行者与阿里进行比较深度的共建。
2.阿里云 FC：集团 FaaS 统一方案
Serverless Serverless 底层 K8s 来提供容器相关的知识，容器之上重点 Runtime 层业务函数明细的设计。第一点使用 Sidecar，Sidecar 去年和微软一起共建一套面向 Serverless 环境运行。之前的微软、FaaS 系统的业务代码的容器与中间件的内容吻合在一起，导致启动非常慢，弹性难。实现语言中立，阿里系的中间件主要以 JVM 为主，在很长时间里 JVM 都是作为服务端开发的主流语言，如果想逃出框架做申领很难。特点编程语言中立并且 FRAMEwork 层的 Runtime 可以支持定制，扩展性更强。Sidecar 构架，让整个业务容器更轻量，弹性更容易，启动速度更快。实现了容器化隔离并且实现高密部署。弹性伸缩，按量计算的能力。
4.回顾过往十年
集团第一批大规模落地 Serverless 的部门：超过 80%的业务参透率，积累 5 年的经验沉淀。
Part2:Business with FaaS
Business with FaaS 结合使用 FaaS 的经验探讨 FaaS Serverless 在实际场景进行落地时会有哪些问题、怎样去解决、是否和想象中一样非常好。
1.Serverless 之殇
.存量业务的改造
想要拥有 Serverless 的能力难道要将正在运行的 Serverful App 变成 Serverless Function 吗？像飞机正在运行不能让它停下来同时要给它加油甚至换引擎，风险非常大收益不好衡量，要找到一个适当的平衡点。不是一定用 Serverless 这种方式。
.FaaS 碎片化问题
传统微服务应用里比较庞大，高内聚的应用。绝大多数独立业务的场景，业务相关的部门会放在传统的微服务应用里。同一个场景之前是一个微应用解决，用 FaaS 后多了 30、40 几个函数。同样的业务扩张函数很难管理非常分散。
.研发效能的瓶颈
Serverless 能提供 Only Focus on Business 超级提效的研发体验，真正落地发现并不是如此，研发效率更多的是关注其它的问题
2.存量复杂业务如何与 FaaS 有机结合?
.BFF 模式
绝大多数同学好理解是常见的主流做法，将传统的 Serverful 逻辑进行抽象，在业务场景分为两种，一个代码变动层，特点逻辑轻，产品的需求。将变动层抽象出放在 Serverless 函数里，实现了 BFF 层的效果。前台消费方直接通过函数调用 Serverful App 有一个缓冲的区域，实现更快的发布和交付更少的运维。包袱丢不掉但可以集中 80%的经历有提效的效果。
适用场合：前台类业务应用，如 M-V-C 架构中的 Controller 层。
.扩展点模式
比较适合中后台场景，业务里的电商中台商品中心。
模式非常复杂业务逻辑多，历史悠久，可以将复杂的业务程序进行抽象。现有的业务逻辑可以将业务抽象成扩展点的方式，底层逻辑可以完全不动，只是修改代码结构让它成为一个扩展点的实现，有了扩展点可以用 FaaS 实现。在代码的架构定义出清晰的扩展点，可以让 FaaS 作为扩展点的实现，可以通过机制提供函数，让函数提供的服务成为 Serverless 业务逻辑的一部分，相当于是逻辑的提供者。通过这样的方式实现未来业务增量的迭代，可以让原来封闭式的架构，实现架构的开放。中台的业务场景很难让业务方定制这种模式后，业务方帮助进行定制业务逻辑，实现架构的开放。
适用场景：偏基础类业务应用中台型场景，需要服务多业务方。
3.避免 FaaS 的碎片化问题
.第一做编辑界面的权衡
函数集符不完全是函数，在定义里 Serverless 所谓 FaaS 里的 Function 更接近一个微运行时或者微应用，在里边可以做很多事情。没有必要做到极致，做一个函数的代码就变成一个独立的函数运行，可以扩展函数的定义。
结合之前做完 loss 老系统之后的经验和教训，那时是纯脚本编程导致函数数量膨胀的很快，而且难以管理，代码很难做。共建 JVM 函数的 Runtime 的编程界面时，制定两个原则，第一个原则做的是 Micro App 不是 Single Function。这样做一个函数提供多个接口，并且接口之间能实现相互复用，可以避免函数数量过于膨胀，第二个原则整个代码工程结构是 Code Project 一个完整的项目工程，而不是一个 Single Script。通过这两种方式可以实现整个 Serverless 函数管理。
面向开发者可玩的空间更大，数量不会像传统脚本的方式膨胀的太快。
第二点在基础上建设服务市场的能力，即便采用了 Micro App 的方式，函数比传统的微应用多很多，不是一个数量级，函数很轻量创建起来没有心理负担，防止泛滥成无法管理，函数在 Code Project 工程里做一个插件，插件会在编译时自动打包，自动扫描代码，判断函数属于哪个业务域，然后做函数组的划分、函数的划分以及函数内部每个接口详细的划分，对接口维度进行接口所属团队、维护人以及功能的业务描述和自动文档的生成。
通过自动上传和采集分类归档的方式建设服务市场的标准，让所有的 FaaS 函数有个地方能看到每个业务团队下有哪些函数，这些函数具体做哪些功能，维护人是谁，通过这种方式有效的避免 FaaS 的碎片化问题并且对函数进行裁剪时有迹可循，这是对 FaaS 碎片化问题做的两个尝试。
.编辑界的权衡
代码复用 研发效率 隔离性 可维护性
Micro App，Not Single Function
Code Project,Not Single Script
.建设服务市场
分类归档+自动采集：建设标准
4.研发效率的瓶颈在哪里?
Serverless 从诞生开始就号称能够 Only Focus on Business，如果只是生搬硬套将 Serverless 运用到环境中会发现真的 Only Focus on Business 了吗？
在初期的 Serverless 中确实发现写代码效率高很多，但从整体的业务团队、业务需求交付的角度包括产品和运营反馈在整个大环境的反馈来看研发效率没有太大的提升。阿里内部有研发者幸福度调研结果一天有 14.7%编码，剩下的时间在开会、联调、沟通、做方案设计等等。运用 Serverless 实际可以将编码的时间裁剪掉，但其他的时间很难用技术颠覆掉。如果站在业务团队的角度，真正想要提高业务效率只靠一门技术是不能实现的，更多的是关注技术之外的事情，比如很严重的沟通和协调效率之间的问题。在传统的前后端模式里，如果想要加强沟通协作的效率，可能采取工具性的方式，比如后端与前端之间通过自动生成的文档、样例以及幕后数据的一些方式来实现前后端工具化的协作，尽可能降低沟通成本，但这种方式可以闭环由一个人员从头开发到尾，消除了沟通的鸿沟和沟通的成本，Serverless 解决研发效率更多从这个角度出发。
技术之外：沟通和协作效率
方向一:通过工具优化协作流程，降低沟通成本 方向二:全栈开发，消除沟通鸿沟
总结来说在研发效率 Serverless 不是提效的银弹，研发效能提升的关键在于人与技术的结合。要结合实际场景、业务团队以及组织架构。
技术架构改造
没有改造前基本逻辑简化基本上是以下模型
商品的后端包括无线服务端都是采用传统的微应用 Serverful App 来实现业务逻辑，包含商品逻辑的核心业务逻辑以及无线服务端前台业务逻辑除此之外还有集团中台，都是微服务的方式提供 RPC 接口给前端进行消费。
第一个改造引入 BFF 层先把前台业务逻辑，无线服务端，提高研发效率，这逻辑变动最多，发布最频繁。解出来后先将发布迭代开发性能做实验解决。
当提供了 BFF 层后意外收获是有了 BFF 层后做了 UI 逻辑上行，前端有多种实践，多端代码的逻辑不同。如果将逻辑交给客户端做，可能实现两端逻辑不一致，如果想做跨端方案，组件逻辑非常复杂，所以将业务逻辑上新到 BFF 层。前端的组件非常干净只做展示，让多端的差异得到了很好的抹平并且跨端的方案得到了发展。
核心业务逻辑定义的扩展点，扩展点允许业务方通过函数的方式来把定制的业务逻辑进行实现。比如工业品和消费品的场景都需要定制价格和库存，通过扩展点的定义，业务方可以写一个函数实现价格和库存的逻辑直接接进，整体不用任何改动，通过这种方式实现了封闭架构开放化，更容易支持定制逻辑。
比如当前业务后端想要定制一个属于自己业务场景的业务详情，可以通过扩展点加前台函数的方式自己完成此过程，不需要与商品的后端、无线的服务端进行沟通、协作。沟通和协作成本比之前底很多。前后端是分离的在前后端沟通上对领域模型和视图模型都做了抽象文档样例的功能减少沟通的成本。
5.前端工程师开发项目时，创建一个项目做脚手架，怎样与 Serverless 相结合？
一个完整的业务链路包换几个部分，第一部分前端的组件，第二部分可能有一个业务的函数工程，第三部分有一个同样的接口。
目前在开发全栈式的开发流程，比如有一个业务脚手架的功能，在对应的业务场景通过脚手架一键创建出组件，组建的模板函数的模板以及对应的 RPC 接口的调用装，通过这种方式无论是前端的开发还是后端的开发，在整个工程初始化后可以直接写代码，并且函数组件消费的数据源 real model
与函数强绑定，做一些预发的样例实时采集幕后数据这些方式来加速前端组件和函数逻辑的结合度，能更好的结合在一起。目前探索的前后端相关事情的一些方式。
前端的发明有没有脱离本地 ID
Part3:复杂业务场景的实践
1.Only Focus on Business 的研发实践
定制一个业务场景以架构组织为例，业务方团队需要实现业务扩展的函数 FaaS 里有定义好的接口，以及接口的实现来进行业务逻辑的定制，业务逻辑定制之后商品的领域模型定制后会自动更新检测出来添加了哪些字段生成一个文档给前台视图层开发者进行参考，视图层的入参就是对应的模型，在里面做简单的 UI 映射，面向前台逻辑的业务封装，也是一段函数编写逻辑，这段函数发布完后形成视图模型是面向 UI 层的 real model。
前端的开发者直接消费模型。从理论上看不断优化的过程中包括技术站语言通用的情况下，完整的业务逻辑有可能实现从业务扩展点到视图层的逻辑再到前台 UI 的逻辑一个人完全开发。
2.提效结果
总体来看研发流程比之前高效很多，以数字看实际的业务效果。引入 FaaS 能力以及架构之后在业务场景里发布的等待时常降低了 80%，FaaS 的发布只需要 1 分钟，但原来传统的微服务发几个小时。
发布频次持续提成和持续交锋的能力提升了 300%，从产品的感知看需求的吞吐量提升了 20%，最关键的是在保证吞吐量提升的情况下人员投入减少了。原来的业务场景服务端需要两个正式员工投入现在只需要半个正式员工加一个外包就可以做到业务逻辑的 cover，整体提升效果好。
Part4:总结与展望
站在云原生的风口
小结
·Serverless 无疑是一轮新的革命，FaaS 等核心技术所带来的生产力提升已经得到了有效证明
·Serverless 的落地要结合实际业务场景有的放矢，不要一杆子捅到底。不是推翻所有的微服务都是不好的，都用 Serverless，不现实。
·任何技术都不是提效的“银弹”，研发效能的提升更多要站在人的角度去思考
虽然目前公有云 FaaS 能力比较成熟，还是有很大的进化空间，比如目前的冷启动问题弹性的能力，在业界正在探索以两者结合实现一套新的标准 FaaS 体系，有更好的弹性和资源利用率。FaaS 不会完全替代传统微服务，微服务是运行在传统的 FaaS 体制还是 K8s 体制，微服务在 FaaS Serverless 在很长时间内有效的共存，团队要做好准备，有效的结合。在组织架构、研发角色定位上 Serverless 可以看到全栈和低代码开发，这种一栈式开发逻辑在未来的业务场景和未来的业务团队尤其是前台的业务团队来讲越来越成为趋势，这种方式是最大实现技术提效的方式。
答疑：
低代码怎么做 Serverless 的 UI 层
Serverless 是解决运维问题，低代码 Serverless 化，低代码通常是搭建出来的网页，打包成一个简单工程用 Serverless 交付，CI 是整个研发链路最右边是部署上线，左边是研发，是整个研发上线中间的环节，持续部署和 CI 这套东西用 Serverless 很好的解决 CI CD 的问题。
