知识卡片
微服务宁愿冗余也不要耦合
内容
微服务架构刻意放弃了”发现两个服务都有Customer概念就把它们合并复用”的传统冲动，转而让每个服务各自维护自己对同一实体的内部表示，需要协作时靠传递消息完成，代价是数据有点冗余。这是因为复用等于耦合：越是追求代码通用、可复用，就得塞入越多参数和分支去适配不同场景，代码本身的可用性反而下降；而微服务看重解耦带来的独立演进能力，局部的冗余成本远低于耦合对整体架构造成的伤害。
参考来源
- 位置：《演进式架构（原书第2版）》第5章《演进式架构拓扑》「宁愿冗余也不要耦合」相关小节（源文件：_epub-src/EPUB/xhtml/chapter09_0001.xhtml）
- 结论依据：原文用CatalogCheckout和ShipToCustomer共享Item概念反而增加变更耦合成本的例子，明确微服务采用零共享、宁愿冗余也不要耦合的设计哲学，直接支持卡片论点。
- 原始内容："微服务采用了零共享的架构，其目标是尽量减少耦合。通常情况下，冗余比耦合更可取……微服务避免代码复用，采用了'宁愿冗余也不要耦合'的设计哲学：复用意味着耦合，而微服务架构是极度解耦的。"