第一章：Serverless 基础概念——为什么我们需要它？
先聊一个我亲手踩过的坑。几年前我负责一个日志聚合服务，每天要处理几 TB 的 Nginx 访问日志。传统的做法是搭一套 Spark 集群，但运维成本高得离谱——半夜扩容、打补丁、调 JVM 参数，搞得团队苦不堪言。后来换了 Serverless 方案，代码量砍了一半，运维几乎为零。嗯，从那以后我再也没回头。
这一章我们不讲空泛的定义，而是从一个工程师的视角，把 Serverless 拆开来看：它到底是什么、主流平台怎么选、哪些场景该用它、哪些场景千万别碰。
1.1 什么是 Serverless 计算？
官方的说法叫“无服务器计算”。但你想想看，真的没有服务器吗？当然不是。服务器还在，只是你不用管了——云厂商替你搞定资源分配、扩缩容、补丁更新。你要做的只有写代码，然后上传，等着被调用就行。
我个人习惯用一个比喻来理解：传统架构像自己买车，得保养、加油、找车位；Serverless 像打网约车，车来了就用，用完下车，按里程付费。你根本不用操心车库里有没有车。
核心特征
- 事件驱动：函数被事件触发执行（HTTP 请求、文件上传、消息队列等）。
- 自动弹性：从 0 到上千并发，云厂商自动扩缩，你只管写逻辑。
- 按量付费：只付实际消耗的计算时间和资源，不跑着不花钱。
- 无状态：每个函数实例不保存上一次调用的数据，状态存外部（DB、缓存）。
为什么强调“无状态”？我曾经在项目中把用户会话直接存在函数内存里，结果下一请求被调度到另一个实例，数据丢了——排查了半天才反应过来。所以，记住：函数本身不做持久化。
小技巧：刚开始接触 Serverless 时，可以先从“事件处理函数”写起，比如处理对象存储（OSS/S3）上传事件。逻辑简单，踩坑少，很快就能感受到自动扩缩容的爽快。
1.2 主流云厂商 Serverless 产品对比
市面上三大巨头各有千秋。我用一张表帮你快速对齐关键差异。
| 维度 | AWS Lambda | 阿里云函数计算 (FC) | Azure Functions |
|---|---|---|---|
| 运行时支持 | Node.js、Python、Java、Go、Ruby、.NET、自定义运行时 | Node.js、Python、Java、Go、PHP、.NET、自定义镜像 | Node.js、Python、Java、Go、PowerShell、.NET |
| 最大执行时长 | 15 分钟（超时可联系提额） | 最长 24 小时（预留实例） | 10 分钟（默认），可无限（托管方案） |
| 并发弹性速度 | 极快，数千并发秒级就绪 | 较快，支持预留实例预热 | 一般，冷启动需预热计划 |
| 最大内存 | 10240 MB | 1536 MB（阿里云），ECI 场景可更高 | 1536 MB（消费计划），可自定义 |
| 触发事件源 | S3、API Gateway、SQS、SNS、DynamoDB 等 200+ 事件源 | OSS、API 网关、MNS、表格存储、CDN 等自研生态 | Blob、Event Grid、Service Bus、Cosmos DB 等 Azure 生态 |
| 冷启动时长 | 约 200ms – 1s（Java/Go 稍慢） | 约 300ms – 2s（依赖镜像大小） | 约 500ms – 3s（消费计划较慢） |
| 计费单位 | 1ms 粒度 + 请求次数 | 100ms 粒度 + 调用次数 | 1ms 粒度 + 执行次数（消费计划） |
| 中国区友好度 | 需全球/中国区切换，合规较复杂 | 原生支持，有等保、国产化认证 | 由世纪互联运营，支持国内合规 |
你看，Lambda 生态最成熟，冷启动快，但国内用起来有些绕。阿里云 FC 对国内企业更友好，能跑长任务（比如我们做日志巡检，有时候跑半小时以上），而且预留实例功能很实用。Azure Functions 在 .NET 生态里表现优秀，但冷启动一直是个痛点。
避坑指南：我曾经贪图 Lambda 的便宜，选了 Python 运行时做日志解析，结果数据量大时被 15 分钟超时卡死，最后不得不重构成流式处理。如果你要做长时间作业（比如全量日志扫描），优先考虑阿里云 FC 的 24 小时支持，或者把任务拆成小批次。
1.3 Serverless 适用场景与局限性
既然目录叫“日志巡检自动化实战”，那 Serverless 在日志领域简直是天选之子。但别急着把所有业务都搬上去，先看清楚边界。
适用场景
- 定时日志巡检：每天凌晨扫描昨天的错误日志，自动告警。用 CloudWatch / SLS 触发函数，写完即扔。
- 数据 ETL 管道：日志从 OSS/对象存储进来，函数负责过滤、转换、落地到数据库或数据湖。
- 实时报警聚合：接收日志流（Kafka / SQS），函数去重、聚合、发钉钉 / Slack 通知。
- Webhook / API 后端：日志平台的查询接口、配置前端等轻量 API。
局限性
- 冷启动：函数长时间不调用，下次触发需要初始化运行时和代码。对延时敏感的 API 可能受不了。
- 执行时长限制：就算阿里云 24 小时，也扛不住真的跑几天的大数据任务。
- 无状态：不适合需要长时间存会话或共享内存的场景（比如游戏服务器）。
- 调试难度高：本地模拟环境与线上总有差异，尤其是事件源和权限问题。我经常花了半天才发现是 IAM Role 没配好。
- 费用陷阱：高并发下调用次数和运行时长账单可能猛涨。记得设预算告警。
个人经验：如果你做日志巡检，建议先把离线、可分批的任务丢上去。比如全量日志扫描，我习惯按分钟窗口切片，每个函数处理 1 分钟的数据，超时风险为 0，也很容易调试。
说到这，我画了一张知识体系图，帮你把第一章的核心概念串联起来。你看一遍就能记住。