微服务核心概念与面试高频考点
面试中微服务基础概念是必考项，尤其考察对架构本质的理解、服务拆分原则和基础设施选型。以下给出高频问题的回答框架、公司侧重点对比，以及面试问答卡片，帮助你快速构建答题逻辑。
大厂面试侧重点一览
| 公司 | 侧重点 | 常见追问方向 |
|---|---|---|
| 阿里巴巴 | 服务治理、高可用 | Sentinel 限流降级、Nacos 配置管理 |
| 腾讯 | 分布式事务、消息 | TCC 方案、RocketMQ 事务消息 |
| 字节跳动 | RPC 框架、链路追踪 | Dubbo 原理、OpenTelemetry 落地 |
| 美团 | 服务网格、容器化 | Istio 流量管理、K8s 容器编排 |
面试问答卡片
面试问题
请谈谈你对微服务架构的理解，以及它与单体架构的主要区别？
面试官考察点：基础概念清晰度、架构对比深度、实际应用思考。
回答框架
- 定义：微服务是一组独立部署的小服务，每个服务围绕业务能力构建。
- 关键特征：独立部署、去中心化治理、技术栈多样性。
- 与单体对比：单体所有功能在单一进程，微服务拆分后带来弹性、可扩展性，但增加网络通信和运维复杂度。
- 优缺点：优点（灵活、容错、团队自治），缺点（分布式事务、调试困难、服务治理成本）。
- 适用场景：大型互联网项目、多团队协作、需要快速迭代的场景。
简短示例回答
微服务架构将单体应用拆分为多个独立服务，每个服务可独立部署，通过轻量级通信协作。与单体相比，它提升了模块化和弹性，但引入了分布式复杂性，例如网络延迟和数据一致性。像电商平台的订单、库存服务拆分就属于典型实践。
可能追问
- 你认为微服务一定比单体好吗？什么场景下单体更合适？
- 微服务中如何保证数据一致性？
- 服务间通信常用的方式有哪些？
避坑提醒：不要只背概念，一定要结合你实际项目中的服务拆分案例，说明拆分的依据和遇到的问题。
面试问题
微服务架构中如何进行服务拆分？有哪些核心原则？
面试官考察点：领域建模能力、拆分原则理解、实践经验。
回答框架
- 先理解业务领域，使用 DDD 限界上下文划分核心域与支撑域。
- 原则一：单一职责——每个服务只负责一个业务能力。
- 原则二：高内聚低耦合——服务内部强相关，服务间接口稳定。
- 原则三：数据独立——每个服务拥有自己的数据库，避免紧耦合。
- 原则四：独立部署——拆分后能独立发布，不依赖其他服务同时上线。
简短示例回答
我采用 DDD 限界上下文进行拆分，例如将订单、支付、库存拆分为独立服务。遵循单一职责原则，每个服务只处理自己的业务逻辑；数据独立，订单库与库存库分离；最终实现各服务可独立部署和扩展，避免了单体修改时的全局影响。
可能追问
- 拆分后服务间如何保持数据一致性？
- 你的项目中有没有拆分过细导致过度拆分？如何解决？
- 如何拆分足够粗粒度？
避坑提醒：不能只列原则，要举出反例——拆分过细导致的“服务地狱”，以及如何用聚合边界来约束。
面试问题
微服务中服务发现是如何实现的？客户端发现和服务端发现有什么区别？
面试官考察点：服务发现原理、注册中心选型、实际组件使用经验。
回答框架
- 服务发现核心：服务启动时向注册中心注册，消费者获取服务地址列表。
- 客户端发现：消费者直接查询注册中心，如 Eureka、Consul，优点是无额外中间件，缺点是客户端要集成逻辑。
- 服务端发现：消费者请求负载均衡器，由它查询注册中心并转发，如 Nginx + Consul、Kubernetes Service。
- 常见组件：Nacos、Zookeeper（不推荐作为注册中心）、Eureka（已进入维护期）。
- 健康检查：服务通过心跳续约，注册中心剔除宕机实例。
简短示例回答
我使用 Nacos 作为注册中心，采用客户端发现模式。服务启动时调用 Nacos API 注册，消费者定时拉取服务列表并缓存。通过心跳检测保证实例健康，当服务下线时自动摘除。相比服务端发现，客户端发现延迟更低，但需要每个服务集成发现逻辑。
可能追问
- 注册中心如果挂了怎么办？你怎么做高可用？
- 客户端缓存的服务列表如何做到实时更新？
- Nacos 和 Eureka 的区别？
避坑提醒：不要只背注册中心概念，要讲清楚你项目中如何配置注册中心集群、如何应对网络分区（如 Nacos AP/CP 模式切换）。