微服务架构下API设计不同于单体应用，需要考虑服务边界、接口粒度、服务间通信等多个新维度。设计不当会导致服务耦合紧密、调用链复杂，违背微服务的初衷。本文总结微服务API设计的核心要点和实践经验。
服务拆分与API边界
服务拆分决定了API的边界。拆分原则：业务边界清晰划分，每个服务拥有独立的业务领域和数据库。API是服务对外暴露的契约，API的设计约束了服务之间的交互方式。好的拆分让API自然合理，不好的拆分导致API交互复杂。以电商为例：用户服务管理用户信息和认证，商品服务管理商品目录和库存，订单服务处理交易流程。每个服务只暴露与自身领域相关的API。
接口粒度控制
微服务接口粒度需要合理把握。太粗：一个API返回大量数据，包含多个领域的信息，导致服务间耦合。太细：一个业务操作需要调用多个API，增加网络开销和调用复杂度。衡量标准：API是否以业务聚合为单位设计。查询用户时同时返回用户的基本信息和角色权限是合理的，但查询用户时同时返回用户的所有订单信息就是粒度过粗。
服务间通信模式
同步通信：通过REST或gRPC直接调用下游服务，实现简单但存在级联故障风险。异步通信：通过消息队列解耦服务，服务之间不直接依赖，可靠性高但一致性实现复杂。选择原则：强一致性要求高的场景用同步通信，最终一致性可接受的场景用异步通信。查询操作用同步，命令操作用异步。事件驱动模式让服务通过事件交互，耦合度最低。
API网关在微服务中的角色
微服务架构中API网关对外部客户端屏蔽内部服务结构。外部客户端只与网关交互，网关将请求路由到对应的微服务。网关承担认证、限流、日志等横切关注点。BFF模式：每种客户端类型有独立的网关后端，返回适合该客户端的数据格式。网关还能实现协议转换，让外部HTTP协议与内部gRPC协议互通。网关不是必须的，但对于多个客户端的场景非常有用。