最近好几个做独立开发的同事在群里问我同一个问题ECS云服务器和Serverless函数计算到底怎么选。他们看到我一边用着按量付费的云主机跑着常驻服务一边把一堆小接口丢到函数计算上觉得有点精神分裂。其实这两个东西不是竞品更像电动手工具和流水线的关系一个让你想怎么干就怎么干另一个替你规定好了流程和节奏。这篇文章我就以自己这些年实际部署、迁移、踩坑的经验把两者的区别拆开讲清楚顺带给出可以直接抄作业的选型方法。1. 先把话说清楚ECS和函数计算到底差在哪1.1 ECS是一台永远开着的云上电脑ECS弹性云服务器本质上就是一台跑在云端数据中心的虚拟机。你付钱租下它之后就会有固定规格的CPU、内存、系统盘和带宽配额你可以像操作自己家里的电脑一样通过SSH登录上去安装任何软件改任何配置跑任何常驻进程。我最早接触云服务器第一反应就是这不就是远程桌面那套东西吗确实很像只不过你拿到的不是图形界面而是一个随时可以折腾的Linux环境。这种云上电脑最大的特点是你拥有完整的操作系统控制权。想装MySQL就装MySQL想跑Python 3.9就自己编译想部署Nginx反代、Redis集群甚至自己挂个定时任务扫描日志全都一句话的事。代价是你得自己负责安全加固、系统补丁、软件依赖、磁盘空间所有事情都逃不掉。日常开发中常见的ECS用法包括部署Web应用、当作数据库服务器、搭建自动化构建跑批任务的Jenkins或者用来给家里的设备做一个稳定的公网入口。1.2 Serverless函数计算是一段按次数执行的代码函数计算Function Compute缩写FC就完全不同了。它根本不给你一台可以登录的机器而是提供一个把代码扔进去由平台负责调度执行的运行环境。你只关心自己的业务函数比如收到某个HTTP请求时去查一次数据库并返回JSON至于函数跑在哪台物理机、跑在多少个实例上、什么时候启动统统不需要管。平台会根据请求量自动扩缩容没有请求的时候甚至可以缩到零让你一分钱都不用付。Serverless这个名字其实挺有误导性不是让你没有服务器而是让你感受不到服务器的存在。最直白的类比是食堂打饭ECS是你自己租了个厨房锅碗瓢盆、食材采购、排风管道全得自己管但你想几点做饭、做什么菜都自由函数计算是你去食堂窗口点菜你只关心菜好不好吃、上菜快不快食堂后台的厨师、灶台、采购流程跟你完全没关系。1.3 一张表看懂核心差异很多新手纠结选型是因为没弄明白两者的边界。我整理了一张对比表基本覆盖了大家最关心的维度对比维度ECS云服务器Serverless函数计算资源形态固定规格的虚拟机可登录无实例概念只有运行时运行时长7x24小时常驻按调用触发空闲时缩容到零弹性伸缩手动配置规格/自动伸缩组平台自动弹性秒级扩容计费模型按CPU/内存/带宽/磁盘包时包年按调用次数运行时长GB-秒计费运维范围系统、依赖、安全、监控全自助平台管运行时你只写代码冷启动无进程始终在跑首次调用需初始化有延迟适用类型长连接、大内存、有状态服务短任务、事件驱动、突发流量成本特征空转也计费无请求基本不花钱这张表只能帮你建立初步判断。接下来我要展开说三个最关键的点计费、冷启动、运维边界。这三样决定了你实际使用的体验也是我替别人做过好多次迁移后总结出的核心决策依据。2. 选型先看这三样计费、冷启动、运维边界2.1 计费模型包年包月与按量计费的账怎么算先说钱的问题。ECS的计费思路特别简单你定一台2核4G的实例按小时或者按年付钱不管你这台机器实际使用了多少CPU空转也扣费。以我实际使用过的某云厂商为例2核4G的按量计费大约是0.2元/小时左右一个月下来就是一百五六十元一年差不多一千八往上。如果你只是跑一个低流量的个人博客、一个API服务这个成本其实不算低。函数计算的计费方式完全不同它分解成三个部分请求次数、资源占用时长、公网流量。资源占用时长的单位是GB-秒意思是你的函数配置了512MB内存执行了1秒就消耗0.5GB-秒的资源。公网流量按出方向流量计费。直观理解就是你点一次接口跑0.3秒按512MB内存算消耗大概0.15GB-秒费用极小没人调用的时候费用就是零。我拿一个真实场景算过账。一个天气查询接口通过定时任务每5分钟拉一次第三方数据、存到对象存储日请求量大约两三千次。放在ECS上就算只跑一个Python脚本包年也要一千多元放到函数计算上用一个定时触发器每天执行24次每次运行5秒512MB内存一个月下来资源费大概几块钱流量费根据数据量另算。两者差距是数量级的。但这里有个特别容易踩的坑函数计算的计费和你写的代码质量强相关。如果你在函数里用多线程并发、配置大内存规格、循环里做大量耗时操作费用会成倍往上翻。之前在项目里给一个数据同步任务随便配了2GB内存结果一个月账单是预期的三倍。所以做Serverless一定要养成习惯先看单次执行的资源消耗和耗时再评估总费用。2.2 冷启动与常驻实例函数计算的第一脚油门接着就要聊一个让很多初学Serverless的人血压升高的东西冷启动。函数计算的底层逻辑是按需启动当一个函数在短时间内没有请求时平台会把运行实例回收掉。下一次请求进来它必须重新加载代码、初始化运行时、执行你的初始化逻辑这一整个流程就叫冷启动。冷启动耗时和语言关系很大。我用过的几种运行时里Python和Node.js冷启动一般在一两百毫秒到几百毫秒之间Java由于JVM和依赖加载比较重冷启动经常跑到一两秒甚至更久。如果你的业务是面向用户的高频接口每次请求都赶上冷启动体验就很糟糕。所以云厂商普遍提供预留实例功能相当于你额外花钱让平台提前准备好几个热实例待命冷启动问题基本消失但要承担类似ECS的常驻成本。实战里的核心建议是如果函数需要被实时调用且对延迟敏感要么配预留实例要么一开始就用ECS如果函数是定时任务、消息队列触发、webhook回调这种对首包延迟不敏感的场景默认的按需实例完全没问题。我在实际项目里会单独建立一个性能测试目录专门记录带冷启动和热调用的P95延迟用数据决定函数计算到底能不能扛住业务。2.3 运维面谁帮你擦管子谁让你自己上手运维边界是另一个决定性因素。ECS给你的自由度越大你需要操的心就越多。我在一台长期运行的ECS上做过完整的日常维护安全补丁要定期打Python版本不能随便升级因为可能搞坏现有依赖Nginx日志每天疯涨磁盘空间要盯MySQL的慢查询得定期清理还有就是半夜收到磁盘告警的邮件爬起来登录服务器清理日志。这个过程说不上多难但确实繁琐。你是在做一份云服务器管家的工作。函数计算把这层事情基本给抹掉了。我不需要关心EC2底层是不是宕机不需要看系统日志因为平台会保证实例的可用性。我只需要关注自己的代码逻辑有没有问题依赖包有没有缺失权限配置是否正确。这个边界带来的直接变化是上线速度更快了原来部署一个服务要先备机器、配环境、再跑启动脚本现在写好函数上传就能用。但是Serverless的运维也有另类的心累。冷启动问题、并发上限、单个函数实例对数据库连接数的占用、临时磁盘大小、超时时间限制这些平台约束像隐形的手。你有时候得为了配合平台规则改造代码比如把原来的长连接改成短连接把超大文件拆分处理把有状态的部分外移到数据库或缓存。这种改造工作我第一次做的时候费了不少劲但改完之后的运维负担确实大幅度下降。3. 实操对比同一个城市天气查询接口这一节是大家最关心的部分。为了不纸上谈兵我拿一个真实的城市天气查询接口来做对照实验一端部署在ECS上一端部署在函数计算上把这个过程中的关键步骤和坑全部记录下来。接口逻辑很简单客户端传入城市拼音服务端去第三方天气API拿数据写入本地缓存返回JSON给前端。这个业务量级大概每日几百次到几千次请求。3.1 ECS上从零部署一个Python HTTP服务先看ECS侧。我选择的是一台2核2G的按量实例操作系统用Ubuntu 22.04地域选在靠近业务用户的地方。整个部署流程分六步首先通过SSH登录实例更新软件源并安装Python 3.9这里要用apt的software-properties-common仓库把Python 3.9拉下来因为默认的Ubuntu 22.04可能自带的版本不够。然后是创建虚拟环境我习惯用python3.9 -m venv venv把项目依赖隔离出来避免pip安装的包污染系统环境。接着写业务代码。用Flask写一个weather接口路由里拿到city参数先去Redis或者本地字典查缓存没有再请求第三方API最后用jsonify返回结果。这里要留意HTTP响应头的编码问题中文数据建议统一用UTF-8。然后是选择生产级Web服务器开发用的flask run根本扛不住并发我平时用Gunicorn配合多worker进程部署gunicorn -w 4 -b 0.0.0.0:8000 app:app。第四步用systemd把服务注册成守护进程这样SSH断开后服务还在跑开机也能自动拉起。systemd的Unit文件里要写清楚ExecStart的路径尤其注意虚拟环境里的gunicorn是绝对路径不能漏。第五步很关键配置云安全组放行8000端口。我早期有一次漏了这一步在服务器上怎么测都是通的一跑浏览器就超时排查了半天。安全组相当于防火墙默认只放行22等基础端口业务端口必须手动加规则。最后可选配一个Nginx反向代理把80端口的请求转发给8000端口顺便处理HTTPS证书。整个过程熟练的话大概四十分钟新手可能折腾两小时中间大概率会在依赖安装和安全组上卡住。3.2 函数计算上实现同样的接口再看函数计算侧。我选择的是Python 3.9运行时512MB内存超时时间设置为30秒。通过控制台或命令行工具Serverless Devs创建一个HTTP函数。函数代码的入口方法和ECS上有明显差异。HTTP触发器模式下你需要实现一个handler(event, context)event里带着请求方法、路径、查询参数、请求头context包含调用元信息。返回的时候不能像Flask那样直接return字符串而是要构造一个包含statusCode、headers、body的响应对象。这一步对于以传统Web框架写习惯的人特别容易踩坑我第一次迁移时直接return了dict结果前端收到的响应内容缺失排查了好一会儿才发现是响应格式不对。处理第三方API请求时函数计算允许你用requests库或者标准库的urllib但要注意出网方式。多数云厂商的函数计算在VPC内如果没有配置NAT或公网访问开关外呼第三方接口会被拒绝。这个坑我后来在配置里勾选了公网访问权限并在代码里加了显式超时控制避免外部服务变慢导致函数一直扣费。部署只需要一条命令完成打包上传之后用控制台生成一个测试事件点击执行就能看到返回结果和请求日志。绑定自定义域名也很方便在平台的域名管理里添加域名自动签发免费SSL证书。整个过程不超过十五分钟比ECS快一倍以上。实测同样规模的服务函数计算这种开发交付速度是真香。3.3 实测对比耗时、费用、心累指数两个版本都跑起来之后我做了对照测试。从响应延迟来看ECS上因为有常驻进程热请求延迟非常稳定P95基本在80毫秒左右。函数计算热实例的延迟跟ECS差不多也在一百毫秒以内但一旦触发冷启动P95能飙到800毫秒甚至一秒多。如果配上预留实例延迟差距缩小到几乎可以忽略但费用会上升。从费用来看这个接口在ECS上按量用一个月将近一百五十元年付能便宜点但也是一笔固定开销。函数计算用按量模式按每天一千次请求、单次执行0.3秒、512MB内存计算一个月的资源费大概几块钱。两者差价非常悬殊。若是把函数计算放预留实例费用翻倍涨但对比ECS还是有价格优势。说到心累指数两者各有各的头痛。ECS的痛是环境维护和半夜磁盘告警函数计算的痛是调试不直观不能SSH上去看只能靠日志和链路追踪。后者对用过传统运维方式的开发来说是段适应期。但纯按业务交付的角度函数计算的交付和维护成本明显低一个档次这也是我为什么把大多数非核心接口都迁到函数计算上的原因。4. 混合用法与选型建议4.1 什么样的业务更适合ECS虽然函数计算很省钱但并不是所有场景都适合。我根据自己的经验总结了几个ECS更适合用的情况。第一类是有状态服务比如WebSocket网关、IM聊天、游戏对战匹配。这些业务要求进程长时间保存会话状态函数计算的无状态、按请求调度模型很难适配强行做的话要么把所有状态外置到Redis要么改用性能较高的预留实例成本优势就没了。第二类是内存消耗和计算量都很大的任务比如视频转码、大数据清洗、复杂机器学习模型推理。函数计算的单实例内存上限有硬约束一般512MB到3GB之间你要么拆分任务要么升级配置但配置一高费用就开始向ECS靠拢。GPU实例目前也是ECS领域更容易获得做图形或AI推理的推荐选GPU云服务器。第三类是需要固定公网IP、特殊端口监听、特定内核参数的场景。函数计算只提供HTTP/HTTPS触发器自定义TCP端口基本做不到。如果你需要一个稳定的公网出网IP对接第三方白名单ECS的弹性IP是更直接的办法。4.2 什么样的业务更适合函数计算反过来函数计算真正擅长的是碎片化、事件驱动的事情。定时任务是最典型的。比如每天凌晨从数据库拉数据、生成日报、推送消息这种任务CPU占用不高、执行时间短、而且大多是周期性触发。用ECS跑定时任务你得专门养一台24小时开机的机器用函数计算的定时触发器没到点就零资源零费用到点自动执行完美契合。Webhook接口也是函数计算的强项。支付回调、GitHub钩子、表单提交通知请求量小但要求快速响应而且不能挂。事件触发场景更不用说比如对象存储的文件上传自动触发图片压缩消息队列里的每条消息触发数据处理都是用函数计算的经典模式。所以我的判断标准很简单任务有没有事件特征是不是按请求算钱比按时间算钱更划算如果答案是肯定的优先上函数计算。4.3 我推荐的三种混合架构实际生产里很少是纯ECS或纯函数计算我推荐大家把两者按职责切分。第一种模式是ECS做核心函数计算做外围。核心的业务API、用户系统、数据库应用跑在ECS上保证稳定性和可调试性周边的一次性任务比如数据导入、通知推送、报表生成全部丢给函数计算既省成本又不影响主流程。第二种模式是函数计算扛流量ECS做管理。把流量波动大的前台接口放到函数计算上利用它的自动扩缩容应对突发峰值用一台小型ECS跑管理后台、处理报表、执行运维脚本。我这里说的管理后台包括简单的定时备份云主机配置、批量执行运维任务之类的工作。第三种是函数计算做触发器ECS做工作节点。对象存储新文件上传后触发函数函数把任务信息写入消息队列ECS上的长驻worker从队列里拉取任务慢慢处理。这种架构既享受了Serverless的免运维触发机制又保留了ECS对重型任务的控制力。5. 常见问题与避坑速查5.1 ECS常见坑写到这里我把这几年在ECS上踩过的高频坑整理成速查表新手上路可以逐一排查。现象大概率原因解决办法SSH连不上安全组未放行22端口 / 密钥没配好控制台放行22端口用密码或密钥重新创建连接公网访问不了业务端口安全组只放行了默认端口在安全组规则里单独放行业务端口比如8000pip安装包总出错系统Python和项目Python混用建venv虚拟环境项目内统一使用绝对路径服务隔一段时间挂了系统OOM / systemd配置配错查看dmesg日志调整机器规格或加swap磁盘空间经常满日志文件无限增长配置logrotate轮转日志定期清理/tmp服务器时间不准没配置时间同步安装chrony指向常用的NTP服务器地址其中安全组和venv这两个坑基本是每个新手都会踩一遍的。我现在的习惯是拿到一台新机器先配好安全组白名单、设置好SSH密钥登录、挂上磁盘监控告警再开始装环境。这些前置工作虽然多花十几分钟但能避免后面半夜起来处理事故。5.2 Serverless常见坑函数计算同样有很多平台层面的暗坑刚上手时需要特别注意现象大概率原因解决办法第一次请求特别慢冷启动未预热对热点函数配置预留实例或做初始化缓存代码里写本地文件后失效函数实例无持久磁盘只写 /tmp 临时目录持久化数据放对象存储调用外部API超时未开公网访问或超时时间太短确认公网访问开关调大函数超时时间数据库连接数爆了每个实例都建独立连接改用连接池或代理控制最大并发实例数计费账单比预期高内存配置过大 / 函数死循环先看函数监控的执行时长与内存用量优化代码并发超过限制导致拒绝单函数并发上限触顶在控制台或配额工单里提高并发上限其中一个最隐蔽的问题是临时文件。函数计算运行在无状态环境中磁盘不保存数据下次调用可能分配到新的实例。很多从传统后端迁移过来的同事在函数里生成了Excel报表写到本地路径结果一个请求能下载下一个请求就报文件不存在其实就是实例被回收了。解决办法是把文件传到对象存储再返回URL不要在函数本地留文件。5.3 选择困难症速查表最后给选择困难的朋友一个条件匹配表。拿到需求先对号入座能省掉大量纠结时间判断条件推荐方案需要长连接、WebSocket、有状态会话ECS需要固定公网IP、自定义TCP/UDP端口ECS需要GPU、大内存超过函数上限ECS需要随时SSH上去调试、装系统软件ECS定时任务、消息触发、低流量API函数计算请求量波动大、想按量真正省钱函数计算团队没有专职运维想快速上线函数计算已有ECS想给外围任务减负两者混用在我个人的实践中函数计算并没有完全替代ECS而是把ECS从什么都干变成了只干最核心的事。以前一组服务全压在一台2核4G的ECS上CPU动不动就100%现在把统计、通知、定时任务全部拆出去用函数计算ECS只跑业务主链路负载下降了七成账单反而更省了。这两套东西不是对立关系更像是工具箱里的不同工具明白各自的能力边界然后组合着用才是正确姿势。如果你正在纠结选型我的建议是从一个小任务开始实验函数计算同时保留ECS上的核心业务。亲手部署一遍、观察一个月的账单和延迟比看十篇对比文章都管用。等你真正理解了冷启动和GB-秒计费的体感下次选型会变得特别自然。