朋友问我：你当初怎么选的技术栈？我说，是从一次深夜排障开始的。
当时我的屏幕上，CodePipeline的部署状态条卡在第四阶段已经37分钟了。六个微服务，滚动更新，一个任务定义里的内存参数配小了200MB，整个管道停住，没给出任何有效回滚指令。我需要手动登录控制台，找到那个卡住的服务，把任务定义改回来，再重新走一遍部署流程。
那次之后我开始认真问自己一个问题：这套组合，真的能撑住10个以上微服务的日常迭代吗？
CodePipeline配合ECS，跑单个服务或演示项目的体验很顺滑。一旦服务数量跨过两位数，团队里有三拨人在同时改不同的代码库，这套工具链的裂缝就会逐条浮现。我自己踩了一遍坑之后发现，问题集中在五个维度上，而且每个维度到了生产级规模都会变成实实在在的阻塞点。
第一个维度是部署策略的弹性。CodePipeline通过CodeDeploy提供的滚动更新和基础的蓝绿部署，在大部分场景下能用，但前提是你的部署策略不需要太多变体。一旦碰到“先把5%流量切到新版观察Prometheus错误率指标，稳定15分钟后再增加到25%，同时设定三个关键指标触发自动回滚”这种需求，你就得自己写大量胶水代码。ECS这边，胶水代码要么挂在Lambda上，要么塞进Step Functions里拼出一个半自动流程，排查问题时往往要在四个服务之间跳转。EKS生态里，Argo Rollouts或Flagger这类工具把金丝雀发布、流量权重控制、基于指标的自动回滚做成了声明式配置，部署策略的可读性和可维护性明显高一个台阶。当你的服务数量还在增长，部署策略的复杂度只会继续爬升，这条差距会越来越刺眼。
第二个维度是编排的精细度。ECS的任务定义跟Kubernetes的原语比起来，控制粒度偏粗。你需要sidecar容器的时候，ECS可以手动在任务定义里加一个容器定义，但两者的生命周期管理并不严格同步；你需要init容器来跑数据库迁移或配置初始化，ECS没有这个原语，只能在工作容器的入口脚本里自己处理顺序；你需要为每个容器精确设定资源请求和上限、配置Pod中断预算、通过拓扑分布约束来控制Pod在可用区之间的分布，这些在EKS中是标准配置项，在ECS里要么不存在，要么只能用外部脚本模拟。一个跑着十几个服务的集群，资源争抢和调度不合理会直接转化成延迟抖动，而精细控制能力的缺失意味着你能用来定位和解决这些问题的杠杆非常有限。
第三个维度是服务间流量的治理。当架构演进到需要服务间启用mTLS、配置重试策略和熔断规则、针对几十个微服务做精细的流量拆分时，ECS的主流方案是上App Mesh。但App Mesh在AWS内部的更新节奏和功能完善度，与社区主力的服务网格方案相比差距明显。反观EKS，与Istio、Linkerd或Cilium的集成路径清晰，这些项目的开发活跃度和生产案例积累让它们在服务网格这个领域变成了事实标准。一旦你的流量治理需求越过某个复杂度阈值，App Mesh的局限性会迫使你重新评估整个网络层的方案，而这个迁移成本远远高于一开始就选对底座。
第四个维度是GitOps的成熟度。CodePipeline的模型是推送式部署，代码提交触发管道，管道把构建产物推到ECS。这个过程天然是AWS原生的，也天然只在AWS内部运转。EKS则通过ArgoCD或Flux打开了GitOps的工作流：集群状态始终以Git仓库中的声明文件为准，任何偏离都会被自动检测并修正，每一次变更都有完整的审计记录。在多服务、多团队的组织里，这种模式带来的运维收益是结构性的——你不再需要为“谁在什么时候改了什么配置”这类问题翻找操作日志，因为Git本身就是唯一的真相源。
第五个维度是便携性和供应商锁定。一个ECS的任务定义离开AWS就没有意义了。一个Kubernetes的manifest文件可以原封不动地在EKS、GKE、AKS或者本地数据中心运行。对于那些正在考虑多云策略或混合云架构的团队来说，这种可移植性不是锦上添花，而是一份对冲风险的保单。你可能现在不需要，但这个选项的存在本身就在影响技术选型的长期评估逻辑。
此外还有生态链的厚度。CNCF围绕Kubernetes构建的配套工具——Prometheus做指标收集、Grafana做可视化、OpenTelemetry做链路追踪、Karpenter做节点自动伸缩、KEDA做事件驱动扩缩容——这套组合在大规模场景下的验证案例远比ECS生态丰富。不是说ECS不能搭配这些工具使用，而是集成路径的摩擦系数更高，踩坑时能找到的社区解决方案更少。
把以上这些维度叠在一起，你会发现最终的分野线不只是功能列表的长短，而是一个底层逻辑的差异：ECS的设计起点是帮你把容器跑起来，它的理想用户是一个小团队、一个清晰的应用边界、一套相对静态的部署逻辑；Kubernetes的设计起点是帮你管理一个不断演进的分布式系统，它的核心假设就是多团队、多服务、多环境、持续变化。当你还处在第一个阶段时，ECS确实更友好，运维心智负担更低，不需要为集群管理本身投入额外的人力和认知成本。但一旦业务规模推动你跨过那条线，EKS提供的灵活性、声明式工作流和CNCF生态就会从“可以有”变成“必须有”。
我写这些不是要论证ECS不好。它在简化运维这条路上的成就不应该被轻视——对于小团队或架构相对简单的系统来说，选ECS是完全合理的决策，它能帮你省下大量照顾Kubernetes控制面的精力。我只是想把那条临界线的位置标出来：当你开始同时维护10个以上的服务，当多个团队需要独立发布节奏，当你对部署策略和流量控制的要求细化到了指标级别，那一刻，你在ECS上打的所有补丁和胶水代码会突然从“能用”变成“技术债”，而这篇技术债的利息会逐月递增。
我很好奇其他在生产环境跑微服务的团队是怎么走这条路的。你们是从ECS平滑过渡到了EKS，还是在某个规模点上发现ECS其实完全够用，不需要跳进Kubernetes的复杂性里？
热门跟贴