1. Serverless与容器概述：什么是Serverless、什么是容器、为什么需要协同、核心概念对比
好，咱们直接进入正题。这一章是整门课的基石，我会把Serverless和容器这两个概念掰开揉碎了讲清楚。你可能会问，这两个东西现在这么火，到底有什么区别？为什么还要协同？别急，我们一步步来。
什么是Serverless？
说白了，Serverless不是真的没有服务器，而是你不需要关心服务器。你只管写代码，部署上去就能跑。至于服务器在哪、配置多少、怎么扩容——这些统统交给云平台去操心。
我记得刚接触Serverless那会儿，心里还挺没底的。总觉得「没有服务器」这事儿不靠谱。后来在项目中用了一次AWS Lambda处理图片缩略图，发现真香。你想想看，原来得搭个服务、配个负载均衡、搞个自动伸缩组，现在一个函数就搞定了。
核心特征：
- 事件驱动：有请求来了才执行，没请求就休眠
- 按量付费：用多少付多少，不用不付钱
- 自动扩缩：从0到成千上万并发，平台自动搞定
- 无状态：每次调用都是全新的环境
我的经验：做Serverless开发时，一定要把「冷启动」考虑进去。我曾经有个接口，平时响应20ms，冷启动时直接飙到2秒。后来用了预留并发才解决这个问题。
什么是容器？
容器，你可以理解成一个轻量级的虚拟机。但它比虚拟机轻得多——共享宿主机内核，只打包应用和它的依赖。Docker就是最典型的代表。
我刚开始用Docker的时候，最大的感受就是「环境一致了」。以前开发环境跑得好好的，部署到测试环境就崩了，这种破事我遇到过太多次。有了容器，本地跑什么样子，线上就是什么样子，再也不用背「环境问题」这口锅了。
核心特征：
- 轻量隔离：进程级隔离，启动秒级
- 可移植性：一次构建，到处运行
- 资源可控：CPU、内存可以精确限制
- 持续运行：容器默认是7×24小时在线的
为什么需要协同？
你可能会问，这两个东西不是竞争关系吗？其实不是。它们各有各的擅长领域，协同起来反而能发挥1+1>2的效果。
我举个例子你就明白了。假设你做一个电商系统：
- 核心业务（用户、订单、商品）——这些需要稳定运行、状态持久化，适合用容器跑在Kubernetes上
- 边缘业务（图片处理、消息通知、数据清洗）——这些调用频率不固定、计算密集，适合用Serverless
你看，容器负责「稳」，Serverless负责「活」。我在一个项目中就是这么干的——核心服务用K8s部署，图片压缩和日志处理用函数计算。效果非常好，成本降了40%，弹性也上来了。
注意：不是所有场景都适合协同。如果你的业务逻辑极其复杂、状态管理要求高，强行用Serverless反而会把自己坑了。我曾经见过一个团队把整个后端都塞进函数里，结果调试起来欲哭无泪。
核心概念对比
嗯，这里我整理了一张对比表，方便你直观理解两者的差异：
| 维度 | Serverless | 容器 |
|---|---|---|
| 运行模式 | 事件驱动，按需执行 | 持续运行，常驻进程 |
| 扩缩容 | 自动，从0到无限 | 需配置，有延迟 |
| 计费方式 | 按调用次数+执行时长 | 按资源占用时长 |
| 状态管理 | 无状态，需外部存储 | 可持久化，支持有状态 |
| 冷启动 | 存在，影响首次响应 | 无，始终在线 |
| 运维复杂度 | 极低，平台托管 | 中等，需管理集群 |
| 适用场景 | 短任务、异步处理、API | 长服务、微服务、有状态应用 |
避坑指南：我曾经在选型时犯过一个错误——把需要长连接的业务（比如WebSocket）直接扔到Serverless上。结果发现函数执行完连接就断了，根本没法用。后来老老实实改回容器部署。所以选型时一定要想清楚业务特性。
小结
这一章我们聊了Serverless和容器的基本概念，也分析了为什么需要协同。说白了，没有银弹。Serverless和容器各有优劣，关键是要根据业务场景做选择。
我个人习惯的做法是：核心业务用容器兜底，边缘业务用Serverless增效。这样既保证了稳定性，又兼顾了灵活性和成本。
下一章我们会深入实战，看看怎么在同一个项目中把这两个技术结合起来用。到时候我会拿一个真实的项目案例来拆解，保证你听完就能上手。