微服务架构
微服务按业务能力划分独立部署单元。本文讨论拆分收益、边界和运行成本。
1. 面试核心
先记住这几条，再读正文- 服务边界。 微服务按业务能力划分，服务拥有自己的写入规则。卡 · 综合题
- 独立部署。 独立部署依赖兼容契约、自动化测试和独立发布流程。
- 远程调用。 网络调用增加超时、重复请求和结果未知等失败状态。
- 拆分成本。 服务拆分增加跨服务一致性、观测和运维成本。
- 故障隔离。 同步依赖会传播故障，超时与资源隔离共同限制影响。卡 · 同步依赖与故障传播
2. 拆分目标
拆分应解决可测量的问题。例如，搜索需要单独扩容。订单需要提高发布频率。支付故障需要缩小影响范围。特定数据需要独立访问控制。
拆分前记录发布频率、变更耗时和资源用量。故障影响与团队等待时间也应纳入基线。拆分后的结果用同一口径比较。
3. 业务能力边界
技术分层会让一次请求跨越多个服务。按表拆分则容易切开同一业务规则。
服务边界需包含明确的业务职责、接口和写入权。代码、测试和发布由明确团队负责。限界上下文可以对应一个或多个部署单元。粒度取决于共同变化、负载和维护能力。
4. 独立部署
接口向后兼容时，服务可独立发布新版本。调用方按原契约继续运行。热点服务也可单独增加实例。
若每次需求都要同时发布五个服务，边界仍然耦合。此时要分析哪些契约或共享数据迫使联动。拆分收益来自实际独立性。
5. 网络调用的失败语义
远程调用超时后，服务端仍可完成操作。客户端得到的是未知结果。重试需要业务幂等，限时等待需要端到端预算。
服务还需要限流、熔断和有界队列。认证、证书、服务发现与链路追踪也进入运行成本。
5.1 同步依赖与故障传播
假设订单同步调用支付。支付变慢后，订单线程持续等待。线程池耗尽时，其他订单接口也会失败。独立进程并未隔离这条依赖。
调用方应限制等待时长和并发数。超时预算要留出自身处理与返回时间。重试会增加下游负载，应设置次数和退避。
支付确认属于关键条件，超时可返回处理中。推荐信息属于可选结果，可用默认内容降级。隔离测试应观察线程占用、延迟和业务结果。
6. 数据所有权与一致性
服务拥有自己的写入模型。迁移阶段可以共用数据库实例。各表的写入责任仍需明确。
跨服务查询可使用 API 聚合或读取投影。跨服务提交的选择见分布式一致性。
7. 服务数量的运维成本
每个服务都需要构建、配置、监控和安全更新。容量计划与故障响应也有固定成本。
服务增加后，契约版本和测试环境更复杂。低流量服务仍需保留运行副本。值班人员需要理解更大的依赖图。因此，自动交付和集中观测应跟上拆分规模。
8. 拆分粒度
拆分过细会出现长同步链和频繁联动发布。大量事务需要跨服务协调，也说明边界成本偏高。单表 CRUD 服务若没有独立变化价值，可考虑合并。
故障隔离与单独扩容需要实际验证。两个服务长期共同变化时，同一部署单元可降低成本。
9. 渐进式拆分
单体内部先明确模块接口与数据所有权。候选模块应有可测量的独立部署或扩容收益。选择一条可验证路径灰度迁移，具体流程见绞杀者模式。
10 · 面试题卡片
10.1 微服务应该怎样拆，拆得太细会有什么问题
出现公司：字节跳动、美团
题型：综合题
考察重点
- 拆分目标和业务边界。
- 独立部署、扩缩容与故障隔离的收益。
- 网络、数据、测试、运维和组织成本。
参考回答
微服务应按业务能力和数据所有权划分。
独立部署需要兼容接口与独立交付流程。独立扩容适合负载明显不同的能力。故障隔离还需超时、并发限制和降级。
拆得太细会增加同步调用、联动发布和协调成本。每个服务也会增加测试与值班负担。边界尚不清楚时，可先建立模块化单体。拆分后用发布频率、故障范围和资源成本验证收益。
10.2 服务已经独立部署，为什么下游故障仍会拖垮上游？
出现公司：暂无已核验的公开来源（本站自测）
考察重点：同步等待、并发资源与降级语义。
相关内容：同步依赖与故障传播。
参考回答
同步等待会占用上游线程和连接。
下游变慢后，资源耗尽会扩大故障。超时限制等待，并发上限限制资源占用。有界重试避免继续放大下游负载。关键支付结果应显示处理中，可选推荐可以降级。