1.2.2 面临的挑战
虽然Serverless架构发展迅速，被更多的人认为是真正意义的云计算，甚至在2020年的云栖大会上，Serverless被再次断言“将会引领云计算的下一个十年”。但是，Serverless架构仍然有着劣势，面临着诸多挑战。2019年，UC Berkeley的文章“Cloud Programming Simplified: A Berkeley View on Serverless Computing”针对Serverless架构总结出了包括Abstraction、System、Networking、Security、Computer architecture等在内的挑战。
1）Abstraction Challenge。
·资源需求（Resource Requirement）：通过Serverless产品，开发人员可以指定云功能的内存大小和执行时间，而无法指定其他资源需求。这阻碍了那些想要控制更多指定资源的人，例如CPU、GPU或其他类型的加速器等资源。
·数据依赖（Data dependence）：今天的云功能平台不了解云功能之间的数据依赖性，更不了解这些功能可能交换的数据量。这可能导致次优放置，从而导致通信模式效率低下。
2）System Challenge。
·临时性存储（Ephemeral Storage）：为Serverless应用提供临时存储的一种方法是使用优化的网络栈构建分布式内存服务，以保证微秒级的延迟。
·持久性存储（Durable Storage）：与其他应用程序一样，Serverless数据库应用受到存储系统的延迟和IOPS的限制，需要长期的数据存储和文件系统的可变状态语义。
·协调服务（Coordination Service）：功能之间的共享状态通常使用生产者-消费者设计模式，这需要消费者在生产者获得数据时立即知道。
·最小化启动时间（Minimize Startup Time）：启动时间包括3个部分，一是调度和启动资源以运行云功能的时间，二是下载应用软件环境（例如操作系统、库）以运行功能代码的时间，三是执行特定于应用程序的启动任务的时间，例如加载和初始化数据结构和库的时间。资源调度和初始化可能会因创建隔离的执行环境以及配置客户的VPC和IAM策略而产生显著的延迟和开销。
3）Networking Challenge：云功能可能会对流行的通信原语（如广播、聚合和混洗）产生巨大的开销。
4）Security Challenge：Serverless架构重新分配了安全责任，将其中许多人从云用户转移到云提供商，而没有从根本上改变它们。但是，Serverless架构还存在应用程序分解多租户资源固有的风险。
5）Computer Architecture Challenge：主宰云的x86微处理器性能提升速度缓慢。
当然，此处所认为的Serverless架构面临的挑战相对来说是比较抽象的。就目前的工业界实际情况来看，这些挑战依旧普遍存在，也是当今众多云厂商不断努力的方向。站在Serverless开发者角度来说，将上述挑战与开发者最为关注的几个问题结合起来，可以认为Serverless架构目前所面临的挑战包括不限于冷启动问题、厂商锁定、配套资源不完善等。
1.冷启动问题
所谓的冷启动问题，指的是Serverless架构在弹性伸缩时可能会触发环境准备（初始化工作空间）、下载文件、配置环境、加载代码和配置、函数实例启动完整的实例启动流程，导致原本数毫秒或数十毫秒可以得到的请求响应需要在数百毫秒或数秒得到，进而影响业务处理速度。
正如前面所说，任何事物都有两面性。Serverless架构具备弹性伸缩优势的同时，相对ServerFul架构而言也引入一个新的问题：冷启动问题。
Serverless架构下，开发者提交代码之后，平台一般只会对其持久化并不会为其准备执行环境。所以，当函数第一次被触发时会有一个比较漫长的准备环境的过程，这个过程包括把网络的环境全部打通、将所需的文件和代码等资源准备好。这个从准备环境开始到函数被执行的过程，被称为函数的冷启动。由于Serverless架构具有弹性伸缩能力，Serverless服务的供应商会根据流量波动进行实例的增加或缩减，所以平台就可能频繁准备新的环境、下载函数代码、启动实例来应对不断产生的请求。
如图1-6所示，当Serverless架构的FaaS平台中某函数被触发时，FaaS平台将会根据具体情况进行实例的复用或者新实例的启动。
图1-6 函数计算根据流量进行函数扩缩示意图
如图1-7所示，当有空闲且符合复用要求的实例时，FaaS平台将会优先使用，这个过程是所谓的热启动过程。否则，FaaS平台将启动新的实例来应对此时的请求，这个过程则是对应的冷启动过程。Serverless架构这种自动的零管理水平缩放，将持续到有足够的代码实例来处理所有的工作负载为止。其中，“新实例的启动”包括初始化工作空间、下载文件和配置环境、加载代码和依赖、函数实例启动等几个步骤。相对于热启动在数毫秒或者几十毫秒内的启动，冷启动所多出来的这几个步骤耗时可能是数百毫秒甚至数秒。这种在生产时出现的新实例启动，并导致业务响应速度受到影响的情况，通常就是大家所关注的冷启动带来的影响，如图1-8所示。
图1-7 FaaS平台实例启动流程简图
图1-8 函数冷启动产生示意图
综上所述，不难分析和总结出冷启动问题出现的常见场景。
·函数的第一次启动：函数部署后的第一次启动，通常是不存在已有实例，所以此时极易出现冷启动问题。
·请求并发：当前一个请求还没有完成，就收到了新的请求，此时FaaS平台会启动新的实例来应对新的请求，进而出现冷启动问题。
·前后两次触发间隔太久：函数的前后两次触发时间间隔超过了实例释放时间的阈值，也会引发函数的冷启动问题。
目前来看，Serverless架构所面临的冷启动挑战虽然严峻，但并不致命，因为各个云厂商都正在努力推出冷启动问题的解决方案，包括但不限于实例的预热、实例的预留、资源池化、单实例多并发等。
2.厂商锁定
所谓的厂商锁定，指的是不同厂商开发的Serverless架构的表现形式是不同的，包括产品的形态、功能的维度、事件的数据结构等，所以一旦使用了某个厂商的Serverless架构，通常意味着FaaS部分和相对应的配套后端基础设施也都要使用该厂商的，若想进行多云部署、项目跨云厂商迁移等将会困难重重，成本极高。
众所周知，函数是由事件触发的，所以FaaS平台与配套的基础设施服务所约定的数据结构往往决定了函数的处理逻辑。如果每个厂商相同类型的触发器所约定的事件结构不同，那么在进行多云部署、项目跨云厂商迁移时就会产生巨大的成本。以AWS Lambda、阿里云以及腾讯云云函数为例，对象存储事件的数据结构对比如图1-9所示。
图1-9 AWS Lambda、腾讯云、阿里云对象存储事件的数据结构对比
通过图1-9的对比不难发现，3个云厂商关于同样的对象存储触发器的数据结构是完全不同的，这就导致开发者对对象存储事件关键信息的获取方法不同，例如同样是获取触发对象存储事件的原始IP：
按照AWS的Lambda与S3之间规约的数据结构，获取路径为：
sourceIPAddress=event["Records"][0]["requestParameters"]["sourceIPAddress"]
按照腾讯云的SCF与COS之间规约的数据结构，获取路径为：
sourceIPAddress=event["Records"][0]["event"]["requestParameters"]["requestSourceIP"]
按照阿里云的FC与OSS之间规约的数据结构，获取路径为：
sourceIPAddress=event["events"][0]["requestParameters"]["sourceIPAddress"]
由此可引申出，当开发者开发一个功能，在不同云厂商所提供的Serverless架构中实现时，涉及的代码逻辑、产品能力均是不同的，甚至业务逻辑、运维工具等也是完全不同的。所以想要跨厂商进行业务迁移、业务的多云部署，企业将面临极高的兼容成本、业务逻辑改造成本、多产品的学习成本、数据迁移风险等。
综上所述，由于目前没有完整、统一的且被各云厂商所遵循的规范，不同厂商的Serverless架构与自身产品、业务逻辑绑定严重，开发者的跨云容灾、跨云迁移非常困难。目前来看，各云厂商对Serverless架构锁定严重的问题也是开发者抱怨最多、担忧最多的问题之一。当然就该问题而言，无论CNCF还是其他一些组织、团队都努力在上层通过更规范、更科学的方法进行完善和处理。
3.配套资源不完善
所谓的配套资源不完善，指的是Serverless架构的核心思想之一是将更多、更专业的事情交给云厂商来做，但是在实际过程中，云厂商会碍于一些需求优先以及自身业务素质等问题，没有办法做更多“在Serverless架构中该做的事情”，导致开发者对基于Serverless架构开发项目、运维应用过程中困难重重，抱怨不断。
在Serverless架构飞速发展的过程中，各个厂商也在努力完善自身的配套资源和设施。尽管如此，Serverless架构还是有很多配套资源不完善，并不能让开发者更顺利地完成Serverless应用的开发、更轻松地对Serverless应用进行运维，主要表现在以下几个方面。
1）配套的开发者工具复杂多样，且功能匮乏：一方面表现在市面上开发者工具链匮乏，这导致开发和部署难度大，进而增加成本；另一方面表现在缺乏相关的工具链在体验层对Serverless体验进一步提升，优质工具链的匮乏导致本来就担心被厂商绑定的Serverless开发者变得更难与厂商解绑。2020年10月，信通院发布的国内首个《云原生用户调查报告》明确指出在使用Serverless架构之前，49%的用户考虑部署成本，26%的用户考虑厂商绑定情况，24%的用户考虑相关工具集完善程度。这些数据背后透露的实际是：开发者对于完善工具链的强烈需求。就目前情况来看，并没有绝对统一、一致的Serverless开发者工具，每个厂商都有自己的开发者工具，而且使用形式、行为表现并不相同，这就导致开发者在开发前的调研、开发中的调试、部署后的运维等多个层面面临很严峻的挑战。另外，绝大部分的Serverless开发者工具更多是资源编排、部署工具，并不能真正称为开发工具、运维工具，尤其在调试中不能保证线上和线下环境的一致；在运维时不能快速对业务进行调试，不能保证更简单地排查错误；在定位问题等方面并没有统一、完整的方案，这就导致Serverless架构的学习成本、使用成本对开发者来说会变得非常高。
2）配套的帮助文档、学习资源并不完善，学习成本过高。就目前情况来看，Serverless架构的学习资源相对来说是匮乏的，无论从文字、视频、实验等角度，还是从厂商提供的案例、教程、最佳实践等角度，都没有完善的学习资源和参考案例。正是由于Serverless学习资源比较少，开发经验案例比较少，开发者在学习阶段很难找到适合自己的学习资源，开发过程中经常会遇到未知错误，严重阻塞了Serverless架构在开发者侧的心智建设。
当然，上述几个方面也只是Serverless架构在配套资源、设施层面不完善的部分表现。除此之外，Serverless架构如何与传统框架更紧密地结合；传统业务如何更容易地迁移到Serverless架构；Serverless架构如何做监控、告警；如何管理Serverless应用与Serverless资源；Serverl-ess架构的科学发布、运维的最佳实践是什么样子的……这些问题也都是需要研究与探索的。
时至今日，对于Serverless架构尽管还有很多的挑战需要面对，但是各个云厂商都在努力摆脱困境，希望通过更好的体验助力用户将业务代码更简单、更快速地部署到Serverless架构，例如阿里云Serverless团队开源的Serverless Devs就是一款无厂商锁定的Serverless应用全生命周期管理工具。
如图1-10所示，Serverless Devs可参与到项目的创建、开发、调试、部署与运维的全流程，以阿里云函数计算组件为例。
图1-10 Serverless Devs项目全生命周期管理Serverless应用示意图
·在项目的创建环节，可通过开发者工具或者应用中心进行项目的最初创建。
·在项目开发环节，可以通过本地开发、调试等能力来验证本地开发的正确性。
·在项目调试环节，可以通过本地调试与远程调用、日志查询等能力进行项目的最终调试。
·在项目部署环节，可以先通过依赖安装、项目构建等流程构建完整的部署包，再进行项目的部署。
·在后期运维环节，可以通过指标查询进行项目健康度检查，通过日志查询等进行问题定位，通过项目发布等能力进行版本发布、别名发布以及灰度发布等。
除此之外，各个云厂商在学习资源层面大力支持。图1-11是腾讯云Serverless团队提供的Serverless学习路径课，图1-12是阿里云开发者社区提供的大量Serverless课程。
图1-11 腾讯云Serverless团队提供的Serverless学习路径课
图1-12 阿里云开发者社区提供的大量Serverless课程
4.其他挑战
Serverless架构如今已经非常热门，各个厂商也都在付诸更大的努力完善自身的Server-less产品，推动Serverless生态和心智建设。但是，Serverless架构所暴露出的挑战，并不只有前面所描述的。
·Serverless架构在某些安全层面会有更大的挑战：尽管把更专业的事情交给更专业的人，让Serverless架构在安全层面有了更大的保障，但是由于Serverless架构的极致弹性能力让开发者产生了更多的担心，“如果有人恶意对我的业务进行流量攻击，Serverless架构的极致弹性和按量付费会不会让我迅速产生巨大的损失？”曾有创业公司因为遭受恶意流量攻击，一夜之间损失数千美元。所以，当安全性更高、性能更好的Serverless架构面对流量攻击时，所表现的结果是产生巨大的费用支出。这与传统云主机所表现出的“无法提供服务”是不同的，但是更让开发者担忧。尽管现在很多厂商都在通过API网关的白名单与黑名单功能、函数计算的实例资源上限配置等相关功能解决该问题，但仍然值得开发者关注和深思。
·出现错误难以感知也难以排查：由于Serverless架构相对传统云主机架构更有“黑盒”即视感，所以在Serverless架构下进行应用的开发，往往会出现一些难以感知的错误。例如某些经验不足的Serverless应用开发者在使用对象存储触发器时就可能会面临严重的循环触发问题，具体为“客户端上传图片到对象存储，对象存储触发函数执行图片压缩操作，之后将结果图片回写到对象存储，如果这里的触发条件设置不清晰，就可能导致循环触发压缩、回写操作”。有用户在使用S3触发AWS的Lambda时出现了循环回写和触发操作，产生数百美元的额外支出，直到账单报警才发现这个问题。当然，除了刚刚所描述的错误难以感知之外，Serverless架构还存在错误难以排查的挑战。常见的情况是，用户在本地进行业务逻辑开发并调试完成，将代码部署到线上后出现偶然性错误，此时由于无法登录机器进行调试，并且实例可能在触发之后被释放，出现了问题难以定位、难以溯源等挑战。
与Serverless架构的优势一样，即使在上文中已经举例说明很多Serverless架构所面临的挑战，我们仍然没办法枚举其现阶段的全部劣势。虽然一些挑战已经有一些解决方案，但也会因为用户需求过于强烈，存在一些违背Serverless思想的方案。例如：为了更好地解决冷启动问题，多家云厂商先后提出了实例预留功能，即当开发者无法信任Serverless平台可以更好地做弹性伸缩时，为了最大限度地减少冷启动带来的性能问题，云厂商允许开发者提前预留一些实例，以备不时之需。诚然，这种做法在一定程度上与Serverless所主张的思想有一定冲突，却也是当前解决冷启动带来的性能损耗的一个比较有效的手段。
综上所述，Serverless架构所面临的挑战很多，但也会因为这些挑战给更多组织、团队带来新的机会。