个人水平有限，可能有错，欢迎大家在评论区指正和讨论。
这是我读完王伟杰《从程序员到架构师》的读书笔记。这只是一个总结，真正深入学习，还是推荐读书！

《从程序员到架构师》第四部分：微服务进阶场景实战

第 12 章 微服务的痛：用实际经历告诉你它有多少陷阱

1 业务痛点

微服务拆分后衍生 9 大核心问题，校招高频面试场景：

1. 服务边界难划分：业务归属模糊，跨团队需求扯皮，受组织架构（康威定律）、排期、绩效干扰；

2. 拆分粒度失控：容易过度拆分，服务数量爆炸，维护成本飙升；

3. 架构无全局视图，新人 / 领导无法完整梳理全链路依赖，故障排查难度大；

4. 大量重复代码，公共 Jar 包版本冲突，复用成本高于复制粘贴；

5. 资源消耗翻倍，多实例高可用需要大量服务器，硬件成本激增；

6. 分布式事务难题，多库更新无法用本地事务，极易出现数据不一致；

7. 循环依赖，服务互相调用，重构影响面极大，回归成本高；

8. 联调成本极高，多团队接口排期、对齐、调试耗费大量工时；

9. 测试部署复杂，本地无法完整启动全套微服务，共用测试环境经常排队争抢。

2 核心解决方案

1. 服务拆分规范

   • 遵循康威定律（设计系统的组织在设计系统时，会设计出基于这些组织的沟通 结构的系统），按业务域、团队职责划分；

   • 控制粒度：一个服务 3-4 人维护最佳，禁止为微小功能拆分新服务；

   • 定期梳理架构图，统一文档维护全局依赖视图。

2. 代码复用治理
   规范内部公共依赖包版本，分部门维护通用工具类，减少无意义复制。

3. 资源管控
   非核心服务单节点部署，流量低服务取消多副本，混合部署降低机器成本。

4. 依赖治理
   依靠全链路日志梳理服务调用关系，废弃老旧版本服务，避免 V1/V2 多版本长期共存。

5. 配套工具解决联调 / 部署痛点
   接口 Mock、容器化独立测试环境（对应 16、17 章方案），减少环境争抢、跨团队联调阻塞。

6. 分布式数据问题专项处理
   数据一致性（13 章）、跨服务数据同步（14 章）单独配套成熟方案。

3 小节

场景描述：单体拆分为微服务后，边界、依赖、事务、联调、资源出现大量衍生痛点，迭代效率不升反降。
面试重点：微服务优缺点、拆分难点、康威定律、微服务常见陷阱及规避手段。

第 13 章 数据一致性

1 业务痛点

跨多个微服务完成一笔业务（下单、扣积分、发券），多数据库独立，出现：

1. 上游更新成功、下游执行失败，数据不一致（有订单无库存 / 扣积分未发券）；

2. XA 分布式事务性能极差，锁持有时间长，高并发下严重拖慢接口；

3. 强一致性场景（资金、积分）不能容忍临时脏数据，最终一致性场景允许短暂延迟；

4. 补偿逻辑复杂，手动回漏数据成本高，缺少自动化兜底机制。

2 核心解决方案

解决方案核心思想：把其他服务的基础数据同步到本地库，本地联表查询，消除远程调用。

方案 1：最终一致性（报表、通知、订单库存等非资金场景）

实现机制：本地事务 + MQ 事件驱动

1. 服务完成本地数据库操作，投递消息到 MQ；

2. 下游消费消息执行业务，失败自动重试；

3. 所有接口强制幂等，避免重复消费造成数据错乱；

4. 定时对账脚本兜底，修复长期不一致数据。

方案 2：实时强一致性（资金、积分、交易）

1. TCC 模式：Try（预留资源）、Confirm（确认执行）、Cancel（回滚），侵入业务代码，适合核心金融场景；

2. Seata AT 模式（面试高频）：无代码侵入，自动生成 undo_log 记录前后镜像，全局失败自动回滚；

• 优势：仅需添加全局事务注解，开发成本低；

• 劣势：大事务、高并发场景性能损耗明显。

选型区分

• 允许短暂数据延迟：MQ 事件最终一致性；

• 资金 / 积分等强实时要求：Seata AT / TCC；

• 禁止使用 XA 2PC，性能差、可用性低。

3 小节

场景描述：跨服务多库操作，出现数据不一致，传统分布式事务无法适配线上高并发。
面试重点：最终一致性、TCC、Seata AT 原理、XA 缺陷、幂等设计、事务选型区分。

第 14 章 数据同步

1 业务痛点

多服务独立库，查询需要关联其他服务基础数据（商品、分类）：

1. 频繁远程调用依赖底层服务，接口超时、并发瓶颈；

2. 大量 IN 批量查询，数据库查询性能暴跌；

3. 上游基础表更新后，下游无法同步，查询数据老旧；

4. 服务循环依赖，底层基础服务被大量上游调用，成为性能瓶颈。

2 核心解决方案

1. 消息冗余同步（简单场景）
   基础数据变更发送 MQ，下游订阅更新本地冗余字段；缺点：消息种类多，同步逻辑重复开发。

2. Binlog 中间件实时同步（推荐，Bifrost/Canal/Debezium）

   • 原理：模拟 MySQL 从库监听 binlog，自动同步整表至下游数据库；

   • 优势：业务代码零侵入，一张表同步一次，无需写消息逻辑；

   • 约束：同步表仅做查询只读，核心写逻辑仍调源服务，容忍毫秒级同步延迟；

3. 适用边界：基础配置、商品、分类等低频变更、只读查询数据；库存、金额等实时写数据不适用。

3 小节

场景描述：微服务分库后，跨表查询依赖远程调用，性能差且服务压力集中。
面试重点：Canal/Bifrost 数据同步原理、binlog 同步优缺点、数据冗余两种方案对比、同步延迟业务取舍。

第 15 章 BFF（Backend for Frontend）

1 业务痛点

多端客户端（App、小程序、H5、PC）共用后端微服务，出现大量问题：

1. 前端页面需要聚合订单、商品、会员多服务数据，前端串行请求多次，页面加载慢；

2. 不同端字段需求不同，后端接口需要大量 if 判断适配客户端；

3. 服务之间互相调用，依赖关系错综复杂，重构回归成本极高；

4. 频繁改动前端展示字段，需要改动底层核心服务，频繁发布后端。

2 核心解决方案

1. 分层架构拆分
   网关 → BFF 层（按端拆分：AppBFF / 小程序 BFF/PC-BFF） → 底层领域微服务；

2. BFF 层职责（无自有数据库）

   • 数据聚合：一次请求调用多个底层服务，组装统一数据返回前端；

   • 字段裁剪 / 适配：针对不同端过滤、封装返回字段；

   • 简单参数转换，减轻前端处理压力；

3. 优势

   • 底层服务只处理领域核心逻辑，不关心前端展示差异；

   • 各端 BFF 独立迭代，改动前端展示无需发布底层服务；

   • 消除领域服务之间的互相调用，依赖收拢至 BFF 层。

4. 代码复用方案：通用聚合逻辑抽公共 Jar，避免多个 BFF 重复开发。

3 小节

场景描述：多端客户端复用后端服务，接口适配复杂、跨服务聚合请求性能差、服务依赖混乱。
面试重点：BFF 概念、分层职责、BFF 与网关区别、解决的核心问题、适用业务场景。

第四部分整体面试总结

1. 微服务拆分有哪些典型痛点？如何解决？
   答：边界模糊、粒度失控、分布式事务、循环依赖、联调困难；配套康威定律拆分、Seata/MQ 一致性、BFF 收拢依赖、Mock + 容器测试环境。

2. 跨服务数据不一致怎么处理，三种方案区别？
   答：最终一致性（MQ，低侵入、容忍延迟）、Seata AT（注解自动回滚，通用）、TCC（金融强一致，侵入代码），淘汰 XA。

3. 跨库基础数据查询慢，怎么同步数据？
   答：binlog 中间件（Canal/Bifrost）实时同步只读基础表，零业务侵入，仅用于查询，核心写仍调用源服务。

4. BFF 层作用是什么，和网关有什么区别？
   网关：鉴权、限流、路由、全局拦截；
   BFF：面向各端做数据聚合、字段适配，处理前端个性化展示逻辑。

5. 康威定律是什么，对微服务拆分有什么指导？
   答：系统设计匹配组织沟通结构，服务按团队业务职责拆分，避免跨团队高频调用。