Spring Cloud Alibaba 还是 K8s？一份“说人话、重实战”的选型与落地指南

K8s作为微服务基座的实战指南

原创已于 2025-09-24 09:34:59 修改 · 1.1k 阅读

20 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #容器 #云原生

于 2025-09-21 08:56:01 首次发布

场景背景：不少团队对 Spring Cloud Alibaba（SCA） 的未来稳定性持谨慎态度；同时，国内大厂与中大型公司基础设施基本已全面 Kubernetes（K8s）化。我们要不要把 K8s 当基座，让微服务更“云原生”？这篇就把话说透：为什么换、怎么换、换了以后怎么稳住。

一、结论先行：把 K8s 当基座是当前更稳的主路线

生态和更新节奏：K8s 由 CNCF 牵头，长期稳定演进，更新与周边生态极其活跃。
功能覆盖度：K8s 自带或生态替代了大量“中台组件”的通用能力（服务发现、配置、负载、网关、弹性、灰度/滚动发布、任务调度、RBAC 等）。
供应商绑定更弱：上标准 K8s 就能跑，跨云迁移成本相对可控。
开发/运维一体化：Dev/QA/Prod 一套基座，规范化部署、回滚、观测更顺。

你可以理解为：K8s 提供“操作系统级”微服务土壤，很多原本要在应用里做的工作，下沉到平台层更可靠、更可标准化。

二、能力对照：SCA 组件与 K8s/生态的“对位替换”

领域	过去（SCA/常见）	现在（K8s/云原生生态）	备注要点
服务发现	Nacos / Eureka	Service + kube-dns + Readiness/Liveness Probe	K8s 用 Service + DNS 做寻址；探针做存活/就绪判定。
配置中心	Nacos Config / Apollo	ConfigMap / Secret（+ External Secrets）	配置热更新用 Sidecar/重载；敏感信息放 Secret。
负载均衡	Ribbon/客户端LB	Service（ClusterIP/NodePort/LoadBalancer）	服务端统一 LB，配合 Ingress/Service Mesh。
网关	Spring Cloud Gateway	Ingress Controller（nginx/traefik）或 API Gateway（Kong/Envoy/Apinto）	复杂网关策略可上独立网关或 Mesh Gateway。
熔断限流	Sentinel	Service Mesh（Istio/Linkerd）的熔断、超时、重试、故障注入；或继续用 Sentinel	Mesh 做到无侵入；应用内拦截可继续 Sentinel。
弹性伸缩	应用自管	HPA（CPU/内存/自定义指标）、VPA、Cluster Autoscaler	配合 Prometheus + Adapter 实现基于业务指标伸缩。
发布策略	人工/脚本	滚动发布/蓝绿/金丝雀（Deployment + Ingress 权重 / Mesh 流量规则）	K8s 原生滚动 + Mesh/Ingress 做细粒度流量。
任务调度	xxl-job 等	Job/CronJob	分布式并发、重试、幂等要在任务内实现。
鉴权与权限	Spring Security / OAuth2	K8s RBAC（集群层）+ 应用层认证授权	集群访问与应用鉴权分层治理。
日志/指标/链路	各组件自带	EFK/ELK、Prometheus+Grafana、OpenTelemetry	平台统一采集，应用打点轻量化。
分布式事务	Seata	Seata on K8s	作为独立服务部署；并非 K8s 原生能力。
厂商绑定	较强（云上托管版）	相对较弱（标准 K8s）	谨慎依赖云厂商“特殊 API”。

要点：不是非此即彼。SCA 里某些“好用”的库完全可以继续用（如 Sentinel、Seata），只是运行与治理交给 K8s/Mesh，更标准、更通用。

三、为什么很多团队开始“担心”只押 SCA

维护节奏的不确定性：历史上你也见过一些组件“停更/活跃度下降”的波动。
对云厂商的路径依赖：用了云上定制服务，迁移难度显著增大。
平台能力重复造轮子：SCA 提供的部分能力，K8s 已经“系统级”提供，重复建设、成本更高。

不是 SCA 不好，而是当平台层已经具备稳定能力时，把通用能力“下沉到平台”是业界趋势。

四、落地指导：从 SCA 迁到 K8s 的最小闭环

目标：不求一步到位，先把“能跑稳、能观测、能灰度、能回滚”做起来。

1）容器化与部署基线

Docker 化服务，做 不变构建（Immutable Build）。
用 Deployment + Service 起应用；配置通过 ConfigMap/Secret 注入。
制定 镜像规范（基础镜像、健康探针、优雅停机、日志到 stdout）。

示例（精简）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 3
  selector: { matchLabels: { app: user-service } }
  template:
    metadata: { labels: { app: user-service } }
    spec:
      containers:
        - name: app
          image: registry.local/user-service:1.0.0
          ports: [{ containerPort: 8080 }]
          envFrom:
            - configMapRef: { name: user-service-config }
            - secretRef:    { name: user-service-secret }
          readinessProbe:
            httpGet: { path: /actuator/health/readiness, port: 8080 }
          livenessProbe:
            httpGet: { path: /actuator/health/liveness,  port: 8080 }
---
apiVersion: v1
kind: Service
metadata: { name: user-service }
spec:
  selector: { app: user-service }
  ports:
    - name: http
      port: 80
      targetPort: 8080

2）网关/入口

轻量场景：Ingress + NGINX Ingress Controller。
复杂策略（鉴权、QPS、限速、API 版本）可上 Kong/Apinto/Envoy。

3）弹性与发布

HPA：先按 CPU/内存，后接入 自定义业务指标（如请求数/延迟/P99）。
发布策略：默认 RollingUpdate，小流量验证用 金丝雀（Ingress/Mesh 权重）。

4）观测（先统一，再细化）

日志：Fluent Bit/Vector → Elasticsearch/OpenSearch 或 Loki。
指标：Prometheus + Grafana；服务暴露 /actuator/prometheus。
链路：OpenTelemetry（SDK 或 Agent）→ Tempo/Jaeger。

5）服务间治理（可选但建议）

上 Istio/Linkerd：超时/重试/熔断、灰度/故障注入、mTLS 加密、无侵入观测。
如果短期不上 Mesh，可继续 Sentinel 做应用内限流降级。

6）Dev/QA/Prod 一致与效率工具

本地开发不必“每次打镜像”再调试：
- kt-connect / Telepresence / Bridge to Kubernetes：把本地服务“接入”集群流量。
- Skaffold/Tilt：自动构建-推送-部署，加快内循环。
配置隔离：命名空间 + 环境变量前缀；禁止在代码里写死环境差异。

7）CI/CD 与回滚

镜像构建签名、漏洞扫描（Trivy/Grype）。
部署用 Helm/Kustomize；环境参数外置。
GitOps（Argo CD/Flux）做一键回滚与审计。

五、成本与挑战：别踩的坑、该付的学费

学习曲线：K8s/Mesh/可观测性一次性引入较多概念。建议循序渐进：先 K8s，再 Ingress，再 HPA，再 Mesh。
资源开销：K8s 本身 + 观测/网关/存储栈会吃资源，小团队需要核算节点与费用。
组织与权限：需要平台、后端、运维协同；RBAC、命名空间、镜像仓库与网络策略都要规范。
小团队/小项目不建议“上全套”：单体 + 最简容器编排足矣，别为技术而技术。

六、迁移路线图（四步走）

盘点：列所有服务与组件依赖（注册中心、配置、网关、限流、任务、事务、缓存、消息）。
对照替换：先把“最通用、平台可替代”的放到 K8s（Service/ConfigMap/Ingress/HPA/Job）；暂留 SCA 中的“应用内特性”。
平台补强：引接 Prometheus/Grafana + 日志栈 + OTel，把告警重点放在 可用性与 P99。
服务治理升级：评估是否引入 Service Mesh；引入后逐步把熔断/重试/灰度等“横切逻辑”下沉到平台策略。

七、典型问答（实战视角）

Q：没有 Nacos，还怎么做动态配置？
A：用 ConfigMap/Secret + Reload 机制（Sidecar/Actuator Refresh）。敏感信息放 Secret，外部密钥用 External Secrets 管理器对接云 KMS/Secrets Manager。
Q：分布式事务怎么办？
A：K8s 没有原生分布式事务，直接把 Seata 以 StatefulSet/Deployment 的方式上集群即可；同时梳理业务边界，优先用 最终一致 + 事务消息 降维处理。
Q：限流熔断用谁？
A：短期继续 Sentinel；中长期上 Istio，把超时/重试/熔断、mTLS、灰度全部“策略化、无侵入”。
Q：如何避免“环境不一致”导致上线翻车？
A：一套基座（K8s），差异仅在命名空间与配置；用 GitOps 管理清单，发布前在 预生产 用同清单做一次“演练”。

八、给不同体量团队的建议

小团队/小项目：容器化 + 单集群 + Ingress 即可；监控先落好，别急 Mesh。
成长型团队：上 HPA、灰度发布、统一日志/指标/链路；关键链路评估 Mesh。
中大型团队：全面云原生：GitOps、Mesh、细粒度安全（NetworkPolicy/mTLS）、多环境多集群与多活。

九、Checklist（拿去即用）

所有服务容器化，镜像规范与健康探针落地
ConfigMap/Secret 管理配置与敏感信息
统一入口（Ingress/网关）与 HTTPS
HPA 基于 CPU/内存先跑起来，再接业务指标
滚动发布 + 金丝雀策略与一键回滚
日志/指标/链路三件套就位，告警以 可用性、错误率、P99 为核心
CI 镜像扫描、签名；CD 用 Helm/Kustomize，最好 GitOps
灰度、熔断、超时、重试策略可平台化（Service Mesh）
制定云厂商能力“最小依赖清单”，避免被锁死
文档与手册同步更新，统一培训与演练

结语

K8s 不是银弹，但它是更稳的“地基”。把通用能力交给平台、把业务逻辑留在应用，是当下性价比最高的工程路线。SCA 里“好用的库”别急着丢，能迁就迁、不能迁就放“应用层”，平台与应用各司其职。按本文的对照表与路线图一步步推进，你的微服务会更可控、更易维护，也更经得起“降本增效”的长线考验。