喧哗的背后：Serverless 的概念及挑战中，实现 Serverless 面临的挑战有哪些？

挑战一：业务轻量化困难 要实现彻底的自动弹性，按实际使用资源付费，就意味着平台需要能够在秒级甚至毫秒级别扩容出业务实例。这对基础设施是一个挑战，对业务，尤其是比较庞大的业务应用来说，更提出了很高的要求。如果一个应用的分发和启动需要十分钟，那么自动弹性的响应能力就基本无法跟上业务流量的变化了。解决这个问题有很多方法，微服务化能够把巨型应用拆小；而 FaaS 就通过一种全新的应用架构，把应用拆分成更细粒度的函数来做到轻量化，当然，这种方法的缺点是需要业务做比较大的改造。对于 Java 语言来说，Java 9 引入的 modules，以及 GraalVM 的 native image 技术都能够帮助 Java 应用程序瘦身，降低启动时间。 挑战二：基础设施响应能力不足 一旦 Serverless 的应用或者函数的实例能够实现秒级，甚至毫秒级扩容，相关基础设施就很快会面临巨大的压力。最常见的基础设施就是服务发现和日志监控系统，原本整个集群实例的变化频率可能是每小时几次，现在这个频率变成了每秒几次；此外，如果这些系统的响应能力跟不上实例变化的速度，例如对于业务来说，容器实例 2 秒就完成了扩容，但还需要等待 10 秒服务发现才能完成同步，那么整个体验也 就大打折扣了。 挑战三：业务进程生命周期与容器不一致 Serverless 平台依赖标准化的应用生命周期，才能实现完全自动的容器腾挪，应用自愈等特性。而在基于标准容器及 Kubenetes 的体系下，平台能控制的生命周期就是容器的生命周期。因此就需要业务做到业务进程的生命周期和容器的生命周期保持一致，具体包括启动、停止、以及 readiness probe 和liveness probe 的规范等等。在实际情况中，很多业务虽然做了容器化改造，但实际上容器中除了包含业务主进程之外，还包括很多辅助进程，这也会导致业务进程和容器的生命周期不一致。 挑战四：可观测能力需完善 在 Serverful 的模式下，如果生产环境出现任何问题，服务器是不会消失的，用户会很自然的想到登陆到服务器上去，操作 linux 命令，搜索日志，分析进程，甚至 dump 内存来进行问题分析。到了Serverless 模式下，我们说用户不需要关心服务器了，也就是说默认情况下是看不到服务器了，那么这个时候如果系统出现异常了，而且平台无法完成自愈怎么办呢？用户还是需要有丰富的排查诊断工具，能够观测到包括流量、系统指标、依赖服务等等各方面综合的状态，以实现快速准确的问题诊断。当围绕Serverless 模式的全面可观测能力不足的时候，用户必然不会对此感到放心。 挑战五：研发运维心智需要改变 几乎所有的研发，在职业生涯中第一次部署自己的应用程序的时候，都是面向一台服务器的，或者说是面向一个 IP 的，这是一种非常强大的习惯。今天我们依然能看到很多的应用程序还是有状态的，无法做到自动更换实例；也能看到很多的变更部署行为和 IP 绑定了起来，例如单独选一台特定的机器做 Beta 等 等；还有许多发布系统，在做 Rolling Update 的时候，是不会更换实例的，相关的运维系统也就基于这个假设建设能力了。在 Serverless 逐渐落地的过程中，研发需要转换一些思维的模式，逐步地去适应 “IP 随时可能会发生变化” 这样一种心智，转而更多的从服务版本，以及从流量的视角去运维自己的系统。

答复内容摘自《云原生技术与架构实践年货小红书》，这本电子书收录开发者藏经阁 下载连接：https://developer.aliyun.com/topic/download?id=1127