Serverless 落地之痛有哪些？

挑战一：冷启动耗时长 快弹是 Serverless 天然自带的属性，但是快弹的条件是要有极致的冷启动速度去支撑。在非核心的业务上，毫秒级别的延时，对业务来说几乎不受影响。但是，对于核心业务场景，延时超过 500 毫秒已经会影响到用户体验。虽然 Serverless 利用轻量化的虚拟技术，不断的降低冷启动，甚至某些场景能降低到 200 毫秒以下。但这也只是理想的独立运行场景，在核心业务链路上，用户不仅是运行自己的业务逻辑，还要依赖中间件、数据库、 存储等后端服务，这些服务的连接都要在实例启动的时候进行建连，这无形中加大了冷启动的时间，进而把冷启动的时间加长到秒级别。对于核心在线业务场景来说，秒级别的冷启动是不可接受的。 挑战二：与研发流程割裂 Serverless 主打的场景是像写业务函数一样去写业务代码，简单快速即可上线，让开发者在云上写代码，轻松完成上线。然而在现实中，核心业务的要求把开发者从云上拉回到现实，面对几个灵魂拷问：如何做测试？如何灰度上线？如何做业务的容灾？如何控制权限？当开发者回答完了这些问题，就会变的心灰意冷，原来在核心业务上线中，“函数正常运行”只占了小小的一环，离上线的距离还有长江那么长。 挑战三：中间件的连通问题 核心在线业务不是独立函数孤立运行的，需要连接存储、中间件、数据中后台服务，获取数据后再计算，进而输出返回给用户。传统中间件客户端需要打通和客户的网络、初始化建连等一系列操作，往往会使函数启动速度下降很多。Serverless 场景下实例生命周期短、 数量多，会导致频繁建连、连接数多的问题，因此针对在线核心应用常用的中间件的客户端 进行网络连通优化，同时对调用链路进行监控数据打通，帮助 SRE （Site Reliability Engineer ）从业者更好的评估函数的下游中间件依赖情况，对于核心应用迁移上 Serverless 非常重要。挑战四：可观测性差 用户大多数的核心业务应用多采用微服务架构，看核心业务应用的问题也就会带有微服务的特性，比如用户需要对业务系统的各种指标进行非常详尽的检查，不仅需要检查业务指 标，还需要检查业务所在系统的资源指标，但是在 Serverless 场景中没有机器资源的概念，那这些指标如何透出？是否只透出请求的错误率和并发度，就可以满足业务方的需求？ 实际上，业务方的需求远不止这些。可观测性做的好坏还是源于业务方是否信任你的技术平台。做好可观测性是赢得用户信任的重要前提。 挑战五：远程调试难度高 当核心业务出现线上问题时，需要立即进入调查，而调查的第一要素就是：现场的保留， 然后登陆进行调试。而在 Serverless 场景中没有机器层面的概念，所以如果用户想登陆机器，在现有的 Serverless 基础技术之上是很难做到的。当然原因不仅限于此，比如 V endor-lockin 的担心等。上面几大类痛点的概括，主要是针对开发者的开发体验，对于实 际的开发场景中，是否真的是"提效", 而不是新瓶装旧酒。目前仍有大部分核心应用开发者 对 Serverless 还是持有观望状态，当然也不乏一些质疑观点，“FaaS 只适合小业务场 景以及非核心业务场景”。

答复内容摘自《云原生大规模应用落地指南》，这本电子书收录开发者藏经阁 下载连接：https://developer.aliyun.com/topic/download?id=1055