06 - 一套微服务系统的全景架构

前面我们有了四个业务服务（用户、商品、订单、支付），它们会通信、各管各的库。但如果就这么散着，会冒出一堆现实问题：

• 客户端（App/网页）到底该请求哪个服务的地址？难道要记住四个 IP？
• 服务会挂、会重启、会扩容变多，地址一直在变，谁去调它的人怎么找得到？
• 同一个服务开了好几份，请求该发给哪一份？
• 几十个服务的配置（数据库密码、开关）散落各处，怎么统一管？
• 一个请求跨了好几个服务，出错了怎么知道是哪一环？

于是，微服务系统里会多出来几个**“配角”服务**，专门解决这些问题。这一章只讲它们各自干什么用，不讲怎么配置。

先看全景图

                     ┌─────────────┐
   客户端(App/网页) ──▶│  API 网关     │  ← 所有请求的统一大门
                     └──────┬──────┘
                            │  （鉴权、限流后，转发给对应服务）
        ┌───────────┬───────┼────────────┬───────────┐
        ▼           ▼       ▼            ▼           ▼
   ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
   │用户服务 │ │商品服务 │ │订单服务 │ │支付服务 │  ← 业务服务（可能各开好几份）
   └────────┘ └────────┘ └────────┘ └────────┘
        │           │        │            │
        └────── 都向"服务注册中心"登记自己的地址 ──────┘
                            │
        ┌───────────────────┼───────────────────┐
        ▼                   ▼                   ▼
  ┌───────────┐      ┌───────────┐       ┌───────────┐
  │服务注册发现 │      │  配置中心   │       │链路追踪/监控│
  └───────────┘      └───────────┘       └───────────┘

下面逐个说这些配角。

1. API 网关：所有请求的”统一大门”

客户端不直接去找四个业务服务，而是只跟网关打交道。网关像小区的门卫室，所有人进出都走这里。

它干这几件事：

• 路由转发：看请求是找订单的还是找用户的，转给对应服务
• 鉴权：先检查你登录了没、有没有权限，没通过直接挡回去（业务服务就不用每个都自己做一遍登录校验）
• 限流：流量太猛时挡一部分，保护后面的服务

好处：客户端只需要知道一个地址（网关），后面服务怎么拆、怎么变，客户端都无感。

2. 服务注册与发现：服务多了怎么互相找

服务会重启、会扩容、会换机器，地址一直在变。写死 IP 是行不通的。于是有了注册中心，像一个”通讯录”：

服务启动时 → 主动去注册中心登记："我是订单服务，我在 10.0.0.7:8000"
服务挂了   → 从通讯录里被划掉
别人要调它 → 先问注册中心："订单服务现在在哪？" → 拿到地址再去调

这样谁也不用记死地址，通过名字就能找到对方。

3. 负载均衡：同一个服务开了好几份，请求发给谁

订单服务压力大，开了 3 份。一个请求进来，该给哪一份？负载均衡负责把请求均匀地分给这几份，别让某一份累死、其他闲着。

你会发现：注册发现 + 负载均衡，正好是 K8s 天生就帮你做好的事（下一章讲）。

4. 配置中心：几十个服务的配置统一管

数据库密码、第三方密钥、功能开关……如果散在每个服务自己的配置文件里，改一个要改几十处。配置中心把它们集中管理：

• 配置统一放一处，改一次，相关服务自动生效
• 不同环境（开发/测试/生产）的配置分开管

5. 链路追踪与监控：出错了怎么定位

一个”下单”请求，可能依次经过网关 → 订单 → 商品 → 支付。中间某一环慢了或挂了，怎么知道是哪一环？

• 链路追踪：给每个请求发一个”追踪号”，它走过的每个服务都带着这个号记日志。出问题时，用这个号一串，整条链路清清楚楚。
• 监控告警：盯着各服务的健康状况（响应时间、错误率），异常了自动报警。

服务越多，“看得见”就越重要。没有追踪和监控，微服务出了问题就是一团乱麻。

一句话记住这些配角的分工

小结

• 业务服务之外，微服务系统还需要一批配角来支撑整体运转。
• API 网关（统一大门）、服务注册发现（通讯录）、负载均衡（分流）、配置中心（统一配置）、链路追踪/监控（看得见）。
• 记住它们各自解决什么问题就够了，配置细节是后话。
• 好消息：其中不少（注册发现、负载均衡、部署伸缩）都能靠容器编排平台帮你搞定——下一章讲。

上一章 ← 05 - 数据怎么办：每个服务一个数据库 ｜ 下一章 → 07 - 微服务怎么跑起来：容器与编排 ｜ 回到 README 目录