函数计算如何在 AI 浪潮下顺利出圈？

函数计算的价值

每个企业都应该配备一个高效的函数计算平台，无论是直接使用公有云还是因涉及敏感数据而需私有部署，因为函数计算能为企业显著节省巨额成本，极大地提高业务更新迭代速度，助力企业更快发展。

|- |传统方式 |函数计算| 价值|
|-|-|-|
|应用开发周期 |以月为单位| 天/小时/分钟| 应用迭代速度是企业高速发展的核心|
|参与人员 |开发/运维| 开发&AI| 原先需要一组人员的任务，现在借助函数计算或许仅需数名开发人员，借助 AI 能力甚至只需了解需求的人参与
|人员要求| 高专业要求| 低专业要求 |只需掌握业务逻辑即可，无需过多专业知识。|
|资源要求 |资源浪费/利用率低| 资源利用率极高 |平均资源利用率低于 30% 的基础设施，借助函数计算可降低成本 50% 以上。|

应用开发周期

例如，我司开发许多功能模块真的就是分钟级，且具有高度复用性，如各种三分钟系列：

• 三分钟实现注册登录

• 三分钟接入微信支付

• 三分钟实现 ChatGPT👇

三分钟拥有自己的 ChatGPT (从开发到上线)

这里并非编写一个仅供娱乐的示例，而是真正具备线上服务能力。最重要的是，这三分钟并非仅编写代码，还包括将代码在线上运行！写完即发布，点击保存，关机走人。

因此，基于函数计算去开发应用，开发周期的单位都是以分钟/小时/天来计算的。我的合伙人马斯洛同学经常在与他人开会教授别人如何操作时就完成了编写，效率之高令人惊叹。

这很像一个完全可定制化的业务中台，不仅是简单地获取一个业务接口，而是拿到之后很方便就可以定制。例如，提供一个微信支付接口不如提供一个微信支付 function，拥有了 function，您便可以轻松地添加自己的支付逻辑。

参与人员

使用函数计算，一个人顶一个团队并无夸张。首先，运维人员在这个模型中并不存在，甚至连运维动作都不存在。就像发布一篇博客，您需要运维动作或者运维人员帮忙吗？既然发布博客不需要，那为什么发布业务代码需要呢？

其次什么 DevOps 什么容器 Kubernetes，对不起老夫只会一把梭，K8s 单词怎么拼老夫都不知道，也不需要知道。

函数计算理想情况下同时也消除了企业内部的 DevOps 团队。因此，在理想情况下，企业仅需要保留少量开发人员，他们只需关注业务逻辑。这样节省的人力成本是非常惊人的，大多数企业都可减少 50% 的员工。但如果需要的是私有云，那可能需要额外投入一个人来维护函数计算平台。

最理想的情况是开发人员也不需要了，只需会写需求即可，让 AI 生成全部代码。这一天肯定不远了（作者本身也是开发者，已经准备好了美团外卖账号，短期内 AI 还无法送外卖）。

人一多必然增加沟通协调等隐性成本，这是难以察觉但却极高的成本。

人员要求

过去需要高薪才能编写安全、稳定、高并发的程序，如今月薪 3k 的人也能完成。你只需要写业务代码，其他问题由函数计算平台来解决，如高并发、横向伸缩等，都由平台全权解决。

AI 进一步降低了对人的要求。作者本人并不十分精通 TypeScript，但在 AI 的帮助下，编写出可用于生产的代码几乎没有问题。关键是 AI 仍在进化，技术呈爆炸式发展。在未来三年内，AI 的编码能力将使人类望尘莫及，人类将更多地为 AI 提供支持，而 AI 将成为主程。

资源要求

只要资源利用率低于 30%，就有巨大的降本空间。使用函数计算的降本可不是降一点点，而是成本“脚脖子斩”。

例如，在一个场景中需要部署 5000 个小应用。传统方式可能需要部署 500 台虚拟机，每台部署 10 个应用，这个密度已经不低了，而且还需要避免这 10 个应用免相互干扰。

而使用函数计算，可以将这些应用部署到仅 10 台服务器上。低频应用一个节点运行 500 个函数是很常见的情况。而且无需关心应用的管理、隔离和高可用问题。

对于高并发应用，只需增加一些函数副本，即可在整体利用率未达到临界水位时继续塞满。

实际上，许多拥有超过 100 人研发团队的企业，在使用传统方式运行应用时，都在很大程度上浪费了资源。即使采用了容器等技术，与函数计算相比仍有很大的提升空间。

我们团队内部运行了 1000 多个函数，仅使用了 10 台低配虚拟机。业务增长时只需简单增加服务器即可。

函数计算未能普及的三大障碍

函数计算如此强大，似乎每个人都应该使用它，本应早已广泛应用。那为什么目前整个市场仍未普及呢？

我总结了以下三点原因：

*** 大众市场难以接受变革**，难以从熟悉的开发方式转变。即使新方式具有诸多优势，人们对破坏性创新仍然抱有天然抵触。

• 大部分应用无法在函数内实现完全闭环，导致仍需依赖其他开发方式。为了便利，人们可能会因为一些小需求而重归传统方式。
• 先进的非 Serverless 框架的竞争与挑战（例如，使用 Java 进行函数计算可能会面临 Spring Cloud 框架的挑战，如果采用了函数计算，可能就需要放弃其他框架的优越特性。）

开发方式的割裂

绝大多数函数计算都需要修改代码，无法与既有代码保持兼容，也不太容易将代码复制到传统环境中运行。这导致现有业务需要修改代码才能享受巨大好处，尽管利益很大，改造成本也相当高。

大众市场对于变革天生抵触。尽管绝大多数公司的口号都是拥抱变革，但当变革真正到来时，他们又会变得保守。

此外，你无法确定今天改完了代码，明天是否会出现更先进的技术。

非 Serverless 框架的挑战

函数计算还面临着其他优秀编程框架的挑战。例如，你使用 Java 进行函数计算就很尴尬，因为主流方式是 Spring Cloud。如果你要兼容 Spring Cloud 框架，那么你可能就不再是函数计算；如果你不兼容，那就需要在编程体验上做得比 Spring Cloud 更好。

你绝对很难在各种编程语言中把你的 function 框架做到最流行。因为函数计算还是一个相对较新的技术，许多开发人员可能对其不太了解，或者对其持观望态度。而这些主流框架已经拥有了成熟的生态系统和广泛的用户群，这些因素可能会对函数计算的普及产生阻碍。

适用场景有限

函数计算适用于某些特定的场景，如短暂的、计算密集型任务等。对于需要长时间运行或者需要与其他服务紧密集成的应用程序，函数计算可能不是最佳选择。这限制了函数计算在业务中的应用范围。

举个例子，很多 function 不支持常驻进程，这样就没法做长连接（当然有些已经支持了），这样开发者又得搞个传统的方式来支持这一个小特性，笔者最开始时就是遇到这个情况，本想 all in function 一把梭的，结果为了长连接又得搞台虚拟机，让事情变得更复杂了，所以后来索性抛弃了 function。

长连接只是个例子，还有其他 n 个需求满足不了导致无法使用 function 的尴尬境地。比如 function 的冷启动，有调用时还会消耗资源，这听起来好性感，但是业务跑起来想吐血，比如这样连一个 ChatGPT 的会话保持都实现不了。

所以这个技术不够通用导致用起来比较尴尬。

函数计算何时才能出圈？

要使函数计算流行起来，需要解决以下几个核心问题：

❶** 降低门槛，优化编程体验**：让开发者能够更快速、简便地体验开发、上线整个流程。产品设计要简洁易用，让开发者可以轻松上手。

比如 Laf 在 40s 就能体验开发上线全流程，整个过程无门槛，我们非技术背景的投资人都能轻松搞定整个上线过程。

这个初次体验的过程但凡有一点点障碍或者体验不好的地方，都会直接劝退 90% 的人。

❷** 简化计费方案**：许多云服务厂商的计费方案复杂难懂，应该设计简单明了的计费方案，让用户能够清晰了解自己的成本。

现在很多厂商的计费方案真的是一言难尽，你花一周时间去算都算不明白，形同虚设的价格方案设计，鬼知道我的函数调用时长有多长，花一周时间去研究怎么收费，这不是太可笑了嘛。

❸ 一定要开源：开源可以消除用户对于函数计算服务可能被下架或价格提高的担忧。此外，开源还有助于满足源码交付等需求。

开源的好处显而易见，即使提供服务的公司凉凉了，用户还是可以自己部署和使用。

❹ 成为优秀的流行框架：面对非 Serverless 优秀框架的挑战，函数计算需要努力成为更具优势的框架。这需要不断优化和改进，以满足市场需求。

Laf 开源以来只发布过两次文章，两次都实现了爆发式增长，也在 GitHub 趋势榜上待了一周，发布当天每天有 400 多应用被创建，付费上线 6 小时营收过千，每日 Star 数量增长 50+，这只是个开始，Laf 成为流行的函数计算框架指日可待。

❺ 关注实际业务需求：不要过度追求高大上的技术，而是要关注实际业务所需。例如，在冷启动方面，不需要过度研究节省成本和资源的技术，而是要关注如何满足大多数业务场景的需求。

很多冷启动技术方案搞得天花乱坠，但在业务层面上反而加深了技术与业务的割裂，因为实际上大部分业务都是运行在常驻进程中。虽然冷启动可以节省成本和资源，但实际节省的金额可能相当有限。相反，那些需要在请求到来时快速创建容器并预热的方案可能会带来更高的技术成本。

Laf 就选择了常驻进程的方式，这样就能够在保留原生运行方式的基础上，将开发者的注意力集中在业务逻辑本身，不需要关心其他事。这种方式不仅降低了技术与业务的割裂，还能满足大部分需求。还有个非常重要的一点就是Laf 是运行在 Sealos 云操作系统之上的，所有的扩展工作都可以在 Sealos 云操作系统中进行，例如在 Sealos 上运行 AI 引擎并通过 Laf 进行调用，实现完美融合。

❻ 最后一个关键因素是时机：函数计算作为一种新兴技术，更容易在新的技术浪潮中爆发，也就是 AI 的崛起。在这个大浪潮中，必然会有很多新的应用需要被开发出来。选择使用函数计算来开发 AI 应用的公司必然在竞争中胜出，因为在这个浪潮中兵贵神速。使用函数计算可以按照分钟或小时来计算开发进度，而传统的公司可能仍在缓慢地进行迭代和上线，必然会在竞争中落后。

例如，我们开发的 chatmind（AI 生成脑图的应用）仅用了一天时间就完成开发，上线当天就吸引了10000 名注册用户。这是传统开发方式无法实现的。因此，函数计算将随着 AI 领域的崛起而共同发展壮大。

引用链接

[1]
Laf: https://github.com/labring/laf

[2]
Laf: https://github.com/labring/laf

[3]
Sealos 云操作系统: https://github.com/labring/sealos

[4]
chatmind: https://www.chatmind.tech/

sealos 以kubernetes为内核的云操作系统发行版，让云原生简单普及

laf 写代码像写博客一样简单，什么docker kubernetes统统不关心，我只关心写业务！