Microservice

微服务治理-API网关 API Gateway 是微服务系统的统一入口层，负责请求路由、协议转换、安全控制、流量治理与聚合编排，是连接外部世界与内部微服务体系的核心枢纽。 一、介绍（Introduction） 1.1 为什么需要 API Gateway？ 在没有网关之前： 问题 1：客户端需要知道所有服务地址 前端 / App 直接耦合后端服务拓扑。 问题 2：安全无法统一控制 每个服务都要： 鉴权 权限 限流 黑名单… 问题 3：跨服务调用暴露内部结构 问题 4：接口碎片化 一个业务页面可能需要多个服务，前端要请求 4～10 次 API。 1.2 API Gateway 的作用 Client │ ▼ API Gateway │ ├── User Service ├── Order Service ├── Payment Service └── Inventory Service 网关成为： 唯一入口 1.3 API Gateway 解决什么问题？ 1. 统一入口 如：所有请求：https://api.xxx.com/* 2. 路由转发 /api/user → user-service、 /api/order → order-service...

微服务治理-服务监控 服务监控（Metrics Monitoring）用于对系统运行状态进行持续量化观测，通过指标数据（QPS、RT、错误率、资源使用率等）实现对微服务系统健康状况的实时评估与告警。 一、介绍 1.1 为什么需要监控？ 链路追踪解决的是：“这一次请求为什么慢？” 但通常还需要知道：“整个系统现在健康吗？” 比如：系统很卡问题 你需要判断： 是 CPU 高了？ 是数据库慢了？ 是某个接口爆了？ 还是流量暴涨？ 1.3 监控解决什么问题？ 一句话总结： 把系统运行状态数字化 + 可视化 + 可告警 核心能力： 实时状态 历史趋势 异常检测 自动告警 容量规划 1.4 三大核心指标类型 System Metrics（系统指标） Application Metrics（应用指标） Business Metrics（业务指标） 二、核心指标（Metrics） 2.1 系统指标（System Metrics） 关注机器层面： CPU 使用率 内存使用率 磁盘 IO 网络流量 2.2 应用指标（Application Metrics） 关注服务本身： QPS（每秒请求数） RT（响应时间） 错误率（Error Rate） 并发连接数 2.3 业务指标（Business Metrics） 关注业务结果： 下单成功率 支付成功率 注册转化率 GMV 三、应用 Prometheus + Grafana + Alertmanager轻量级监控告警系统

微服务治理-服务调用 微服务拆分之后，服务之间不再是进程内方法调用，而是通过网络进行通信。服务调用（Service Communication）就是研究不同服务之间如何安全、高效、可靠地进行数据交换。 一、介绍 1.1 为什么需要服务调用？ 在单体架构中：只掉调用方法，比如 $user = $this->userService->getUser(1); 只是一次普通的方法调用（Method Call）。 没有网络、没有序列化、没有超时、没有连接 而微服务以后： 已经变成：HTTP、TCP、gRPC 所有调用都变成：网络通信（Network Communication） 1.2 微服务调用有哪些方式？ 主要有三种： 1. HTTP REST 优点： 简单 通用 调试方便 缺点： JSON 较大 序列化效率较低 2. RPC 看起来像：本地方法。 实际上走的是网络。 3. gRPC 底层： HTTP/2。 Protobuf。 速度：非常快。 1.3 怎么选择调用方式？ 场景 推荐 对外 API HTTP REST 内部服务调用 gRPC 旧系统兼容 HTTP 高频通信 gRPC 即： 外部使用 HTTP。 内部使用 gRPC。 二、原理 2.1 一次 HTTP 调用发生了什么？ 业务代码 │ ▼ DNS / 服务发现 │ ▼ TCP 建立连接 │ ▼ 发送 HTTP 请求 │ ▼ User Service │ ▼ 返回 JSON 如果没有连接池。...

微服务治理-注册中心 一、介绍 1.1 什么是注册中心 注册中心可以理解为： 整个微服务系统的“通讯录”或“服务目录”。 在单体应用中： Web │ ▼ Controller │ ▼ Service │ ▼ Repository 所有模块都运行在同一个进程中，方法之间直接调用： $user = $this->userService->getUser($id); 开发者无需关心： 服务在哪里？ IP 是多少？ 端口是多少？ 因为它们都在同一个应用中。 而在微服务架构中： User Service 10.0.0.10 │ Order Service ---------------- Product Service 10.0.0.11 10.0.0.12 现在 Order Service 想调用 User Service。 问题来了：Order Service 怎么知道 User Service 在哪里？ 如果直接写 IP：虽然可以运行，但会产生很多问题。 1.2 为什么不能写死 IP？ 假设：今天：User Service 10.0.0.10 后面因为扩容：User Service 10.0.0.20 或者增加服务器：10.0.0.xxx 那么： 所有调用 User Service 的项目：都要修改配置。 到底调用哪一个? 于是：...

微服务治理-负载均衡 一、介绍 1.1 什么是负载均衡 负载均衡（Load Balancing）是微服务治理中的核心能力之一，它负责在多个服务实例之间合理分配请求，提高系统吞吐能力、可用性和扩展能力 假设： User Service 只有一台服务器：10.0.0.5 随着后面业务越来越大增加服务器：10.0.0.5，10.0.0.6，10.0.0.7 … 现在应该调用哪一个？ 于是出现： 负载均衡（Load Balancing） 它负责： 从多个可用实例中选择一个最合适的实例。 1.2 为什么需要负载均衡？ 假设：10000 个请求全部发送：10.0.0.5 导致服务宕机 结果： 10.0.0.6, 10.0.0.7 却一直空闲 负载均衡能够平均分配 1.3 负载均衡解决什么问题？ 主要包括 1.流量分摊 2.提高可用性 3.方便扩容 4. 支持灰度发布 二、原理 2.1 整个调用流程 Order Service ↓ Service Discovery ↓ Registry ↓ 返回： 10.0.0.5 10.0.0.6 10.0.0.7 ↓ Load Balance ↓ 选择： 10.0.0.6 ↓ HTTP 2.2 轮询（Round Robin） 特点： 简单 公平 实现容易 缺点： 不能反映机器性能差异。 2.3 随机 优点：...

微服务治理-服务发现 一、介绍 1.1 什么是配置中心 在单体应用时代，我们通常这样管理配置： .env文件 但是进入微服务以后。 现在：每个服务都有自己的配置 比如REDIS_HOST需要修改，几十个服务的.env都要修改 于是就需要： 配置中心（Configuration Center） 1.2 配置中心解决什么问题？ 一句话总结： 统一管理所有配置。 二、原理 2.1 配置中心整体架构 典型架构： Config Center (Nacos / Apollo) ▲ │ Read Config│ ┌────────┬─────────┼──────────┐ ▼ ▼ ▼ ▼ Gateway User Order Payment 服务：启动 读取：配置。 运行： 监听：配置变化。 2.2 配置加载流程 User Service为例 启动 ↓ 读取配置中心 ↓ 下载配置 ↓ 缓存到本地 ↓ 程序启动 2.3 动态刷新 配置修改时： 配置中心通知各个服务，自动刷新，无需重启 2.4 配置版本管理 如果修改错误：可以恢复上一版本 2.5 环境隔离 比如 开发环境DEV、测试环境TEST、预发布UAT、生产环境PROD 配置分别管理 三、主流配置中心 产品 特点 是否支持动态刷新 Nacos 注册中心 + 配置中心 ✅ Apollo 配置中心 ✅ Consul KV KV 存储 + 配置 ✅ Etcd KV 存储 ✅ Nacos最常用...

微服务治理-链路追踪 链路追踪（Distributed Tracing）是微服务可观测性（Observability）的核心能力之一，用于在分布式系统中还原一次请求的完整调用路径，并定位性能瓶颈与故障点。 一、介绍 1.1 为什么需要链路追踪？ 在单体应用中：一次请求在同一个进程内完成，只需要 打日志 打断点 其他调试 即可定位问题。 但在微服务架构中： Client ↓ API Gateway ↓ User Service ↓ Order Service ↓ Payment Service ↓ Inventory Service ↓ DB / MQ 一次请求变成： 跨进程 + 跨机器 + 跨网络 1.2 典型问题 问题1：不知道慢在哪里 比如 ：接口很慢 但系统里有：Gateway、User、、Order… 你无法判断：到底慢在谁？ 问题2：日志分散 如： Gateway logs User logs Order logs Payment logs 每个服务都有日志,但它们之间没有关联关系。 问题3：无法串联一次请求 无法确认日志是不是同一个请求？ 1.3 链路追踪要解决什么问题？ 把一次请求在多个微服务中的完整路径“串起来” 核心能力： 请求路径可视化 性能瓶颈定位 服务依赖分析 故障快速定位 二、原理 2.1 核心概念 链路追踪有三个核心概念：...

连接池 一、概述 1.1 什么是连接池 连接池（Connection Pool）是： 预先创建一定数量的连接，并统一管理和复用这些连接，而不是每次请求都重新建立连接。 这里的"连接"不仅指数据库连接，还包括： MySQL 连接 Redis 连接 HTTP 连接 gRPC 连接 Kafka 连接 RabbitMQ 连接 本质上，只要是建立成本较高、可以复用的连接，都适合使用连接池。 1.2 为什么需要连接池 假设没有连接池： 每个请求执行流程如下： HTTP Request │ ▼ 创建 MySQL 连接 │ ▼ 执行 SQL │ ▼ 关闭连接 如果系统每秒有 5000 个请求, 服务器的大量资源都会浪费在建立连接上，而不是执行业务。 1.3 建立一个连接到底需要做什么？ 以 MySQL 为例： Application │ ▼ TCP 三次握手 │ ▼ SSL/TLS（可选） │ ▼ MySQL 用户认证 │ ▼ 权限校验 │ ▼ 初始化 Session │ ▼ 返回连接对象 这整个过程远比执行一条简单 SQL 更耗时。...

并发模型-协程模型 一、介绍 1.1 什么是线程 协程（Coroutine）是一种： 运行在用户态、由程序自身调度的轻量级执行单元。 它不像线程那样由操作系统调度，而是由运行时（Runtime）负责调度。 例如： 操作系统 │ ▼ Worker（线程） │ ┌──┼───────────────┐ │ │ │ ▼ ▼ ▼ 协程1 协程2 协程10000 可以看到： 一个线程 可以运行成千上万个协程 1.2 为什么会出现协程 先看传统线程。 例如： 线程1 ↓ 查询 MySQL ↓ 等待200ms 等待期间： CPU： 空闲 线程： 阻塞 CPU 没有工作。 协程出现以后： 协程1 ↓ 等待 MySQL ↓ 主动让出 CPU ↓ 协程2 开始执行 ↓ 协程3 开始执行 CPU 一直在处理其它任务。 因此： 协程解决的是 IO 等待导致 CPU 空闲的问题。 1.3 协程不是线程 协程永远依附于线程。 没有线程： 协程无法运行。...

并发模型-线程模型 一、介绍 1.1 什么是线程 线程（Thread）是： CPU 调度和执行任务的最小单位。 一个进程（Process）可以包含多个线程，这些线程共享进程的内存空间和资源，但拥有各自独立的执行栈和程序计数器。 例如： 操作系统 │ ▼ Chrome（进程） │ ┌────┴────┐ │ │ ▼ ▼ 线程1 线程2 线程是真正执行代码的主体，而不是进程。 1.2 进程与线程的区别 对比项 进程（Process） 线程（Thread） 定义 资源分配的基本单位 CPU 调度的基本单位 是否独立内存 是 否（共享进程内存） 创建成本 高 较低 通信方式 IPC（管道、Socket、共享内存等） 共享变量、锁 崩溃影响 一般不影响其他进程 一个线程异常可能导致整个进程退出（视语言/运行时而定） 1.3 为什么需要线程 假设没有线程： 用户A请求 ↓ 执行3秒 ↓ 用户B开始执行 所有请求只能串行处理。 有线程以后： 线程1 处理用户A 线程2 处理用户B 线程3 处理用户C CPU 可以调度多个线程并发执行，从而提高系统吞吐能力。 1.4 项目中的线程 PHP-FPM HTTP Request ↓ PHP-FPM Worker（进程） ↓ 执行 PHP 脚本 ↓ 请求结束 PHP-FPM 不是线程模型，而是多进程模型，每个 Worker 一次只处理一个请求。...