前阵子帮朋友审一个上云方案第一轮方案评审就卡住了。运维同事坚持用ECS云服务器理由是“可控、熟悉、出问题能直接登进去看”后端同事却想用Serverless函数计算理由是“不用管服务器、按量付费、没人访问就不花钱”。两边各说各话谁也没能真正讲清楚ECS云服务器和Serverless函数计算到底有什么不同。这其实是很多团队第一次接触Serverless时的典型困惑。网上讲这两个概念的文章很多但大多是各自介绍一遍读完你依然不知道自己的业务该选哪个。这篇我想换个角度从底层资源、运维边界、计费模型、业务画像几个维度把它们掰开揉碎最后给一条从ECS迁到函数计算的实操路径。内容尽量贴近我实际做过项目的经验而不是抄文档。1. 先对齐概念ECS是“一直开机的电脑”函数计算是“有事才响的电话”想搞清楚两者的区别第一步不是背定义而是先理解它们在“计算资源”这个层面到底给了你什么。1.1 ECS云服务器到底给了你什么ECS全称是Elastic Compute Service弹性计算服务。它最核心的形态就是一台“云上的虚拟机”你租到的是一个完整的、独立的计算单元有CPU、内存、磁盘、网卡有操作系统甚至可以说就是一台你随时能远程登录的电脑。正因为它是“一台电脑”所以它的行为逻辑和你公司机房里那台物理服务器几乎没有区别。你拿到手之后要自己装操作系统镜像、配置安全组规则、装Nginx、装Python 3.9环境、部署应用、写systemd服务让进程开机自启、每天关注磁盘有没有写满、定期打系统安全补丁。这台机器只要不销毁它就会一直运行不管你业务有没有流量它都在那儿耗着电、占着资源。我见过很多团队用ECS实际上就是把它当一台永不关机的PC用。这种心智模型本身没有错但你必须意识到你购买的是“一个持续存在的计算资源”而不是“一次计算”。这是理解ECS和函数计算差异的根。1.2 函数计算到底帮你管了什么函数计算Function Compute属于Serverless架构的核心产品形态。它的最小交付单元不是一个服务器而是一个“函数”——一段代码加它依赖的运行时环境。你把这个函数上传到平台剩下的事情全部由平台接管什么时候运行、在哪里运行、分配多少资源、怎么扩容、怎么缩容你一概不用操心。怎么理解这件事我给你一个类比ECS像你雇了一个全职员工签了合同不管有没有活干每个月都要发工资并且你还得给他配工位、配电脑、管社保——对应到技术里就是操作系统、运行时、补丁、监控。函数计算则像你找了一个按单计费的顾问来了就干活干完就走你只需要告诉他“做什么”不需要管他坐哪儿办公、怎么通勤。这个类比能解释绝大多数产品差异。注意函数计算有时候也会常驻实例那就是“预热”和“实例复用”的问题后面我会专门讲冷启动时会提到先按下不表。1.3 一句话概括核心差异ECS卖给你的是“一台一直开机的电脑”函数计算卖给你的是“一次按需执行的计算”。前者是资源型产品你租的是“机器”后者是行为型产品你买的是“调用”。理解了这两个心智模型的差异后面的运维、计费、选型问题全部可以推导出来。2. 运维视角的差异系统你来维护还是平台替你代管概念对齐之后最直接的感受差异其实在运维。同一个应用部署在ECS上你要干的活和扔到函数计算上你要干的活完全不是一个量级。2.1 环境安装的隐性成本以Python 3.9为例最近很多人在搜索“云服务器ECS python3.9安装”说明大家刚从ECS入手时就碰到了环境配置这道坎。确实在ECS上装Python 3.9是必修课而且坑不少。以CentOS系统为例你至少要经历这几步用yum安装依赖编译工具链、下载Python 3.9源码包、configure配置编译参数、make make install、把新Python软链到/usr/local/bin、修改pip源、配置virtualenv虚拟环境。整个过程顺利的话半小时起步不顺利的话——比如编译过程报错缺openssl-devel、zlib-devel、libffi-devel——折腾一晚上也很正常。而且更麻烦的是系统自带的Python版本和你业务需要的版本经常冲突。我以前处理过一个线上事故有人图省事直接用系统的Python 3.6跑新代码结果因为f-string语法升级导致一堆兼容性问题。函数计算这边完全不需要关心这些。云厂商直接提供Python 3.9、3.10等官方运行时你在控制台选一个把代码包传上去就能跑如果是用Serverless Devs工具一条sdeploy命令就能完成构建和部署。底层GC、Python解释器、依赖库版本全部是平台预置好的标准环境。我这么说不是让你无脑放弃ECS而是在做技术选型时一定要把这部分“环境维护成本”算进去。ECS上每一个你亲手踩过的编译坑都该算成成本函数计算把这部分成本直接归零这就是两者运维模型最大的分野。2.2 扩缩容人肉扩容 vs 平台自动伸缩ECS的扩容动作是人做的。流量涨了你或者你的运维同学要先登录控制台看看当前实例的CPU和内存水位然后决定是升级配置纵向扩容还是再买一台机器加入负载均衡横向扩容。新机器从创建到可以对外提供服务哪怕用上了预置镜像和启动脚本也要几分钟到十几分钟。如果是线下机房这个时间还要按天算。函数计算的扩容是平台自动完成的。平台上配置好弹性伸缩策略之后来了100个并发请求平台就拉起100个函数实例并发降下去多余的实例在空闲一段时间后自动回收。整个扩缩容过程对用户完全透明。这里有个对比特别直观流量高峰前夜ECS团队通常要提前一周做压测、预估容量、准备机器这叫“计划内扩容”。函数计算不需要准备实例流量到了平台自动判断这叫“突发自适应”。从运维的角度来看ECS是一个需要你持续关注、主动干预的系统函数计算是一个本身就会自我调节的系统。两者不是好坏之分而是运维参与度的本质差异。2.3 安全补丁和故障处理的责任边界再提一个容易被忽视的点安全补丁谁来打。在ECS上从操作系统内核到运行时环境的所有安全补丁都需要你自己负责。你会经历“收到安全通告→评估影响面→找停机窗口→发版测试→灰度更新”这套完整流程。我一个朋友所在的公司因为一个内核CVE补丁迟迟不敢打结果被安全扫描发现生产环境存在已知漏洞等保评测没过非常被动。函数计算中操作系统层和运行时层的补丁全部由云厂商统一运维你只管业务代码。你的责任边界收窄到代码本身的漏洞、依赖库的安全版本、敏感信息的配置。责任边界缩小运维负担自然减轻这对小团队来说是实打实的福音。3. 计费模型的分水岭闲置时间到底花不花钱如果说运维差异是日常体感那计费差异就是决定你是否迁移的核心数据。3.1 计费单位完全不同ECS的计费单位是“资源持有时间”通俗讲就是“这台机器我租了多久”。按量付费的ECS按秒计费包年包月按整月计费核心是只要你持有这台机器不管业务有没有流量费用都照收。你租一台4核8G的机器跑个官网一天只有两三个小时有访问但一天24小时的钱一分不少。函数计算的计费单位是“计算用量”通常由两部分构成调用次数和实际运行时长GB-秒。所谓GB-秒就是函数实例规格以内存为基准乘以实际执行时间。如果配置了1GB内存的函数每次执行0.5秒那一次调用的资源用量大约是0.5 GB-秒。你一天只有1000次调用那就只收这1000次的费用夜里没有调用费用就是0。这个差异带来一个非常反直觉的结论**一台ECS即使闲置它也在帮你“烧钱”一个函数不调用它就完全是零成本的存在。**对流量波峰波谷特别明显、甚至长时间低流量的业务来说这个差异直接决定你一年的基础设施成本。3.2 用一个真实场景算一笔账为了更直观我拿一个实际项目来对比。假设有一个定时爬虫服务每天凌晨2点运行一次每次跑10分钟用来抓取数据入库。同时平时偶尔有用户手动触发几次数据刷新一个月大约100次额外调用。方案A用一台2核4G的ECS按量付费假设每小时约0.5元一个月30天下来就是360元左右。这还只是计算资源费用未包含磁盘快照、公网流量等隐性成本。方案B用函数计算资源配置为2核3GB内存每次爬虫实际运行600秒资源用量约为1800 GB-秒。国内云厂商的函数计算价格通常在0.000015元/GB-秒上下一次运行的成本约0.027元。一个月30天加上额外手动触发总成本大概1元左右。这个案例极端吗确实有点极端因为它就是典型的低频任务。但类似的低频、间歇性任务在真实业务中非常多数据清洗、报表生成、图片处理、webhook回调、定时通知。把这些任务从ECS迁到函数计算省下的不是小数目。我给你整理了一张不同业务形态下的成本感受对比表业务场景ECS成本特征函数计算成本特征高并发持续流量固定成本流量越大边际成本越低按调用计费流量大了成本上升明显低频定时任务持有成本高闲置浪费严重几乎只按执行时间收费成本极低突发脉冲流量需要预置容量或用伸缩组成本较高弹性按需高峰多收、低谷不花钱开发测试环境长期持有成本恒定随用随调用基本免费需要提醒的是函数计算并非永远更便宜。当你的业务是全天候持续高并发的API服务每秒几百上千次调用且从不空闲时按调用次数叠加的资源费用往往比包年包月的ECS要贵。这时候ECS或容器服务反而是更经济的选择。3.3 免费额度和突发账单是另一个隐藏变量选函数计算前还要看清免费额度。很多云厂商每月都提供一定量的免费调用次数和免费资源额度对小流量业务非常友好相当于白嫖。但也要警惕突发流量导致的账单暴涨。我见过有人写了个供内部Excel调用的函数结果Excel表格被同事分享出去VBA写了个死循环调用接口直接把当月费用打穿。所以用函数计算一定要在控制台配置并发上限和费用告警这道工序必须做不是可选项。4. 业务画像决定选型稳定流量用ECS脉冲流量用Serverless技术选型没有银弹。我通常建议团队根据业务自身的流量特征来选而不是根据“哪个更流行”来选。4.1 什么样的业务适合坚持用ECS以下几种业务形态现阶段用ECS或容器服务依然更合理第一有状态服务。函数计算的实例是无状态的每次执行可能落在不同的实例上你不能假设文件系统里上一次写入的东西下次还在。如果业务强依赖本地会话、Stateful的分布式锁、长连接的WebSocket那函数计算会让你非常难受。第二固定长驻的微服务。比如公司内部的核心订单系统白天晚上都有持续流量需要常驻进程处理消息队列适合用ECS跑Spring Boot或Go服务。这种场景用函数计算反而要处理冷启动、超时、实例冻结等一系列问题徒增复杂度。第三重度依赖GPU或特殊硬件资源的机器学习训练、视频转码任务。函数计算的常规实例不提供GPU虽然部分云厂商有GPU实例规格但通用性远不如ECS灵活。4.2 什么样的业务适合优先考虑函数计算反过来这几类场景我强烈建议用函数计算第一事件驱动型业务。对象存储里一有新文件上传就要触发转码、缩略图生成、内容审核数据库有新的binlog变更就要触发缓存更新。这类“某个事件发生→自动执行一段逻辑”的模型简直是为函数计算量身定做的。第二低频定时任务。报表生成、数据备份、日志清理、健康巡检、发送订阅邮件。定时触发器和低频调用天然匹配按量付费模型。第三弹性需求明显的API服务。比如活动页后端、抢购秒杀接口、行情推送网关流量瞬间暴涨几十倍用ECS需要提前囤机器用函数计算只需要平台自动扩容。第四开发原型和内部工具。我自己经常用函数计算写一些内部SQL查询接口、给运维写自动化的脚本服务不需要买服务器也不用维护环境写完传上去就能用。4.3 不少团队实际采用的是混合架构“取长补短”在真实项目里是最常见的形态。我参与过的一个项目就是这种架构基础业务仍然跑在一组ECS上保持稳定可控但把用户上传头像的图片处理、消息推送、Excel导出这类低频或峰谷明显的功能拆出来用函数计算承接。结果机器数量降了一半因为最占资源的突发任务已经不在ECS上跑了同时接口响应速度没有明显变化。混合架构最大的好处是可以低风险地体验Serverless不至于一开始就把核心业务押上去。5. 从ECS迁到函数计算一条可以复制的实操路径如果你已经有了ECS上的业务想试试函数计算我建议不要直接“大搬家”而是走一条渐进迁移的路。下面这个路径我在真实项目里验证过风险可控收益可见。5.1 第一步把应用拆出“可函数化”的模块先看应用里的功能哪些符合前面说的函数计算特征事件驱动、低频、无状态、短执行时间。经典候选包括图片和视频处理短信和邮件通知数据清洗和格式转换第三方API回调处理定时任务轻量级Web API把这类模块从主应用里拆出来保留主应用核心流程不动先把边缘功能迁过去。这一步的核心原则是最先迁的一定是不出问题也没关系的模块不然出了问题排查面太大容易打击团队的信心。5.2 第二步代码改造和部署发布这里用Python写一个最简单的函数作为示意展示从“本地函数”到“平台函数”的改造# 这是你的原始业务函数 def process_order(order_id: str): # 做一些业务处理 print(fprocess order {order_id}) return {status: ok, order_id: order_id} # 在函数计算平台上需要被包装成平台认可的入口 import json def handler(event, context): # event 是触发事件不同触发器格式不同 evt json.loads(event) order_id evt.get(order_id, unknown) # 复用原来的业务逻辑 result process_order(order_id) return { statusCode: 200, body: json.dumps(result), }改造的关键是入口函数必须遵循平台的规范。不同云厂商规则略有不同但基本模式一致平台调用你的入口函数传入事件和上下文你返回结果。部署发布有两种常见方式控制台直接创建函数上传代码包配置触发器。用Serverless Devs这类工具通过YAML描述项目配置命令式部署。第二种方式更适合正经项目因为配置可版本化、可回滚。我简单给一个s.yaml的示例edition: 1.0.0 name: order-process services: order-process: component: fc props: region: cn-hangzhou service: name: order-service description: order process service function: name: process-order runtime: python3.9 handler: index.handler memorySize: 1024 timeout: 60 triggers: - type: http name: httpTrigger props: methods: - GET - POST这里面的runtime参数可以直接写python3.9跑起来就是标准Python 3.9环境不需要你自己安装这也回应了前面提到的ECS上装Python的对比。配置中memorySize和timeout要根据业务逻辑的实际情况去调整不是越大越好1GB内存配60秒超时是很多轻量函数的起点配置。5.3 第三步双跑验证用流量比对消除心理障碍代码部署之后不要立刻从ECS下线旧功能。建议设置一个“双跑期”新函数和旧ECS服务同时在线用流量灰度的方式逐步切流量。具体做法前一周只切5%的流量到函数计算。观察日志、错误率、耗时同时和旧服务对比。确认稳定后再逐步提升到50%、100%。那次迁移让我印象最深的是函数计算后端日志里面可以看到每次调用的冷启动时间和实际执行时间排查问题比ECS上看系统日志还方便。双跑期通常在两周内完成之后ECS上的旧模块就可以放心下线了。6. 冷启动、并发与超时函数计算三块容易被低估的短板很多团队迁到函数计算后又想迁回去多半不是因为有状态问题而是被三个平台特性坑怕了冷启动、并发限制、函数超时。6.1 冷启动寒夜里第一声电话总要多等一秒函数计算的实例在第一次被调用时需要经历环境初始化、加载代码包、建立运行时这部分时间就是冷启动时间。相比热调用几毫秒到几十毫秒的延迟冷启动一般要额外增加几百毫秒甚至几秒。对用户交互类接口冷启动造成的首包延迟是感知明显的。你点开一个接口转圈转了3秒哪怕后面所有请求都很快体验也已经坏了。缓解手段有几个方向配置“预留实例”也叫预置并发平台提前把实例拉起待命让请求直接打到热实例上。代价是预留实例空闲时也会产生费用相当于你又买了几台“一直开机的小ECS”。选一个更轻的运行时比如Node.js或Python比Java冷启动快得多。把函数的代码体积做小依赖打包精简减少加载时间。我自己的经验是对用户交互敏感的接口预留并发一定得配对后台异步任务冷启动根本不是问题等半秒完全无所谓。6.2 并发上限不是“无限”的虽然函数计算号称弹性扩缩容但每个服务、每个函数都有限制并发上限的配置。你不主动调高时默认的并发额度其实不大流量一旦超过这个值超出的请求不是排队而是直接报错。有一次我给一个活动页配置函数计算后端忘记调并发限制的规格活动上线当天请求量一冲高函数直接返回“429 Too Many Requests”页面秒崩。后来才想起是并发上限设低了。所以在函数计算上线压测时一定要确认两项配置单函数并发上限根据预估QPS乘以平均耗时来推算账号级并发总额度所有函数共享占用不能超建议公式单函数所需并发数 ≈ 预估QPS × 平均响应时间秒。比如预估QPS为500平均响应时间0.2秒那并发上限至少要设100再留2倍以上余量比较稳妥。6.3 超时限制决定了你能写的代码规模函数计算平台对单次执行时长有上限约束常规配置范围是1秒到几百秒不等。这意味着一个需要跑20分钟的视频转码任务在普通函数里是跑不完的你得用配套的异步调用、任务模式或者分批处理。这个限制倒推过来的设计原则是**一个函数只做一件小而快的事如果逻辑本身耗时很长就得拆成多个步骤或引入工作流服务。**从ECS迁过来的时候习惯把几件事写在一个进程里的思路必须改否则会不断踩超时告警。顺带提一嘴函数计算的配套日志服务和监控指标很完善建议把每个函数的错误率、时长、冷启动时间都配成告警。这些指标在ECS上要自己搭监控在函数计算上是开箱即用的也算是短板旁边的补强。从我个人的实际体会来看ECS和函数计算不是互相替代的关系更像是“资源型计算”和“事件型计算”的两种正交思维。你不需要急着把服务器全部扔掉也不该拒绝尝试函数计算。最稳妥的做法是把那些低频、事件驱动、无状态的脏活累活扔给函数计算把关键核心、有状态、长驻的业务留在ECS上让两边各自发挥优势。最后再分享一个建议如果拿不准业务适配哪种形态最快的方式是挑一个风险最低的模块花一天时间部署个函数试试配好费用告警放真实流量观察一周账单出来后你会对自己的业务有一个特别清晰的认识。