微服务架构面试：服务拆分、通信与治理

微服务架构已成为现代企业级应用的主流选择。从Netflix到阿里巴巴，顶级科技公司都在大规模实践微服务。对于后端工程师和架构师而言，微服务相关问题是系统设计面试的必考内容。

为什么选择微服务架构？

单体架构的困境

传统单体应用将所有功能打包在一个部署单元中：

部署效率低：修改一行代码需要重新部署整个应用
技术栈僵化：难以引入新技术
扩展性差：无法针对热点模块独立扩容
故障影响大：一个模块的问题可能导致整个系统崩溃

微服务的核心优势

围绕业务能力组织
可独立部署和扩展
由小团队全权负责
技术栈自由选择

微服务架构示意图

flowchart TB
    subgraph Clients["客户端"]
        Web["Web App"]
        Mobile["Mobile App"]
        API_User["第三方API"]
    end
    
    subgraph Gateway["API网关层"]
        GW["API Gateway<br/>认证/限流/路由"]
    end
    
    subgraph Services["微服务层"]
        User["用户服务<br/>User Service"]
        Product["商品服务<br/>Product Service"]
        Order["订单服务<br/>Order Service"]
        Payment["支付服务<br/>Payment Service"]
    end
    
    subgraph Data["数据层"]
        UserDB[("用户DB")]
        ProductDB[("商品DB")]
        OrderDB[("订单DB")]
        Cache[("Redis缓存")]
    end
    
    subgraph Infra["基础设施"]
        MQ["消息队列"]
        Registry["服务注册中心"]
        Config["配置中心"]
    end
    
    Clients --> GW
    GW --> User
    GW --> Product
    GW --> Order
    GW --> Payment
    
    User --> UserDB
    Product --> ProductDB
    Order --> OrderDB
    User --> Cache
    
    Order -.->|异步通知| MQ -.-> Payment
    User --> Registry
    Order --> Registry
    
    style Clients fill:#e3f2fd
    style Gateway fill:#fff3e0
    style Services fill:#e8f5e9
    style Data fill:#fce4ec
    style Infra fill:#f3e5f5

服务拆分：从哪里开始？

拆分原则

1. 单一职责原则（SRP）

每个服务应该只做一件事，并且做好这件事。

2. 业务边界优先

服务边界应该与业务领域边界对齐，而非技术边界。领域驱动设计（DDD）中的限界上下文是最佳实践。

3. 数据独立性

每个服务应该拥有独立的数据库，避免跨服务的数据库耦合。

拆分策略

按业务能力拆分

业务能力	对应服务
用户管理	User Service
商品管理	Product Service
订单处理	Order Service
支付处理	Payment Service

常见陷阱

过度拆分：服务粒度过细，增加运维复杂度
分布式单体：服务拆分了，但耦合度依然很高
忽视数据迁移：数据拆分的复杂度被低估

服务通信：如何连接微服务？

同步通信

RESTful API

最常用的同步通信方式，基于HTTP协议：

简单易用，广泛支持
语言无关，跨平台
易于调试和测试

RPC框架

gRPC、Dubbo等RPC框架提供更高效的通信：

基于HTTP/2，支持双向流
使用Protocol Buffers，序列化效率高
强类型定义，代码生成支持多语言

异步通信

消息队列

消息队列实现服务间的异步解耦：

Kafka：高吞吐、持久化、适合日志和事件流
RabbitMQ：功能丰富、可靠性高
RocketMQ：阿里开源、事务消息支持好

通信方式选择指南

场景	推荐方式	理由
需要即时响应	同步（REST/RPC）	调用方可等待结果
流量削峰	异步（MQ）	队列缓冲流量
跨团队协作	RESTful API	标准化、易理解
内部高频调用	RPC	性能优先

服务治理：如何管理微服务？

服务发现

在微服务环境中，服务实例动态变化，需要一种机制让服务相互发现。

常用注册中心：

Nacos：阿里开源，支持服务发现和配置管理
Consul：HashiCorp出品，支持多数据中心
Eureka：Netflix开源，AP架构

负载均衡

服务端负载均衡：Nginx、F5等
客户端负载均衡：Ribbon、gRPC客户端

熔断与降级

分布式系统中，服务故障会级联传播。熔断器模式防止故障蔓延：

熔断器状态机：

关闭状态：正常调用
打开状态：错误率超阈值，直接返回失败
半开状态：尝试少量请求，判断是否恢复

常用实现：

Hystrix：Netflix开源，功能完善
Resilience4j：轻量级，模块化设计
Sentinel：阿里开源，支持流量控制

高频面试题解析

Q1：微服务和SOA的区别？

特性	微服务	SOA
服务粒度	细粒度	粗粒度
通信方式	轻量级（REST/RPC）	重量级（ESB）
数据管理	每服务独立数据库	共享数据库
部署方式	独立部署	集中部署