📚 课程目录第3章微服务架构设计原理

微服务架构设计原理

本章聚焦微服务架构的核心设计要素：服务拆分、注册发现、配置中心、网关、服务网格。掌握这些原理是构建高可用、可扩展分布式系统的基础。

  面试高频信号：面试官通过追问“拆分依据”“一致性如何保证”“网关职责边界”来评估你对架构权衡的深度理解。

面试问题	如何进行微服务拆分？你会遵循哪些原则？
面试官考察点	是否理解领域驱动设计（DDD）、单一职责、高内聚低耦合；能否区分业务拆分与技术拆分。
回答框架	原则 → 方法论（DDD限界上下文）→ 案例（如电商拆订单、库存、支付）→ 数据独立性考虑。
简短示例回答	按业务领域拆分，如订单、商品、支付各成独立服务。遵循单一职责与团队独立迭代。避免过早拆分，先用单体，待业务边界清晰后再解耦。数据独立，每个服务拥有专属DB。
可能追问	拆分后出现跨服务事务怎么解决？如何识别限界上下文？拆分粒度如何把控？
避坑提醒	❌ 按技术层拆分（如API层、逻辑层），❌ 拆分后不治理导致网状调用，✅ 优先考虑业务变化频率。

面试问题	注册中心选型（如Consul、Nacos）与配置中心如何配合？服务上下线如何感知？
面试官考察点	是否熟悉健康检查、心跳机制、缓存降级；是否了解配置动态刷新与版本回滚。
回答框架	注册中心角色 → 服务实例注册/注销 → 消费者拉取/推送 → 健康检查 → 配置中心独立存储、监听改变 → 灰度配置。
简短示例回答	使用Nacos做注册与配置。服务启动时注册IP+端口，每5秒发送心跳；消费者订阅服务列表，本地缓存兜底。配置修改后Nacos推送到客户端，@RefreshScope自动刷新Bean。
可能追问	注册中心脑裂怎么处理？配置中心热更新如何保证一致性？Nacos与Consul区别？
避坑提醒	❌ 只依赖推送，忽略本地缓存；❌ 配置不区分环境导致生产事故；✅ 配置中心应支持多环境隔离与回滚。

面试问题	网关的核心职责是什么？服务网格（如Istio）能否完全替代网关？
面试官考察点	是否清楚网关（路由、限流、认证）与Sidecar代理（流量劫持、可观测性）的分层；能否理解Mesh解决了什么问题。
回答框架	网关层职责 → 常见实现（Kong、Spring Cloud Gateway）→ Mesh引入Sidecar并控制东西向流量 → 两者并存：网关处理南北向，Mesh处理服务间。
简短示例回答	网关负责认证、限流、协议转换；服务网格用Sidecar接管服务间通信，实现重试、熔断。两者不冲突：Gateway处理外部流量，Mesh管理内部调用，可叠加使用。
可能追问	网关单点故障如何解决？Istio中VirtualService与DestinationRule如何配合？
避坑提醒	❌ 认为Mesh能替代网关（实际功能不同）；❌ 过度使用网关做业务逻辑；✅ 网关保留轻量级路由，复杂治理下沉到Mesh。

项目名称	电商中台服务化重构（订单/支付/物流）
业务背景	原有单体电商日活超500万，每次发布影响全站，团队30+人协作效率低。需要拆分为独立微服务，支持快速迭代与弹性扩缩。
规模指标	日均接口调用量1.2亿，峰值QPS 2.5万；服务节点数80+；数据库分片32个；配置项2000+。
技术栈	Go (gin/gRPC) + Nacos (注册/配置) + Sentinel (限流熔断) + Kong (网关) + Jaeger (链路追踪) + Istio (部分服务网格试点) + PostgreSQL/MongoDB
核心难点	1) 历史数据迁移与双写；2) 跨服务分布式事务（Saga模式）；3) 配置热更新导致逻辑不一致；4) 从单体网关逐步过渡到Mesh的平滑方案。
面试高频追问	“为什么选Nacos而不是Consul？”“Saga事务回滚如何保证补偿幂等？”“Mesh试点后观测到了哪些收益？”
可迁移回答话术	“我主导了从单体到微服务的拆分，方案基于DDD限界上下文。注册配置统一使用Nacos，通过健康检查+本地缓存避免注册中心抖动影响。网关只做路由与限流，服务间熔断与重试下沉到Sidecar。关键经验是配置变更务必走灰度流程，以及分布式事务优先用异步补偿而非强一致。”这种表达能体现架构权衡与落地细节。

讲师提示： 微服务设计原理面试的核心是展示“权衡能力”——没有完美的拆分，只有适合业务阶段的选择。多结合你主导过的真实项目数据（如节点数量、QPS）来增强说服力。