微服务总览

微服务不是「多起几个进程」，而是一种组织与架构方式：用一组围绕业务能力、可独立部署的小服务，替代一个大而全的单体。它的收益与代价都很真实，上之前要算清账。

1. 微服务到底是什么

一个被广泛接受的描述来自 Martin Fowler：微服务是一种把单个应用拆分为一组小服务的架构风格，每个服务：

• 运行在独立进程中；
• 围绕业务能力组织（而不是技术分层）；
• 通过轻量级机制（HTTP/RPC/消息）通信；
• 可以独立部署、独立扩展；
• 围绕服务边界拥有自己的数据。

关键词是「独立」：独立开发、独立部署、独立扩缩容、独立演化。做不到这几点，多数只是「分布式单体」。

2. 收益与代价

维度	收益	代价
团队协作	小团队独立迭代，发布互不阻塞	团队沟通与协调成本上升
技术选型	各服务可用最合适的技术栈	技术栈分散，运维与招聘复杂
伸缩	热点服务单独扩容	资源利用率下降，调度变复杂
隔离	故障限定在单个服务	调用链变长，故障定位更难
演化	局部重构影响面小	跨服务改动需协同发布
事务	——	失去单库事务，需要分布式事务
运维	——	需要注册发现、网关、链路追踪等一整套基础设施

微服务不是免费的

单体应用的很多「痛」在微服务里换了个地方出现：单体里是一个大事务、一次全量发布；微服务里变成跨服务一致性和分布式调试。别把复杂度消灭，它只是转移了。

3. 什么时候该上

微服务解决的核心矛盾是「协作规模」，不是「性能」。判断依据：

该考虑微服务：

• 团队规模变大（普遍经验是单服务维护团队接近两位数的量级），改代码经常冲突；
• 不同模块发布频率差异极大，被互相拖累；
• 存在独立扩展需求（某个模块流量是其他的几十倍）；
• 业务边界清晰，且已有较成熟的自动化运维/CI-CD/监控能力。

先别上微服务：

• 团队小、业务仍在快速试错——模块化单体（Modular Monolith）通常更快；
• 边界还没想清楚——先拆错，后面合并更痛苦；
• 没有配套基础设施——贸然微服务会变成「分布式单体 + 一堆运维噩梦」。

正确的心智模型：微服务是组织能力成熟后的自然结果，而不是项目启动时的默认选项。

4. 专题导航

• 服务拆分：按业务能力、限界上下文、康威定律切边界，以及拆分步骤与反模式。
• 服务治理：注册发现、配置中心、网关、负载均衡、超时重试、灰度发布。
• 可观测性：日志、指标、链路三大支柱与落地工具。
• 相关理论见 CAP 与 BASE：跨服务一致性为什么难。
• 跨服务数据一致性手段见 分布式事务。

5. 一个微服务的标准能力清单

一个「成熟」的微服务，除了业务逻辑，通常还要具备：

能力	说明
服务注册与发现	实例上下线能被自动感知
配置管理	配置与代码分离，可动态刷新
健康检查	提供存活/就绪探针，供编排系统摘除故障实例
日志与指标	结构化日志 + 指标暴露（如 Prometheus 端点）
链路追踪	透传 traceId，串联跨服务调用
限流与熔断	过载与依赖故障时的自我保护
幂等与超时	每个对外接口都具备

6. 小结

• 微服务的本质是围绕业务能力的独立可部署服务，核心价值在「独立」。
• 它用运维复杂度换协作与演化能力，不是免费的。
• 上的前提是：边界清晰、团队规模够大、自动化与可观测基础设施到位。
• 不确定时，模块化单体是更稳妥的起点。