面试题：微服务架构里服务拆分对系统耦合性与性能的平衡

Question

在采用服务拆分策略时，如何在降低系统耦合性的同时，避免因拆分过度导致系统性能下降，例如在远程调用频繁、数据一致性维护等方面，需要采取哪些措施？

Answer 1

降低远程调用频繁的措施

1. 合理规划服务边界：
   • 基于业务功能模块进行拆分，确保每个服务职责清晰单一，避免将紧密相关的功能拆分得过细。例如，电商系统中，订单处理相关功能（下单、支付、订单状态更新等）可放在一个订单服务中，而不是将下单和支付再拆分为独立的小服务，减少不必要的远程调用。
   • 运用领域驱动设计（DDD）方法，通过划分限界上下文来界定服务边界，每个限界上下文内的业务逻辑相对独立，从而减少跨服务交互。
2. 使用缓存机制：
   • 在服务层添加本地缓存，对于频繁访问且不经常变化的数据，如商品分类信息、地区编码表等，直接从缓存中获取，避免每次都远程调用其他服务获取数据。例如，使用 Redis 作为缓存中间件，在服务启动时预加载部分常用数据到缓存中。
   • 采用读写分离策略，写操作更新数据库后同步更新缓存，读操作优先从缓存读取，这样能显著减少对后端服务的读请求压力。
3. 合并远程调用：
   • 设计批量接口，当客户端需要从多个服务获取数据时，提供批量获取数据的接口。例如，在用户管理服务中，若需要同时获取用户基本信息、用户权限信息和用户最近登录记录，可设计一个批量接口一次性返回这些数据，而不是让客户端分别调用三个不同的服务接口。
   • 引入聚合服务，将多个相关服务的功能进行聚合，由聚合服务统一对外提供接口。例如，在一个复杂的企业级应用中，可能有员工信息服务、部门信息服务和薪资服务，可创建一个人力资源聚合服务，整合这些服务的功能，减少客户端与多个服务的直接交互。

维护数据一致性的措施

1. 分布式事务处理：
   • 两阶段提交（2PC）：协调者先向所有参与者发送准备指令，参与者执行本地事务操作并将结果反馈给协调者。若所有参与者都准备成功，协调者再发送提交指令，参与者正式提交事务；若有任何一个参与者准备失败，协调者发送回滚指令。例如在银行转账场景中，转出账户服务和转入账户服务作为参与者，银行转账协调服务作为协调者来保证转账操作的原子性。但 2PC 存在单点故障（协调者故障可能导致事务无法完成）和性能瓶颈（阻塞时间长）等问题。
   • 三阶段提交（3PC）：在 2PC 的基础上增加了一个预询问阶段，协调者先询问参与者是否可以执行事务，参与者反馈自己的状态，协调者根据反馈决定是否继续事务。这样在一定程度上解决了 2PC 的单点故障问题，但实现复杂且性能提升有限。
   • TCC（Try - Confirm - Cancel）：Try 阶段尝试执行业务操作，预留业务资源；Confirm 阶段确认执行业务操作，使用预留的资源完成业务；Cancel 阶段取消 Try 阶段的操作，释放预留资源。例如在电商订单支付场景，Try 阶段冻结支付金额，Confirm 阶段完成支付，Cancel 阶段解冻金额。TCC 适用于对一致性要求高且业务逻辑可补偿的场景，但代码侵入性较大。
2. 最终一致性方案：
   • 消息队列：将需要跨服务处理的业务操作封装成消息发送到消息队列中。例如在电商系统中，下单成功后，将订单相关信息发送到消息队列，库存服务、物流服务等从消息队列中消费消息并进行相应处理。通过消息重试机制保证消息不丢失，最终实现数据一致性。
   • 事件溯源：记录所有对数据的更改操作作为事件，通过回放事件来重建数据状态。当服务间数据不一致时，可以通过重新处理事件来恢复一致性。例如在订单状态管理中，记录订单创建、支付、发货等一系列事件，根据这些事件可以准确还原订单状态。
3. 数据同步机制：
   • 定期数据核对：定时任务定期检查各服务之间的数据一致性，发现不一致时进行修复。例如每天凌晨对订单服务和库存服务的数据进行比对，若发现订单数量和库存数量不一致，通过重新计算或数据同步操作进行修正。
   • 基于日志的数据同步：利用数据库的日志（如 MySQL 的 binlog），通过解析日志获取数据变更信息，并将这些变更同步到其他相关服务的数据库中。例如，电商商品服务的数据库发生商品价格变更，通过解析 binlog 将价格变更信息同步到搜索服务的数据库，保证搜索结果中商品价格的一致性。