云原生架构入门：微服务、容器与 CI/CD 怎么落地

云原生的实质是把交付与运维变成可自动化的工程流程：容器提供一致的运行单元，编排系统提供声明式调度与自愈，CI/CD 提供可重复的构建与发布，可观测性提供故障定位手段。结论很直接——先解决交付效率，再谈微服务拆分；顺序反了，团队会先被分布式复杂性压垮。

四要素：容器、编排、服务治理、声明式

• 容器化：把应用与其依赖打成不可变镜像，消除"环境不一致"这类问题。镜像即构建产物，可被扫描、签名、审计。
• 编排：Kubernetes 负责调度、副本管理、自愈、滚动更新与资源配额。它把"运维动作"变成"对象声明"。
• 服务治理：服务发现、负载均衡、熔断限流、链路追踪。规模小时靠 Kubernetes Service 与客户端重试就够，规模大、语言栈杂时才引入服务网格。
• 声明式与自动化：所有环境用同一份描述文件定义，配合 GitOps 让集群状态可追溯、可回滚。

判断一个团队是否真的云原生，不看用了多少工具，而看一条标准：从代码合并到生产可用，是否需要人工介入、是否可重复、是否可回滚。

什么时候不该上微服务

微服务换来的是独立部署与独立扩缩，付出的是分布式事务、跨服务调用延迟、链路追踪、数据一致性、联调成本与运维复杂度。以下情况不适合拆：

• 团队规模小（少于 10 名后端），拆完每人维护多个服务，认知负担反而上升。
• 业务边界还不稳定，需求每周在变，此时拆出的服务边界大概率是错的，后期合并成本极高。
• 没有自动化测试与 CI/CD，拆成十个服务意味着十次手工发布。
• 没有集中日志、指标、链路追踪，出问题只能靠猜。

更稳的路径是模块化单体：一个进程部署，代码内部按业务域分模块、禁止跨模块直接访问数据库、模块间只通过明确接口调用。等某个模块的扩缩需求、团队归属或发布节奏明显独立时，再把它拆出去——此时拆分是收割，而不是赌博。

拆分粒度与边界

按业务能力（Bounded Context）拆，不按技术层拆。"用户服务、订单服务、库存服务、支付服务"是可用的边界；"Controller 服务、Service 服务、DAO 服务"是灾难。几个可操作的判断标准：

CI/CD 流水线该有哪些阶段

一条合格的流水线，目标是把"人为判断"压缩到只有生产放行那一次。典型阶段如下：

关键纪律是同一镜像贯穿所有环境：预发测的镜像必须就是生产要发的镜像，靠环境变量与配置中心区分环境，而不是重新构建一次。否则"预发通过了生产挂了"这类问题永远查不清。

可观测性三支柱

监控回答"有没有问题"，可观测性回答"为什么有问题"。三者互补，缺一不可：

• 指标（Metrics）：时序数据，成本低、聚合好，适合告警。核心看四类——延迟、流量、错误率、饱和度（RED/USE 方法）。
• 日志（Logs）：带上下文的事件明细，用于定位具体异常。关键是结构化（JSON）并带上 trace_id，否则跨服务排查等于大海捞针。
• 链路追踪（Traces）：记录一次请求经过的所有服务与耗时分布，是分布式系统定位慢调用与依赖瓶颈的主力。

落地顺序建议：先把指标与告警做扎实（可用性、错误率、P95 延迟、资源水位），再统一日志格式并接入集中检索，最后才上链路追踪。反过来做往往半途而废——没有指标基线，链路追踪看到的那条慢链路也不知道是否异常。

渐进式落地路线

第一阶段（1–2 个月）：容器化与流水线。目标是把部署变成一条命令。单体现有架构不动，只做三件事：写 Dockerfile 多阶段构建、所有环境配置外置、搭 CI 跑单测与自动构建镜像。验收标准是新成员能在一小时内把服务跑起来，发布不需要登录服务器。

第二阶段（2–4 个月）：编排与可观测性。把服务迁到 Kubernetes（托管集群优先），补齐就绪/存活探针与资源 requests/limits，接入集中日志与指标告警，制定滚动更新与回滚流程。这一阶段最容易出的问题是资源请求不设、探针不配，导致节点被挤爆或流量打空，参考 Kubernetes 核心概念 把对象关系理清。

第三阶段（按需）：拆分与治理。只拆有明确收益的模块，先拆读多写少、边界清晰、可独立扩缩的服务；同时补齐接口契约测试、幂等设计、分布式追踪，再考虑是否引入服务网格。成本上，容器与弹性伸缩如果没有配套的成本治理，账单会随副本数悄悄上涨，可参考 云计算成本优化。

常见问题

延伸阅读

• Kubernetes 核心概念：Pod、Deployment、Service 的关系
• Docker 入门：镜像、容器、数据卷与网络一次讲清
• 云计算成本优化（FinOps）实战：把月度账单砍掉 30%
• 日志体系怎么建：从 rsyslog 到 ELK 与 Loki 的选型：微服务把日志打散到多个容器，集中采集是前提。