企业应用的无服务器与边缘计算：何时适合，何时不适合

许多企业主第一次听到“无服务器”（serverless）这个词，往往来自供应商或热情的工程师：“不用管理服务器，按用量付费，自动扩缩容。”这句话只对了一部分。无服务器和边缘计算确实可以减轻运维负担，并让分布在多地的用户获得更快的访问体验，但它们也带来限制、不同的成本结构，以及与普通服务器不同的调试方式。

本文用通俗的语言说明什么是无服务器和边缘计算、哪些工作负载适合、什么时候仍应使用普通服务器或容器、如何如实计算成本，以及如何在不危及核心系统的前提下进行尝试。

摘要

• 无服务器意味着你不管理机器；云服务商在请求到来时运行你的代码，并按用量计费
• 边缘计算在靠近用户的位置运行代码或提供内容，让响应更快
• 适合波动大的负载、短任务、Webhook、图片处理和轻量 API
• 不太适合长时间运行的流程、持续高负载以及依赖大量数据库连接的应用
• 小规模时每次请求成本很低，但在持续高负载下可能超过固定服务器
• 从一个非关键函数开始，衡量效果，证明有益后再扩大

什么是无服务器

“无服务器”这个名字有误导性，因为服务器依然存在，区别在于它们不再是你要操心的事。你编写一个函数或小型服务，上传到服务商，服务商只在有人请求时才运行它：访客打开页面、收到 Webhook、上传文件或定时任务触发。没有请求时就不运行，通常也不产生费用。

与普通服务器对比：你租用一台 24 小时开机的虚拟机，无论有没有访客都要付费，还要负责操作系统更新、容量规划，并在负载上升时增加机器。对技术团队较小的企业来说，这种管理负担是实实在在的。容器可以减轻其中一部分，参见企业应用的 Docker 与容器，而无服务器可以免去更多。

常见形式包括：

• 函数即服务：由请求或事件触发的短小代码
• 托管服务：由服务商运行的数据库、消息队列、文件存储和认证，你无需接触机器
• 现代网站托管，会为页面的动态部分自动生成函数
• 用于图片、文档和备份的对象存储

什么是边缘计算

如果你的用户分布在雅加达、泗水、棉兰、新加坡和吉隆坡，而服务器只在一个城市，每个请求要经过的网络距离各不相同。边缘计算把一部分处理放到全球多个节点上，让请求由靠近用户的位置响应。

最简单的形式是内容分发网络（CDN），保存图片、脚本和静态页面的副本。更进一步的形式是在这些节点上运行小段代码：按国家重定向访客、校验登录令牌、调整语言，或在响应到达用户前修改内容。基础知识见用缓存与 CDN 加速企业网站和应用。

需要理解的一点是：边缘对轻量处理很快，但你的主要数据通常仍在单一区域。如果边缘函数总要调用远处的数据库，速度优势就消失了。因此数据设计与代码设计同样重要。

适合的工作负载

无服务器和边缘在某些模式下表现突出。

波动剧烈的负载

促销时繁忙、平时冷清的网店，活动前一周达到高峰的报名应用，或只在月底使用的报表门户。固定服务器必须按峰值配置，其余时间闲置，而无服务器会自动调整。为高峰做准备时仍应测试，参见大促前的负载测试，因为并发限制和配套服务可能成为瓶颈。

短小独立的任务

上传后调整商品图片尺寸、生成 PDF 发票、发送确认邮件、处理支付网关 Webhook，或运行夜间定时任务。这类任务独立、几秒内完成，不需要机器一直运行。Webhook 模式参见Webhook 与实时集成。

轻量 API 与动态页面

读取少量数据并快速返回的接口，或内容部分在请求时生成的网页。许多现代托管平台会自动处理这些。

新项目与实验

当你还不知道产品是否受欢迎时，不为闲置服务器付费是一个优势，这与企业应用 MVP中从小处起步的原则一致。

事件驱动的处理

订单创建后需要发生几件事：扣减库存、发送邮件、数据进入报表。由事件触发的小函数很适合这种场景，尤其是配合消息队列，参见事件驱动架构与消息队列。

不太适合的工作负载

并非所有东西都值得迁移。

• 长时间运行的流程：需要几十分钟的大型报表、长视频处理或模型训练。无服务器函数通常有执行时间上限
• 持续的高负载：如果应用全天繁忙，固定服务器或容器的单次请求成本通常更低
• 数据库连接密集的应用：大量函数同时运行可能耗尽数据库连接，需要连接池或为无服务器设计的数据库
• 需要在内存中保存状态的系统：长会话、长时间保持的实时连接或大型本地缓存
• 对延迟要求极低且稳定：长时间未使用的函数可能“冷启动”，首次调用较慢
• 未设计为可拆分的旧系统，参见[在不中断运营的情况下改造旧系统](/blog/modernisasi-sistem-lama-legacy-tanpa-menghentikan-operasional)

对于核心 ERP、收银或会计应用，最稳妥的选择通常是稳定且可预测的架构。系统的边缘部分，如通知、定时报表和集成，可以先采用无服务器。类似的权衡也出现在单体还是微服务中。

如实计算成本

无服务器最大的吸引力是按用量付费，但要算对。

成本构成

• 请求或调用次数
• 执行时长和分配的内存
• 从服务商流出的数据传输
• 配套服务：托管数据库、存储、队列、API 网关和日志
• 常被遗忘的监控与日志存储费用

盈亏平衡点

小负载下，无服务器几乎总是更划算，因为不为空闲时间付费。大而持续的负载下，固定服务器可能更便宜。做一个简单的计算：估算每月请求数、平均时长和内存，再与租用一台足够的小型服务器比较，结果表会显示两条曲线的交点。成本趋势的跟踪参见控制企业云成本。

账单意外的风险

一个让函数反复调用自己的代码错误，或机器人攻击涌入某个接口，都可能在一夜之间让账单成倍增长。请设置并发上限、预算告警，以及针对自动化流量的防护，参见防范机器人与自动化攻击。

运维挑战

调试与监控

没有可以登录的机器，排障依赖日志和分布式追踪。请从一开始就做好结构化日志。指南见可观测性、日志与错误处理和监控与可用性。

本地测试

在笔记本上完全模拟无服务器环境并不总是完美。团队需要云端测试环境和自动化发布流程，参见自动化测试与 CI/CD以及基础设施即代码。

密钥与配置

函数多意味着 API 密钥多。请保存在密钥管理器中，而不是代码里，参见管理密钥与 API Key。

对服务商的依赖

无服务器函数常使用服务商专有的服务，迁移会更困难。这不是拒绝的理由，但需要退出策略，完整讨论见云端供应商锁定。实用做法是：把业务逻辑与连接服务商的胶水代码分开，不要把专有代码散布到整个系统。

安全与合规

无服务器把一部分安全责任（如操作系统补丁）转移给服务商，但不是全部。

• 权限仍由你负责：给每个函数授予最小必要的访问权限
• 验证所有输入，因为函数常对互联网开放
• 检查依赖项，小函数同样携带第三方库，参见[依赖安全与软件供应链](/blog/keamanan-dependensi-dan-rantai-pasok-perangkat-lunak)
• 注意数据位置。边缘函数在多个国家运行，而个人数据可能有位置限制，请结合[数据存放位置与托管合规](/blog/lokasi-penyimpanan-data-dan-kepatuhan-hosting-aplikasi-bisnis-di-indonesia)和[个人数据保护](/blog/pelindungan-data-pribadi-untuk-website-dan-aplikasi)一并评估
• 没有明确规则时，不要把敏感数据放入边缘缓存

分阶段采用的示例

设想一家中型网店，主系统在普通服务器上。一个合理的路径：

• 第 1-2 周：把商品图片尺寸调整迁移到上传时触发的无服务器函数。风险低，收益明确
• 第 3-4 周：把支付 Webhook 的接收迁移到一个把消息放入队列的函数，再由主系统处理。主系统故障时，Webhook 不会丢失
• 第 2 个月：用 CDN 和边缘规则把访客导向正确的语言和货币版本，与[面向区域市场的多语言网站](/blog/website-multibahasa-untuk-pasar-regional)相呼应
• 第 3 个月：评估成本、速度和事故次数，决定其他部分是否值得迁移

注意在有证据之前不触碰核心系统。这降低了风险，也给团队留出学习时间。

常见问题

无服务器一定更便宜吗？

不一定。小负载或波动大的负载通常更便宜；大而持续的负载下固定服务器往往更便宜。请用真实用量数据计算。

我的应用会变快吗？

对分布广泛的用户，边缘和 CDN 通常有帮助。但整体速度仍取决于数据库、页面大小和代码。变更前后请用核心网页指标中的指标衡量。

需要专门的技术团队吗？

需要懂云的人，但负担通常比自己管理服务器轻。良好的日志、测试和成本复盘习惯往往更重要。

已经在运行的系统怎么办？

不要重写。一次迁移一个边缘部分，衡量结果，让核心保持稳定。

结论

无服务器和边缘是工具，而不是目标。它们在波动负载、短任务、集成和分散用户方面价值最大；对于稳定负载和长流程，普通服务器或容器往往更合理。好的决策来自使用数据、如实的成本计算和可撤销的小规模实验。