arch-microservices

一句话概述

将系统拆分为可独立部署的服务，每个服务拥有自己的数据，并与一项业务能力相对应。通过网络进行通信。付出运维成本，以换取自主性和独立扩展能力。

何时使用此技能

• 多个团队在同一代码库／部署中互相掣肘。
• 系统的不同部分需要不同的独立扩展特性（一部分受 CPU 限制，另一部分受 I/O 限制，还有一部分流量突发）。
• 系统的不同部分有不同的发布节奏，一个团队的部署不能阻碍另一个团队。
• 系统的不同部分有不同的可靠性要求（关键的支付链路；非关键的分析仪表板）。

何时不应使用此技能

• 只有一个团队、一个产品，也没有扩展压力——你没有微服务要解决的问题。保持单体架构。
• 对领域的理解还不足以划定服务边界——过早拆分的回退成本非常高。
• 运维成熟度不足（没有 CI/CD、可观测性或值班机制）——微服务会加剧运维痛苦。
• 为简历而开发。请停下来。

核心内容

服务边界应遵循业务能力，而非技术层。 customer-service、orders-service、pricing-service 是合理的划分。database-service、api-service、cache-service 则是反模式。服务边界通常与 DDD 限界上下文相对应（参见 ddd-bounded-context）。

每个服务都拥有自己的数据。 不要共享数据库。如果服务 B 需要服务 A 的数据，B 可以调用 A 的 API，也可以由 A 发布事件供 B 订阅。两个“微服务”底层共享数据库，会使它们变成分布式单体——两者之中最糟糕的情况。

通信模式。

• 同步（REST、gRPC）。 直接、易于理解，但延迟相互耦合。适用于调用方需要立即获得答复的查询密集型模式。
• 异步（事件，参见 arch-event-driven）。 时间上解耦，最终一致。适用于跨多个服务的工作流。

大多数生产系统会混用这两种模式。

边缘模式。

• API 网关——外部客户端的统一入口；负责处理身份验证、速率限制、路由和响应组合。使客户端与内部服务拓扑解耦。
• 前端专用后端（BFF）——针对不同客户端类型（移动端、网页端、合作伙伴 API）定制的网关。避免陷入“一个网关必须满足所有客户端需求”的困境。
• 服务网格（Istio、Linkerd）——由边车代理处理流量、mTLS、重试和可观测性。将横切基础设施从服务中移出。适用于大规模场景；服务数少于约 10 个时则显得过度设计。

反模式警示：分布式单体。 服务虽然能够独立部署，却紧密耦合（共享数据库、同步调用链、同步发布）。它承担了微服务的全部运维成本，却没有获得任何自主性方面的收益。这是最难摆脱的架构。

决策启发

• 默认选择单体架构。 微服务用于解决特定问题（团队自主性、独立扩展、故障隔离）。如果你没有这些问题，就不需要采用这种架构风格。
• 服务边界应与限界上下文相对应。先使用 ddd-bounded-context；让上下文决定如何拆分，而不是反过来。
• 不拥有自身数据的服务值得警惕——它通常是一个适配器或协调器，应该放在别处。
• 单个用户请求经过超过 2-3 个服务的同步调用链，说明拆分方式有问题。应考虑使用事件或重新思考边界。
• 当客户端类型差异显著时使用 BFF；差异不大时使用支持内容协商的网关。

反模式

• 分布式单体。 必须一起发布的服务。两头都不讨好。
• 纳米服务。 服务小到按类发布。协调成本超过任何拆分带来的收益。
• 共享数据库。 两个服务读写相同的表——它们并非独立服务。
• 同步调用链。 一次用户请求中，服务 A 调用 B，B 调用 C，C 再调用 D。每一环都会增加延迟并扩大故障面；任何一环出问题，整条链都会失败。
• 因为 Netflix 这么做就选择微服务——Netflix 解决的是 Netflix 的问题；你的问题并不相同。

另请参阅

• ddd-bounded-context — 服务边界应遵循限界上下文。
• arch-event-driven — 标准的异步通信方式。
• arch-saga — 协调分布式事务。
• arch-circuit-breaker — 隔离服务之间的故障。
• arch-strangler-fig — 从单体迁移到微服务。

参考资料

• Richards & Ford，Fundamentals of Software Architecture，第 17 章（微服务）。
• Sam Newman，Building Microservices（O'Reilly）。
• Sam Newman，Monolith to Microservices（O'Reilly）。
• Khononov，Learning DDD，第 14 章（微服务）。