作者：孔德慧
Serveless简介
Serverless是云原生技术发展的高级阶段，从物理机到云主机再到Serverless的发展，就好比人类从采集野果的原始社会，到刀耕火种的古代社会，再到工业设施完善信息化高度发展的现代社会。人总是要想办法填饱肚子，但是随着社会的发展与生产力的进步，人类在如何填饱肚子上花的时间越来越少，而花费更多的时间用来实现社会价值与个人理想。人类依然需要填饱肚子，但不再需要亲自摘果子，无需亲自放羊，甚至无需关心果子从哪儿摘。
从物理机到Serverless的发展也是类似的。物理机时期，开发者需要组装服务器，搭建机房，为了承接业务峰值需要提前准备平时几倍流量的服务器资源；而到了云主机时期，开发者无需组装机器也可以获取到计算资源，能够直接基于云主机搭建业务。为了承接峰值流量，只需提前规划并且购买云主机，结束后释放云主机，自由计算资源的利用率得到了进一步的提升，资源成本也有所下降；到了Serverless阶段，开发者不但无需组装服务器，甚至无需提前购买与释放计算资源，只需专心于开发业务逻辑，由Serverless云产品来保障业务稳定可靠地运行，开发者只对使用的计算资源付费，资源成本进一步下降。
Serverless时代不是没有服务器，而是业务开发者无需关注服务器，代码仍然运行在真实存在的服务器之上；计算资源的维护从用户转交给了云服务，用户只需要聚焦于业务逻辑代码的开发，按使用量付费。
从物理机到Serverless，将开发者从复杂的基础设施维护中解放出来，开发者无需关心底层的基础设施，只需关心业务逻辑的实现，资源利用率更高，资源成本更低，人力成本更低。
弹性容器实例ECI、Serverless K8s ASK、Serverless应用引擎SAE、函数计算FC分别是容器级别、集群级别、应用级别与函数级别的抽象。
ECI属于容器资源层，开发者无需管理底层服务器，只需提供提前打包好的镜像即可运行容器。但是多大的负载、需要多少容器、什么时候扩容、什么时候缩容、流量如何调度等还需上层来解决。
ASK属于容器编排层，帮助开发者进行ECI的编排、节点的维护与容量的规划。集群还是用户的，ASK只是帮助用户搭建集群、调度流量。
SAE是面向应用的Serverless PaaS平台，计算集群不再属于用户，而是归云产品所有。SAE所有开发者无需维护、管理计算集群，只需部署应用，搭建负载均衡的网关，即可将业务弹性平稳地运行起来。
FC是面向函数的FaaS平台，计算资源归云产品所有，即归函数计算所有。开发者不仅无需维护计算集群，也无需搭建负载均衡的网关，函数计算内置了负载均衡的网关与削峰填谷的队列，开发者只需编写业务逻辑代码，由函数计算来保障应用的弹性稳定运行。
函数计算的研发与运维效率最高，抽象程度也最高，用户无需提前购买与配置任何计算资源，一行代码即可在函数计算上将应用跑起来。过程中，只有代码是用户的，其他的全部计算资源都属于函数计算。
上图左侧是函数计算的简易架构图。首先，用户需要将应用以包或者镜像的格式先上传到函数计算。调用请求过来以后，会分成同步调用与异步调用。
同步调用请求会先经过负载均衡的网关到达函数计算系统的网关，调度模块获取计算资源的地址后，找到计算资源对应的函数执行引擎，并在函数执行引擎里执行用户代码。
异步调用会先将事件写入消息队列，有专门的异步事件分发模块负责从消息队列里读取事件消息，再从资源调度模块获取计算资源，然后找到计算资源执行用户代码。
从架构图中不难发现函数计算架构具有如下特征：
第一， 调度黑盒化，执行环境黑盒化。调度节点与执行环境都归云产品，所有的调度节点与执行环境用户都无法感知，这也给用户排查问题带来了一定困难；
第二， 实例轻量化。实例以请求级别扩缩容，实例的生命周期更短、更不可控。实例扩容后，若没有请求执行，一段时间后会将实例缩容；此外实例规格小，最小的规格为1/12vCPU；
第三， 组件分布化。函数计算典型的事件触发场景中，请求要流转多款云产品，函数计算只是其中一环。
基于以上特征，可以发现函数计算与此前的传统开发模式有着很大的区别。函数计算可观测也面临了诸多挑战：
第一， 数据收集难。
• 实例生命周期更短，实例规格更丰富、更小。传统的部署 agent 可观测技术无法施展；
• 函数的执行引擎为多租户共享，执行引擎里可能有多个用户的函数实例，传统的部署 agent 方式也不支持多租户形式。函数的生命周期是由系统控制，用户无法判断开始与结束时间，导致很多可观测数据无法成功发送。
第二， 数据分析难。
数据量大，而且会随着用户数的增长而呈指数级的增长。对数据链路的稳定性、数据的查询速度和存储成本都带来了非常大的挑战，也给数据分析带了不少难度。
第三， 问题定位难。
• 分布式的组件使得监控数据散落在各处，问题定位流程繁琐。以事件源触发为例，请求会先通过事件源，然后到函数计算执行用户代码，再由执行引擎里处理消息，并将处理结果存储到用户另外的数据库里。上述流程中，请求经历了好几个云产品。如果用户发现请求端到端延时很长，需要先查看上游是否有问题，再看函数计算调度是否有问题，再看下游数据库连接是否满了，流程异常繁琐；
• 调度黑盒化，执行环境黑盒化。因为执行环境都属于用户，用户无法进行管理，唯有要求云产品侧暴露更多指标，使原本黑盒的链路稍微白盒化；
• 函数调用与资源调度都是以请求为粒度的，实例粒度监控已经不足以帮用户快速定位问题，需要提供更细粒度的排查与定位问题的能力。
基于以上痛点，开发者对函数计算的可观测提出了更高要求，期望函数计算平台提供功能更全面、上手更简单的可观测能力。我们收集了客户需求，总结出以下三点目标：
第一， 提供开箱即用的可观测平台，统一的观测页面。用户无需进行复杂的配置，甚至无需配置，开箱即用；
• 平台端需要无侵入地进行数据采集、上报、处理、展示。
• 提供丰富的指标、完备的日志、详细的调用链，提供尽可能多的指标让用户充分了解执行环境。
• 提供更细粒度、以请求为粒度的可观测能力，实现全链路的白盒化。
第二， 兼容传统开发者的开发习惯，提供以实例为问题定位单元的观测体验；
第三， 数据开放，协议开源。
• 将观测数据投递给用户，允许用户进行自定义处理；
• 协议使用开源规范，方便用户统一对数据进行处理。
接下篇：
https://developer.aliyun.com/article/1222670?groupCode=alisoftwaretech
