开发者学堂课程【Serverless 在阿里巴巴的实践：Serverless 在阿里集团的大规模落地案例（下）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/847/detail/14017
Serverless 在阿里集团的大规模落地案例（下）
内容简介：
一.FC 集团规模化落地技术方案
1.极致 Serverless 性能一高可用系统
2.集团中间件打通上下游
3.开发模式
4.研发平台集成一开发者提效1-5-10
5.研发运维平台集成一可观测性 Metrics
6.研发运维平台集成一可观测性 Tracing
7.研发运维平台集成一可观测性 Logging
8.全面触发器集成
9.自定义容器镜像/自定义 Runtime
二.FC 集团规模化落地案例
1.业务特性
2.落地前端场景
3.淘宝前段落地方案
4.消费场景痛点
5.消息处理场景
6.轻应用场景
7.演示 demo
一、FC 集团规模化落地技术方案
1.极致 Serverless 性能一高可用系统
整个 FC 系统，对其稳定性和高可用做出了很多的努力，从而能不用去关心它的函数状态，给用户提供并且保障了一个高可用免运维的操作环境。
整个 FC 系统内部的一些主要链路是一个分布式的模式，同时加入了很多高可用组件包括断路器流控，单机流控，批发度流控，来一同保障整个系统的高可用。同时整个组件是主备模式去部署，或者是多分片机制的去分布式的部署。
底层的一些资源管理层,是会去多机房部署，从而实现了整个资源水位的高可用能力。
整个 FC 集群也是分多个环境，多个单元之间也可以互相去切流，包括中心单元和上海单元。他们当一个当用户的函数在一个单元发生故障时,可以及时切换到另外一个单元。
每个单元也是多机房部署的，防止机房出现网络问题，也可以将请求路由到其他机房。在整个系统中对每个组件实现了自动化恢复的能力,就是以防止单个组件节点的单点故障。
当一个节点出现单点故障的时候，整个这个节点是有可以快速自动化恢复的高可用能力的。同时也会对整个链路实例的状态进行健康检查,来保障用户的整个函数实例是正常的,如果发现一些不正常的函数实例，也会对他进行一个删除和替换。所以相当于给用户提供了一个高可用的保障环境。
2.集团中间件打通上下游
在集团内落地还有一个难点，是和集团的中间件进行上下游的打通,因为在集团内做应用都面临一个多环境的问题,不同环境的环境标和单元标是不一样的。阿里云不希望用户去配置或者感知这些环境的差异,所以借助 dapr 这种分布式的运行时，它会帮助用户在运行时层面去屏蔽掉下游的不同环境的差别，或者下游不同中间件的差别。
这张图就显示了它的一个特性，它是一个可拔插可以替换的组件，是可以任意替换的一种连接方式。在函数中通过实现,方便使用户屏蔽一些底层的实现，去掉下游的不同的数据库的组件等。
dapr 自身也是微软开源的一个分布式的运行时，它上面其实是不同的运行时，dapr 下面是不同的 dapr，中间件组件或者是不同的云厂商的一些服务,他们可以任意的组合和连接。阿里云集团内也落地了这个开源项目，实现了运行时的一个解耦和轻量化。
这是具体的架构图，中间是集团的这些中间层，开始有两个方案和集团的中间层打通，一个是上面介绍的 dapr 方案,另外一个是中心化代理的方案,中心化代理方案有一个明显的缺点，它会造成流量的瓶颈。中心化的节点很容易造成流量的瓶颈，所以就放弃了中心化代理的方案。采取了 dapr 方案，因为 dapr 是分布式运行时，它的部署实施采用 sidcar 部署，它是一个函数实例,函数实例中都会有一个 dapr 的进程或者 sodcar，每个函数实例会通过 dapr 的进程去和中间件联通，而不是通过原来的中心化的代理模式，所以 dapr 更适用于 service 场景。同时 dapr 还有一些其它的特性,包括它的影响面很低，如果出现问题他只会对单个业务造成影响，他还可以控制可以灰度升级。同时它还支持一些包括切流限流的操作，扩展性也很好。
3.开发模式
接下来介绍一下整个函数计算和在阿里集团内部的 serverless 的开发模式和流程。FC 的开发模式和微服务是有区别的，其中最大的区别就是给开发者屏蔽了一些服务器运维方面的操作，还有可观测方面的操做,对于开发者来说只需要去写代码，然后将代码部署到函数计算上,剩下的事情全都给平台去全托管。当然整个开发模式中的需求分析、设计开发是需要用户自己操作的，部署测试，上线运维主要的区别是在运维方面，相当于解放了开发者的双手,不用再去关心部署到函数计算之后的事情,使它实现全方面的托管。
具体的开发模式是如果你想要开发一个函数计算的服务，你得先了解或者配置什么样的东西,也要去了解一下函数计算的基本概念包括服务和函数，service 是函数基本的一个资源管理的单位,同一个服务下可以去配置很多个函数，这些函数是共享了这个服务的配置。服务层面的一些配置主要有以下四个:
网络层面的配置是因为在阿里云上服务可能会需要一个独立的网络环境或者是公网、是独立的 V PC 专有网络的环境，可以去自己配置。
权限配置是服务具有什么样的权限，阿里云上的权限管理是很严格的，它也有一套专门的权限管理机制,如果一个服务区调用另外一个服务的话是没有对应的权限，所以一些企业用户对权限很敏感，会去做相应的权限配置。
NAS 配置是文件系统的配置。需要在函数里面读写大的文件或者将函数代码可以放到 NAS 中读。
SLS 配置可以配置日志服务。
这四部分大部份不是一个必选的配置，针对不同场景可以选择性配置。
函数的基本概念是管理和运行的基本单位,代码 FUNCTION 就是一个函数,实际运行的时候,函数里面的逻辑也包括一系列的配置。这些配置包括超时和需要函数实例中内存和 CPU 的规格。能启动的对应的规格也有相应的文档,每个字段都有相应自己的配置,另外是否可选都是在文档里有相应的标记,在开发之前需要先了解这些概念。
包括开发模式需求分析设计和代码编写这个图做了省略，开发者在代码编写完会先去创建服务和函数。
那么阿里云也提供了一个灰度发布的能力,使用版本和别名的概念控制服务的一个灰度发布的流程,从而可以保障在生产环境下更具有一个安全可靠的发布上线模式。
如果想要去实现灰度发布的流程，需要你在创建完服务再编写代码最后测试通过。需要先创建一个版本,比如创建一个版本一,再创建一个别名，别名概念是指向一个版本的指针。
如可以创建 stmp 的别名，代表了一个稳定的线上版本,它指向了当前的版本一。其他用户去访问的时候,就可以访问这个稳定的别名,也可以在其他的版本上去发布更新，但是不会影响线上稳定的版本。
比如说来了一个新的需求，但是你现在线上运行的是稳定版本，就可以将代码克隆一份出来，发布一个新的版本,这个版本指示的不是线上的版本，而是第二个版本,如果你测试灰度发现版本是正常的，就可以将线上的别名指向这个版本。灰度发布验证正常后，用户可以通过函数日志或者提供的监控报警看到相关内容,这个全托管的平台对用户来说其实不是黑河的模式。其实也提供了一些指标和很好的一个可观测能力,给用户去看它当前函数具体的运行状态。
4.研发平台集成一开发者提效1-5-10
阿里集团内部也做了一个很好的一个研发平台,让集团内部的开发者能够达到提效1-5-10 的效果,什么是 1-5-10呢？
就是能够实现在一分钟内快速开始一次研发流程,在五分钟内能够快速上线一个一体化的应用，在十分钟内如果发现异常可以马上排查解决这个异常。
借助 severless 就可以看到整个研发到上线的流程，相对于传统应用是很便捷的。一分钟内能够快速开始,就是借助现在的一个研发平台，直接在一个外部 IDE,或者外部开发的组建上,能够快速编写代码快速发起一次迭代的流程。
五分钟内能够快速上线一个应用,整个发布的流水线可以自定义,包括代码 review、金丝雀灰度发布和一个快速回滚能力，编写好应用，可以借助发布流水线将应用灰度上线。
十分钟内能够排查解决问题，在整个集团内对全链路都进行了监控和报警的平台处理。不仅是在自身系统还是下游依赖的中间件服务,都进行了全链路的监控。在问题发生的时候,会触发各种电话异常报警,后台在全链路的监控系统里面，会将具体的异常链路和出错具体位置显示出来，这样就可以达到在十分钟内找到具体的问题所在，从而也提供了用一些快速的手段回滚在单元之间切流或者业务的一些预案,能够实现整个应用的快速恢复。
5.研发运维平台集成一可观测性 Metrics
我们整个 serverless 提供了很好的可观测能力,在集团内部和淘宝的一些团队合作建设了一个可观测的应用平台,可以看到函数在当前单元之间的流量、延迟和具体使用的函数实例的个数还有状态。包括每个实例的 CPU 还有内存的利用率,同时在每个请求的调用链上也对每个请求的调用链进行了收集和采样，可以看到从上游哪里来，调用了下游的哪些服务。每个服务的QPS成功率、延迟、用时有多少，提供全面的可观测分析能力,一旦出现异常,也可以马上定位到具体的出现问题的地方。
6.研发运维平台集成一可观测性 T racing
tracing 能力指针对单个调用链，不仅能够看到请求在外部调用了什么服务，在每个服务上的延迟，也能够看到一些敏感冷启动，提供这样的一个分析能力来展示出请求在系统内部到底是耗时了多久。COLD START 代表冷启动的时间,又包含准备下载代码的时间和运行时初始化的时间。整个函数执行的时间可能有两秒多,用户可以很直观的看到冷启动还有可以优化的空间，下一步可能就是会去选择预留实例或者是配置一些初始化的步骤去减少冷启动的时间。这张图就是展示了整个端到端的调用链。
7.研发运维平台集成一可观测性 Logging
logging 是一个日志的方式,用户可以直接在函数里打印自己想打印的信息和日志,这里也对这些日志进行了收集,同时可以根据单条请求的 ID 查到当前日志。相当于给用户提供了一个排查问题的手段，所以不用担心全托管带来的一些问题,提供了丰富的能力帮助大家解决各种问题排查，提供了可视化服务的状态能力,不用担心具体的实现操作。
8.全面触发器集成
触发器相当于是事件源集成的方式，函数计算是多种的触发模式，提供了多种的云产品的触发集成。在集团内主要包括五种触发方式,在公有云上同样支持各种方式触发。
定时触发：
支持分钟级别的触发
保证“At least once”执行
如果函数执行失败，会一直重试至成功
异步触发：
所有事件函数支持异步方式调用保证“At least once”执行
可以配置重试次数，默认重试至成功 Metaq 队 列消费
HTTP 触发器：
支持自定义域名触发支持绑定统一接入层触发面向 HTTP 协议的函数 HSF(RPC) 触发器：
所有函数默认支持 HSF 方式调用，无需手动创建通过 HSF SDK 调 用
MTop 触发器：
H5 接入，客户端接入
集团内也实现了真正的按需付费，集团之前的一般的业务应用的开发模式。其实是需要先申请机器的预算,想要知道预算又得先去评估业务的规模,才能知道会申请多少机器，然后才能去创建应用，开发应用,最后还需要去结算。而现在这种付费方式经过 serverless 可以实现真正的按需使用，就是一个应用上线前它不需要先不需要这些步骤，可以直接先用，阿里会帮他结算在弹性的模式下他真正使用了多少。这样的话相当于简化了整个应用的一个研发上线的一个流程。
9.自定义容器镜像/自定义 Runtime
传统 web 单体应用:
SpringBoot, Wordpress, Flask, Express, Rails
场景特性、挑战:
应用现代化细粒度责任拆分、服务治理等运维负担
历史包袱不易 Serverless 化:云上云下业务代码，依赖、配置不统一
函数计算＋容器镜像优势:
低成本迁移单体应用
二、FC 集团规模化落地案例
1.业务特性
集团内部业务特性符合
存在流量洪峰，业务评估前置,存在评估成本
更新迭代快，快上快下，运维成本高
缺乏动态扩缩能力，存在资源碎片，资源浪费
在集团内很流行 serverless 的开发和应用,特别流行的概念叫 SSF,它的全称是Serverless For Frontend，是面向前端的。和传统研发模式相比它具有免研发免运维的特点并且支持自动化扩缩容，能大幅的降低运维成本，提升资源利用率。
2.落地前端场景
传统 的 BFF 到 SSF 的转变，BFF 相当于是架构模式的转变,现在就是转变成了SSF，后端直接交给 serverless 负责,而不是之前各种传统的微服务或者 IPI，应对的场景包括 ios，安卓和 web 等所有单体的 BFF 模式，都可以转换成 SSF 的模式。
客户端的轻量化是直接由客户端请求直接调用的 serverless 应用上极大的提升了客户端研发和运维的流程。
云端一体化云端是端上的应用和云上的应用都是一套后端的实现。实现代码的复用并且消除运维的负担。
CSR/SSR 是提升了性能，增强了 SEO。
NoCode 是端到 Lowcode 的复用和提效。
中后台为 Serverless App
3.淘宝前段落地方案
结合 serverless 的能力，针对流量防控做了一些很不错的建设,具体是目前在层面流量控制一般是在并发度方面的控制,从并发度转换到具体的 QPS 其实是比较困难的，因为请求会存在不同的请求耗时波动。所以淘宝前端团队就推出了一个拥测控制算法，一个自动化测试的平台搭建，它基于日常真实业务流量,它会进行一个节流测算,再具体框架层会算当前业务具体能够承受的一个 QPS。同时也实现了多层流量的控制，通过一个通用的集团内部网关到函数 FC 上，再具体到内部。在每个维度,都进行了一个流量的控制。
4.消费场景痛点
消息场景是一个应用很广泛场景。但是普通的消息场景也存在一些普遍的痛点。一般业务逻辑都很简单，一般的消息处理不会去管理异常的处理,不知道消息到底有没有被丢弃或者需不需要重试。会对后端服务造成压力，造成后端崩溃,所以这些开发的成本都需要我们用户或者开发者去解决,同时它运维成本比较高，消息很容易造成积压，造成一个消息的流量高峰。用了 serverless 之后，这些开发或者运维成本全部交给平台极大便利了开发者。
5.消息处理场景
核心价值:
弹性高可用:海量请求（数十万 TPS)高并发和极致弹性需求，稳定可靠的容灾和持久化存储能力，灵活的削峰填谷能力保护后端系统稳定。
事件驱动:独有的云产品间事件驱动能力，解放架构难点，自动化处理流程。数据处理:支持定时任务，提供充足的计算资源和高度自定义数据分析策略。
降低成本，按量付费，客户不再需要预留闲置资源，实时反馈营销结果投入。
6.轻应用场景
核心价值:
前后端全栈解决方案:语雀并没有像 SFF 一样将 web 服务迁移到函数计算之上，但是函数计算在语雀整体的架构中对稳定性、安全性和成本控制起到了非常重要的作用。
性能＋弹性:规避不完美，享受 Node 的高效研发福利，在低时效、CPU 密集、沙箱环境、不稳定的第三方服务、高弹性能力等方面有显著收益。
工程效率:无需再维护任务集群和自建服务，基于函数计算自如选择更合适架构，减低安全风险，大大节约成本。
7.演示 demo
针对每个应用，以迭代应用的迭代为维度开发管理整个流程。每个迭代可以创建自己的迭代名和分支名。然后对不同的应用实施展示当前的 QPS、错误率、RT 等，提供了各种迭代、调试、灰度发布、应用回滚、监控、日志查询、应急响应的这些能力。
可以对迭代添加变更进行发布，同时也是支持多环境的发布。一般是线上环境，线上环境是稳定的环境。正式发布后，整个平台会检查完整 cict 的流程和构建代码,函数发布完后会在界面展示函数的访问方式，并且整个构建的日志也会展示出来。
在日常和预发环境中，也提供了函数远程调控的能力，用户可以通过配置远程调试参数，点击坚决执行，就可以实施执行一次请求,这样方便了用户去验证函数的逻辑。如果遇到一些不好解决的问题呢,就可以检验定位出代码出错的位置。
