后端微服务（01）：微服务架构——服务拆分、注册发现、配置中心、网关、链路追踪

更新时间：2026-09-01。本文是 backend/microservice/ 微服务第 01 篇，在 微服务索引下。微服务架构把单体应用拆分成多个独立部署的服务，每个服务有自己的数据库，通过 API 通信。微服务带来了灵活性，也带来了分布式系统的复杂性。

本文要回答的问题

• 服务拆分的原则是什么？什么时候应该拆微服务？
• 注册发现和配置中心解决了什么问题？
• API 网关的作用是什么？和负载均衡有什么区别？
• 链路追踪怎么实现？OpenTelemetry 是什么？

一、服务拆分原则

什么时候拆？

单体应用的优势：
- 简单，开发快，部署简单
- 事务强一致，数据一致性好
- 调试方便，一个进程

适合拆微服务的迹象：
- 代码库太大，改一个功能需要长时间编译/测试
- 团队规模大，多个团队开发同一个模块
- 不同模块需要独立扩缩容
- 部分模块需要不同技术栈

拆分原则

1. 业务边界：按业务领域拆分（用户、订单、商品、支付）
2. 数据独立：每个服务有自己的数据库，不要共享数据库
3. 通信边界：服务间通过 API 通信，不要直接访问数据库
4. 部署独立：每个服务可以独立部署，独立扩缩容
5. 团队独立：每个服务由一个小团队全权负责

拆分顺序：
1. 从最稳定的业务开始拆（用户、商品）
2. 从最独立的业务开始拆（不依赖其他服务）
3. 先拆读，再拆写
4. 先拆非核心，再拆核心

二、注册发现

为什么需要注册发现？
- 微服务实例动态变化：扩容、缩容、故障、滚动更新
- 服务需要知道其他服务实例的地址（IP + 端口）

注册中心：
- 服务启动时向注册中心注册自己的地址
- 服务定期发送心跳（health check）
- 客户端从注册中心获取服务实例列表（服务发现）
- 注册中心检测到服务不可用，通知客户端

常见注册中心：
- Consul：K/V 存储 + 健康检查，支持多数据中心
- Etcd：强一致 K/V 存储，Kubernetes 使用
- Nacos：阿里开源，注册 + 配置二合一
- ZooKeeper：分布式协调，适合较小集群
- Kubernetes Services：K8s 自带，不用额外注册中心

三、配置中心

为什么需要配置中心？
- 微服务数量多，配置存储在 git 中，修改后需要重启
- 需要动态调整配置，不需要重启服务

配置中心功能：
- 配置存储：K/V 存储，版本管理
- 配置变更：修改后实时推送到所有服务
- 环境隔离：开发、测试、生产环境不同配置
- 配置回滚：错误配置可以回滚到旧版本

常见配置中心：
- Spring Cloud Config：Git 后端，推送到 Spring Boot
- Nacos：配置 + 注册中心，支持动态刷新
- Apollo：携程开源，配置中心功能完善
- Consul K/V：也可以做配置中心

四、API 网关

API 网关的作用：
1. 统一入口：所有客户端通过网关访问服务
2. 路由转发：根据请求路径转发到不同服务
3. 认证鉴权：统一认证，不需要每个服务重复实现
4. 限流熔断：保护后端服务
5. 日志采集：统一记录请求日志
6. 协议转换：外部 HTTP → 内部 gRPC
7. 负载均衡：分发请求到多个实例

常见网关：
- Nginx：高性能，功能单一
- Kong：基于 Nginx，插件多
- Envoy：高性能，C++ 实现，服务网格
- Spring Cloud Gateway：Java 生态，和 Spring Boot 集成好
- Zuul：Netflix 开源，Java 网关

网关 vs 负载均衡：
- 负载均衡：L4/L7 分发请求，功能简单
- 网关：L7 应用层，路由、认证、限流、日志等
- 网关通常包含负载均衡功能

五、链路追踪

为什么需要链路追踪？
- 一个请求跨多个服务，出问题时需要知道哪个服务出问题
- 每个服务有日志，但日志分散，需要把请求串起来

OpenTelemetry（OTel）：
- CNCF 开源，统一标准，替代 OpenTracing + OpenCensus
- 支持：tracing（追踪）+ metrics（指标）+ logs（日志）
- 语言：Java、Go、Python、Node.js 等

核心概念：
- Trace：一个请求的完整链路
- Span：链路中的一个操作（一个服务调用）
- Trace ID：整个链路的唯一 ID
- Span ID：当前操作的 ID
- Parent Span ID：父操作的 ID

# 实现
1. 网关生成 Trace ID，传递给下游
2. 每个服务在自己的日志中记录 Trace ID
3. 收集器收集所有 span，聚合展示
4. 可以查看：请求链路、每个服务的耗时、错误

# 工具
- Jaeger：可视化链路追踪（UI + 存储）
- Zipkin：链路追踪系统
- Grafana Tempo：和 Grafana 集成

六、微服务基础设施清单

组件	用途	常见选择
API 网关	统一入口	Nginx / Kong / Envoy
注册中心	服务发现	Consul / Nacos
配置中心	动态配置	Nacos / Apollo
链路追踪	请求追踪	OpenTelemetry + Jaeger
日志聚合	统一日志	ELK / Loki
监控告警	指标 + 告警	Prometheus + Grafana
服务网格	流量管理	Istio / Consul Connect
容器编排	部署管理	Kubernetes

七、常见坑对照

坑	现象	对策
拆分太细	服务间调用链太长，延迟高，定位问题难	按业务边界拆分，不要太细
共享数据库	服务间耦合，一个服务改表影响其他服务	每个服务独立数据库，通过 API 通信
分布式事务	跨服务的数据一致性问题	用 Saga 模式或最终一致性
服务间调用没有超时	一个服务慢，拖垮所有调用方	设置超时 + 熔断

相关与延伸

下一篇：Docker 容器化——镜像、容器、Dockerfile、Docker Compose、多阶段构建；消息中间件，见 消息中间件。

一句话总结

微服务架构：按业务边界拆分，每个服务独立数据库、独立部署、独立团队；注册发现（Consul/Nacos）解决服务实例动态变化问题，配置中心（Nacos/Apollo）实现动态配置不重启；API 网关统一入口，做路由、认证、限流、日志；链路追踪（OpenTelemetry + Jaeger）用 Trace ID 串联请求全链路，定位跨服务问题；微服务基础设施包括网关、注册中心、配置中心、链路追踪、日志聚合、监控告警；不要拆分太细，不要共享数据库，不要忘记设置超时和熔断。