微服务与分布式架构

这部分不是让你背“微服务优点”，而是让你能把它和自己的项目挂上。

你最稳的定位是：

我做过的很多系统虽然不一定是我从零搭起整套微服务平台，但我长期在多服务协同、服务边界划分、接口契约、异步解耦、状态一致性和联调治理里做方案和落地。

一、什么情况下要拆微服务

标准回答

不是业务一复杂就一定拆微服务，而是要看几个维度：

业务边界是否清晰
团队协作是否已经被单体拖慢
不同模块的扩缩容需求是否明显不同
不同链路的技术栈是否有差异
发布频率和变更风险是否已经影响整体系统

面试更稳的说法

我理解微服务不是“拆得越多越高级”，而是当单体已经在研发协作、发布节奏、性能隔离和业务边界上形成明显阻碍时，再拆才有价值。

结合你的项目怎么讲

海外业务平台里，识别鉴定、订阅支付、后台配置、报表归因，本身就是不同性质的链路
推广 ROI 线里，原始事件接入、Kafka 消费、回传处理、报表分析，也天然适合分层
你不是先按语言拆，而是先按职责拆，再决定哪些更适合 Go 服务，哪些继续放 PHP

二、服务拆分原则

你可以直接说

我拆服务时一般看 5 件事：

业务边界
数据边界
调用频率和实时性
发布节奏
团队 ownership

典型例子

海外业务平台

识别 / 鉴定能力层
订阅支付退款层
后台与运营配置层
报表与归因层

推广 ROI 线

原始点击曝光接入层
实时归因与行为回传层
规则配置与后台层
报表分析层

面试官喜欢的表达

我不会按“功能菜单”拆服务，而是按业务闭环、数据特征和运行特性拆。这样后续扩容、治理和定位问题都更清楚。

三、同步和异步怎么选

什么时候同步

必须立即返回用户结果
结果对当前请求强依赖
链路短，失败可直接反馈

什么时候异步

可以延迟处理
链路长
容易被峰值放大
涉及多个下游系统
有重试和补偿价值

结合你的项目怎么讲

在推广 ROI 项目里，如果把点击处理、归因、回传、报表更新全放同步链路，高峰期接口会很重，所以会通过 Kafka 解耦，让主流程只承接必须实时完成的部分。

四、多服务需求怎么做方案

你可以直接背

一个需求涉及多个服务时，我一般先做 5 个产物：

业务链路图
服务职责表
接口契约清单
联调测试矩阵
关键日志和 trace 方案

进一步展开

1. 先梳理链路

哪些服务参与
哪些是主状态
哪些是派生状态
哪些地方同步
哪些地方异步

2. 接口契约先行

请求字段
响应字段
状态枚举
错误码
幂等规则
超时和重试约定

3. 分段联调

先 mock
再本服务自测
再上下游分段联调
最后跑全链路

4. 可观测性先补齐

traceId
入口日志
状态变化日志
消息发送 / 消费日志
告警指标

五、分布式事务怎么理解

不要一上来就讲两阶段提交

更稳的说法是：

分布式事务的核心不是“怎么强行让所有服务一起成功”，而是先看业务是否真的需要强一致，很多业务更适合最终一致性。

常见方案

本地事务 + 消息
Outbox
事务消息
Saga
补偿机制
幂等控制

结合你的项目怎么讲

像支付成功后更新订单状态、发放权益、写报表、发通知，这类后续动作不一定都放一个大事务里，更合理的是订单主状态先落库，再通过消息和补偿机制推进后续链路。

六、幂等为什么重要

典型场景

支付回调重复
Kafka 重复消费
重试请求
用户重复提交
外部平台重复通知

你可以怎么答

我会先定义唯一键和幂等边界，再通过 Redis、数据库唯一约束或者条件更新做幂等控制。很多系统问题不是“少处理一次”，而是“乱处理一次”。

七、服务治理要点

必须准备

注册发现
配置中心
超时
重试
限流
熔断
链路追踪
降级

面试可说

微服务真正难的不是拆出来，而是拆出来以后如何治理。没有超时、重试、限流、trace 和配置治理，拆得越多问题越多。

八、技术总监最喜欢的问法和回答

1. 为什么这个系统要拆微服务

因为不同模块的业务边界、吞吐特征和发布节奏已经不同了。比如推广链路里的行为回传和报表刷新，和后台规则配置不是一类系统，继续混在一起会让扩容、故障隔离和发布都变差。

2. 你拆服务时最看重什么

我最看重业务边界、数据边界和运行特性。不是按页面拆，也不是按语言拆，而是看这段链路是不是独立闭环、是否有明显不同的吞吐和治理需求。

3. 多服务联调最容易出什么问题

不是代码写不出来，而是接口契约理解不一致、状态定义冲突、超时和重试策略不一致，最后联调阶段才集中爆出来。所以我更喜欢契约先行和分段联调。

九、你最适合背的总结句

我做微服务和分布式方案时，重点不是追求拆得多，而是看业务边界、数据边界和链路治理。我的经验更多在复杂业务系统落地，包括多服务职责划分、接口契约、同步异步拆分、幂等、补偿和联调治理，这些在海外业务平台和推广 ROI 线里都实际做过。