Microservice on Leanku 的博客

微服务治理-API网关

Mon, 15 Sep 2025 20:46:01 +0800

微服务治理-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

3. 鉴权（Auth）

统一处理：

微服务治理-服务调用

Mon, 15 Sep 2025 20:46:01 +0800

微服务治理-服务调用

微服务拆分之后，服务之间不再是进程内方法调用，而是通过网络进行通信。服务调用（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

如果没有连接池。

微服务治理-服务监控

Mon, 15 Sep 2025 20:46:01 +0800

微服务治理-服务监控

服务监控（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轻量级监控告警系统

微服务治理-负载均衡

Mon, 15 Sep 2025 20:46:01 +0800

微服务治理-负载均衡

一、介绍

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 随机

优点：

微服务治理-链路追踪

Mon, 15 Sep 2025 20:46:01 +0800

微服务治理-链路追踪

链路追踪（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.Trace（一次完整请求）

Trace = 一次完整请求生命周期

微服务治理-配置中心

Mon, 15 Sep 2025 20:46:01 +0800

微服务治理-服务发现

一、介绍

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最常用

微服务治理-注册中心

Mon, 15 Sep 2025 20:46:01 +0800

微服务治理-注册中心

一、介绍

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 的项目：都要修改配置。

到底调用哪一个?

于是：

需要一个统一管理所有服务信息的地方。

连接池

Fri, 15 Aug 2025 20:46:01 +0800

连接池

一、概述

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 更耗时。

Kong+Konga+Consul

Fri, 01 Aug 2025 11:46:01 +0800

Kong+Konga+Consul 安装和使用

此处使用Docker安装方式

一、安装Kong

kong具体使用可参考另一篇文章：Kong API网关

为了确保 Kong、Konga 和 Consul 能够通信，Kong 和 Konga 也需要加入到同一个网络。如果你尚未创建网络，或者希望使用新的网络，可以创建一个：

1docker network create kong-net

1.1 安装 PostgreSQL (Kong 的数据库)

Kong 需要 PostgreSQL 来存储其配置数据

1docker run -d --name kong-database \
2 --network=kong-net \
3 -p 5432:5432 \
4 -e "POSTGRES_USER=kong" \
5 -e "POSTGRES_DB=kong" \
6 -e "POSTGRES_PASSWORD=kong" \
7 postgres:13

–network=kong-net: 确保数据库与 Kong、Consul 在同一网络。
-e 环境变量：设置数据库的用户名、数据库名和密码。
建议使用 PostgreSQL 9.6 或更高版本，这里使用了 13 版本。

1.2 初始化 Kong 数据库

运行一个临时容器来执行数据库迁移：

1docker run --rm \
2 --network=kong-net \
3 -e "KONG_DATABASE=postgres" \
4 -e "KONG_PG_HOST=kong-database" \
5 -e "KONG_PG_USER=kong" \
6 -e "KONG_PG_PASSWORD=kong" \
7 kong:3.6.1 kong migrations bootstrap

--rm: 容器退出后自动删除。

并发模型-线程模型

Fri, 11 Jul 2025 20:46:01 +0800

并发模型-线程模型

一、介绍

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 一次只处理一个请求。

并发模型-协程模型

Fri, 11 Jul 2025 20:46:01 +0800

并发模型-协程模型

一、介绍

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 协程不是线程

协程永远依附于线程。

没有线程：

协程无法运行。

二、原理

2.1 协程为什么快

假设：

高并发系统设计-服务降级

Fri, 11 Jul 2025 20:46:01 +0800

高并发系统设计-服务降级

一、概述

1.1 什么是服务降级

服务降级（Fallback）指的是：

当系统压力过大或依赖服务不可用时，主动返回一个“可接受的替代结果”，而不是让请求失败。

例如：

正常：
→ 查询实时商品详情

降级：
→ 返回缓存商品详情 / 静态数据

1.2 降级和熔断的区别

项目	熔断	降级
目的	防止故障扩散	保证可用性
触发	服务异常	系统压力 / 异常
行为	阻断调用	返回替代结果
是否对外可用	否	是

熔断 = 不调用

降级 = 换一种方式返回

1.3 为什么需要服务降级

在高并发系统中：

资源永远是有限的。

例如：

数据库：1000 QPS,

实际请求：10000 QPS

如果不做降级：请求全部打到数据库-》系统崩溃

1.4 企业典型应用场景

场景1：商品详情页

正常： → 实时库存 + 价格 + 推荐

降级： → 缓存商品 + 默认库存

场景2：推荐系统

推荐服务挂了

→ 返回热门商品

场景3：搜索系统

ES不可用

高并发系统设计-隔离

Fri, 11 Jul 2025 20:46:01 +0800

高并发系统设计-隔离

一、概述

1.1 什么是隔离

隔离（Bulkhead）源自船舶结构设计：

船体被分割成多个“水密舱”，即使某一舱进水，也不会导致整船沉没。

在分布式系统中对应为：

将不同业务流量或依赖资源隔离开，避免相互影响。

例如：

订单服务
支付服务
库存服务
推荐服务

如果没有隔离：

推荐服务慢查询
→ 占满线程池
→ 订单无法处理
→ 系统崩溃

1.2 为什么需要隔离

在高并发系统中，最危险的不是“单点失败”，而是：

资源被某一个模块耗尽

典型问题：

1. 线程池被占满

慢接口占用所有 worker → 新请求无法处理

2. 连接池被耗尽

某服务频繁调用DB → 连接池100个全部占满

3.某服务拖垮整个系统

推荐服务异常 → 影响订单服务 → 影响支付服务 → 全系统不可用

1.3 隔离的核心目标

隔离的本质是：

限制资源共享范围，防止“一个坏点影响全局”

目标：

防止资源争抢
防止链式崩溃
提高系统稳定性
控制故障范围

1.4 典型场景

场景1：电商系统

订单 / 支付 / 推荐 / 搜索

要求：

推荐挂了不能影响下单
搜索挂了不能影响支付

场景2：微服务调用

Service A → B → C → D

如果 D 崩溃：

高并发系统设计-缓存保护

Fri, 11 Jul 2025 20:46:01 +0800

高并发系统设计-缓存保护

一、概述

1.1 什么是缓存保护

缓存保护（Cache Protection）是指：

通过一系列缓存设计策略，避免缓存异常导致数据库被大量请求直接访问，从而保证系统稳定性。

典型架构：

 Client
 │
 ▼
 Gateway
 │
 ▼
 Application
 │
 ┌─────────┴─────────┐
 │ │
 ▼ ▼
 Local Cache Redis Cache
 │
 Cache Miss？
 │
 ▼
 MySQL

1.2 为什么需要缓存保护

Redis 可以承受几十万甚至百万级 QPS，而 MySQL 通常只能支撑几千 QPS。

例如：

Redis

100000 QPS
↓
MySQL

3000 QPS

如果 Redis 出现问题：

100000 请求
↓
全部进入 MySQL
↓
数据库连接耗尽
↓
整个系统崩溃

缓存的首要目标是保护数据库，其次才是提升访问性能。

1.3 企业缓存架构

企业通常采用：

 Client
 │
 ▼
 Application
 │
 ▼
 Local Cache(Caffeine)
 │
 ▼
 Redis Cluster
 │
 ▼
 MySQL

同时配合：

高并发系统设计-熔断

Fri, 11 Jul 2025 20:46:01 +0800

高并发系统设计-熔断

一、概述

1.1 什么是熔断

熔断（Circuit Breaker）的核心思想来自电路保险丝：

当电流过大时，保险丝会断开，保护整个电路。

在分布式系统中：

服务A → 服务B → 服务C → 数据库

如果服务C异常：

超时
报错
响应缓慢

那么如果不做控制：

A 等 BB 等 CC 卡住→ 线程全部阻塞→ 请求堆积→ 系统雪崩

熔断的作用就是：

当下游服务异常时，直接停止调用它，快速失败。

1.2 为什么需要熔断

在高并发系统中，最危险的问题不是“服务失败”，而是：

失败被放大并传播

例如：

数据库慢查询
 ↓
所有请求阻塞
 ↓
连接池耗尽
 ↓
Redis压力上升
 ↓
Gateway超时
 ↓
全链路崩溃

这就是：

级联故障（Cascade Failure）

1.3 熔断解决的问题

熔断解决三类问题：

1. 防止线程阻塞

避免请求一直等待下游：

请求 → 卡住 → 不释放资源

2.防止错误放大

错误不会扩散到上游系统：

错误服务 → 不再调用

1.4 企业典型场景

场景1：支付服务异常

订单服务 → 支付服务（异常）

不熔断：
→ 一直等待
→ 订单线程堆积

熔断后：
→ 直接返回“支付处理中”

场景2：库存服务不可用

库存服务挂了

熔断：
→ 不再调用库存
→ 返回“库存未知”

场景3：第三方接口超时

例如：

高并发系统设计-限流

Fri, 11 Jul 2025 20:46:01 +0800

高并发系统设计-限流

一、什么是限流

限流（Rate Limiting）是指限制单位时间内允许进入系统的请求数量。

简单来说，就是：

控制流量进入系统的速度，而不是等系统崩溃之后再处理。

例如：

某接口限制：1000 Request / Second

如果一秒钟来了：1500 Request

那么：1000正常处理，500拒绝访问

通常返回：HTTP 429 Too Many Requests

限流的本质就是：

宁可拒绝一部分请求，也不要让整个系统崩溃。

二、为什么需要限流

因为系统资源是有限的。

例如：

服务器配置：

CPU：8 Core
Memory：16GB
MySQL连接池：100
Redis连接池：200

这些资源都存在上限。

假设数据库最大只能处理： 5000 QPS

如果突然来了：30000 QPS

没有限流：30000全部访问MySQL->连接池耗尽->CPU100%->慢SQL->超时->…->系统崩溃

有了限流：30000->Gateway->允许5000->25000直接拒绝->系统稳定

虽然部分用户会收到"系统繁忙"的提示，但系统整体仍然保持可用。

这正是限流存在的意义

三、典型应用场景

限流几乎存在于所有互联网系统中。

1、登录接口

例如：POST /login

限制：每个IP 5次/分钟

防止：

暴力破解密码
恶意攻击
短时间大量登录

2、短信验证码

3、支付接口

4、秒杀系统

5、开放API

四、限流的位置

限流通常不是只有一层。

一般有四层。

第一层：CDN

例如： Cloudflare->限制恶意流量

主要抵御：

CC攻击
DDoS
Bot

第二层：Nginx / Gateway

例如： Client->Gateway->Application

nginx示例

高并发系统设计-重试

Fri, 11 Jul 2025 20:46:01 +0800

高并发系统设计-重试

一、概述

1.1 什么是重试

重试（Retry）是指：

当一次请求失败后，在满足条件的情况下再次发起请求，以提高成功率。

例如：

请求 → 失败 → 再请求 → 成功

1.2 为什么需要重试

在分布式系统中，失败是常态：

网络抖动
RPC短暂超时
Redis瞬时不可用
MySQL连接波动
依赖服务重启

例如：

请求支付服务 → 超时

但实际服务是正常的

如果不重试：用户支付失败

但如果允许重试：

第一次失败

第二次成功

1.3 重试解决的问题

重试主要解决：

1. 短暂故障

如：网络抖动服务瞬断连接超时

2.依赖服务不稳定

如：

第三方支付 / 短信 / API

3.提高成功率

1.4 重试的误区

错误做法：失败 → 立即重试 → 再失败 → 无限循环

正确做法是：可控重试 + 退避策略 + 最大次数限制

二、原理

2.1 重试的核心思想

重试本质是：

用时间换成功率

但前提是：

不能无限重试
不能立即重试
不能对所有错误重试

2.2 哪些情况可以重试

网络超时
连接失败
503 / 502
RPC短暂异常

不可重试

高并发系统稳定性设计

Fri, 11 Jul 2025 20:46:01 +0800

高并发系统稳定性设计

本文适用于 Web 应用、API 服务、微服务、分布式系统等高并发场景，重点介绍现代企业级系统如何通过限流、熔断、降级、重试、超时、隔离和缓存等技术保障系统的稳定运行。

一、什么是高并发

1.1 高并发的定义

高并发（High Concurrency）是指系统在单位时间内需要同时处理大量用户请求的能力。

例如：

电商平台双十一抢购
秒杀活动
支付系统
社交平台热点事件
游戏服务器
视频直播
AI 大模型接口

假设一个用户访问商品详情页面，请求流程如下：

Client
 │
 ▼
Nginx
 │
 ▼
PHP
 │
 ├── Redis
 ├── MySQL
 └── Elasticsearch

一个用户访问几乎不会产生压力。

但是如果同时有10000个用户->10000 HTTP Requests->Application

系统就需要在极短时间内完成：

HTTP 请求解析
身份认证
参数校验
Redis 查询
数据库访问
JSON 序列化
网络返回

如果系统设计不合理，就可能出现响应变慢、超时甚至崩溃。

1.2 高并发 ≠ 高性能

高性能（Performance）

高性能关注的是 单个请求处理速度。

例如：

接口耗时：50 ms

优化 SQL 后：20 ms

这属于性能优化。

常见优化包括：

SQL 优化
Redis 缓存
JVM / PHP Runtime 优化
协程
对象池
连接池

高并发（Concurrency）

高并发关注的是： 系统能够同时处理多少请求。

分布式锁详解

Wed, 11 Jun 2025 20:46:01 +0800

分布式锁详解

在高并发和分布式系统中，为保证资源的一致性和互斥访问，分布式锁是必不可少的技术手段。本文将系统地讲解分布式锁的概念、场景、实现原理、使用方式，并附 PHP 示例。

1. 什么是分布式锁

定义：

分布式锁（Distributed Lock）是用于在多台机器或多个服务实例中控制共享资源访问的机制。它保证在同一时间，只有一个客户端可以操作某个资源，从而避免并发冲突。

特点：

互斥性：同一时间只有一个客户端持有锁。
可重入性（可选）：同一客户端可以重复获取锁。
可靠性：锁过期或客户端异常可自动释放，避免死锁。
可扩展性：适用于分布式系统和微服务架构。

2. 分布式锁的应用场景

分布式锁在企业场景非常常见，典型使用场景包括：

库存扣减
- 秒杀或抢购场景，防止库存超卖。
订单号生成
- 保证全局唯一订单号。
任务调度
- 多实例系统中，保证任务只被单实例执行。
缓存更新
- 防止缓存击穿时，多实例同时重建缓存。
支付或转账操作
- 防止重复扣款或资金异常。

3. 分布式锁的实现原理

3.1 数据库锁

原理：
- 利用数据库唯一索引或事务机制创建锁记录。
示例：
```
1INSERT INTO locks(name, create_time) VALUES('order_123', NOW());
2-- 成功表示获得锁，失败表示锁已被占用
```
优缺点：
- 优点：简单易用，直接使用现有数据库。
- 缺点：高并发性能较差，数据库可能成为瓶颈。

3.2 Redis 锁

原理：
- 利用 Redis 的 SETNX 或 SET key value NX PX 原子操作。
- 设置锁过期时间，防止死锁。
- (RedLock红锁可以解决在 Redis 主从复制或哨兵模式下，使用单实例 Redis 锁可能遇到的锁失效问题。)
释放锁：
- 需要验证当前客户端持有锁，防止误删他人锁。
优点：

高并发技术体系

Sat, 10 May 2025 20:46:01 +0800

高并发技术体系概要

主要为基础理论知识

第一部分：高并发保护机制

限流熔断降级重试隔离缓存保护超时

第二部分：并发模型

线程模型协程模型事件驱动模型 Reactor模型

第三部分：资源池化

连接池线程池协程池对象池

第四部分：异步架构

MQ 事件驱动削峰填谷异步任务

第五部分：微服务治理

注册中心服务发现配置中心负载均衡服务调用 API Gateway 链路追踪服务监控日志系统

关于分布式

Tue, 11 Jun 2024 20:46:01 +0800

关于分布式

一、什么是分布式？

一个系统，各组件分别部署在不同服务器。彼此通过网络通信和协调的系统。

可以指多个不同组件分布在网络上互相协作
也可以一个组件的多个副本组成集群，互相协作如同一个组件，比如数据存储服务中心为了数据不丢失而采取的多个服务备份冗余
分布式最早出现的目的首先是解决单点问题，避免单点故障，然后解决了性能问题

二、分布式和微服务的区别？

微服务并不一定是分布式系统（微服务中多个服务不一定部署在不同服务器，单机部署情况则不算是分布式）
分布式一定不是微服务（分布式祖耀侧重服务的部署方式，微服务则是针对应用的一种服务拆分的架构）

三、分布式CAP原则

在设计一个分布式项目的时候会遇到三个特性：

一致性（Consistency）：所有节点数据实时同步，读取始终返回最新值
可用性（Availability）：每个请求必须得到响应（无论数据是否最新），高可用
分区容错（Partition Tolerance）：分布式最基本也是必需要有的特性，系统在遇到某个节点或网络分区故障时，仍然能够对外提供服务

三者无法同时满足，最多只能实现其中两个，网络分区发生时，必须牺牲C或A

‌CP（牺牲可用性）‌：如ZooKeeper，确保数据强一致性但可能拒绝请求
‌AP（牺牲一致性）‌：如Eureka，保证服务可用但允许数据短暂不一致

三、 BASE理论

BASE理论是分布式系统设计原则，BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。

1. 基本可用（Basically Available）：分布式系统，在出现故障的时候，允许损失部分可用性。类似服务降级
1. 软状态（Soft State）：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。
1. 最终一致性（Eventual Consistency）：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

四、分布式事务及解决方案

分布式事务

本地事务依赖数据库本身提供的事务特性来实现，但是在分布式环境下，可能会出现需要远程调用，比如：

1begin transaction；
2 //1.本地数据库操作：张三减少金额
3 //2.远程调用：让李四增加金额
4commit transation;

张三和李四的账户不在一个数据库中甚至不在一个应用系统里，实现转账事务需要通过远程调用，由于网络问题就会导致分布式事务问题。

分布式事务解决方案

2PC

2PC 即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2 是指两个阶段，P 是指准备阶段，C 是指提交阶段。偏向数据库
TCC TCC 是 Try、Conﬁrm、Cancel 三个词语的缩写，TCC 要求每个分支事务实现三个操作：预处理 Try、确认 Conﬁrm、撤销 Cancel。Try 操作做业务检查及资源预留，Conﬁrm 做业务确认操作，Cancel 实现一个与 Try 相反的操作即回滚操作。TM 首先发起所有的分支事务的 Try 操作，任何一个分支事务的Try操作执行失败，TM 将会发起所有分支事务的 Cancel 操作，若 Try 操作全部成功，TM 将会发起所有分支事务的 Conﬁrm 操作，其中 Conﬁrm/Cancel 操作若执行失败，TM 会进行重试。偏向代码

Kong API网关

Tue, 01 Aug 2023 11:46:01 +0800

Kong API网关

API网关特点

集合多个API，统一API入口
避免内部信息泄露
提供安全认证
支持混合通讯协议
降低微服务复杂度

常用的API网关有：NGINX，Zuul，Kong

Kong 介绍

kong是微服务中的一个网关组件，具有高可用和可扩展性，能提供易于使用的restful api来操作和配置API管理系统，同时它也可以通过负载均衡的功能把请求均匀的分发到各个服务器上，应对大量的请求。基于Nginx和OpenResty，是一个具有分布式、高性能、高并发、可伸缩…亚毫秒级延迟等特性和功能的微服务抽象层。

konga 是kong的UI界面

多用户管理
管理多个kong节点
使用快照备份，还原和迁移Kong节点
使用运行状态检查监控节点和API状态
数据库集成postgresSQL

Kong 流程图

Kong 安装

Kong下载安装

Konga下载安装

API操作文档地址

示例:

负载均衡

# 添加负载均衡
curl -i -X POST \
 -H "Content-Type:application/x-www-form-urlencoded" \
 -d "name=demo-upstream" \
 'http://127.0.0.1:8001/upstreams'

#设置权重
curl -i -X POST \
 -H "Content-Type:application/x-www-form-urlencoded" \
 -d "target=127.0.0.1:8000" \
 -d "weight=100" \
 'http://127.0.0.1:8001/upstreams/demo-upstream/targets'

 curl -i -X POST \
 -H "Content-Type:application/x-www-form-urlencoded" \
 -d "target=127.0.0.1:8080" \
 -d "weight=500" \
 'http://127.0.0.1:8001/upstreams/demo-upstream/targets'

添加Service

# 添加负载均衡
curl -i -X POST \
 -H "Content-Type:application/x-www-form-urlencoded" \
 -d "name=demo-service" \
 -d "host=demo-upstream" \
 'http://127.0.0.1:8001/services'

添加路由

# 添加负载均衡
curl -i -X POST \
 -H "Content-Type:application/x-www-form-urlencoded" \
 -d "name=demo-service-route" \
 -d "paths[]=/abc" \
 'http://127.0.0.1:8001/services/demo-service/routes'

Plugins 为路由添加basic-auth

curl -i -X POST \
 -H "Content-Type:application/x-www-form-urlencoded" \
 -d "name=basic-auth" \
 -d "config.hide_credentials=true" \
 'http://127.0.0.1:8001/routes/demo-service-route/plugins'

## 添加成功后需要添加CONSUMERS在Plugins添加basic auth

Plugins 为services添加jwt

curl -i -X POST \
 -H "Content-Type:application/x-www-form-urlencoded" \
 -d "name=jwt" \
 -d "config.hide_credentials=true" \
 'http://127.0.0.1:8001/services/demo-service/plugins'

## 添加成功后需要CONSUMERS配置jwt

Plugins 为services添加oauth2

curl -i -X POST \
 -H "Content-Type:application/x-www-form-urlencoded" \
 -d "name=oauth2" \
 -d "config.enable_authorization_code=true" \
 -d "config.enable_client_credentials=true" \
 -d "config.token_expiration=7200" \
 'http://127.0.0.1:8001/services/demo-service/plugins'

## 添加成功后需要CONSUMERS在Plugins添加auth2
curl -i -X POST \
 -H "Content-Type:application/x-www-form-urlencoded" \
 -d "name=test" \
 -d "config.client_id=true" \
 -d "config.client_secret=true" \
 -d "config.token_expiration=7200" \
 'http://127.0.0.1:8001/consumers/test/oauth2'

 ## 替换下面的client_id和client_secret获取Token 
 curl -i -X POST \
 -H "Content-Type:application/x-www-form-urlencoded" \
 -d "grant_type=client_credentials" \
 -d "client_id=xxx" \
 -d "client_secret=xxx" \
 -d "config.token_expiration=7200" \
 'http://127.0.0.1:8443/abc/oauth2/token'

Plugins 为services添加限流

# 限制IP每分钟5次
curl -i -X POST \
 -H "Content-Type:application/x-www-form-urlencoded" \
 -d "name=rate-limiting" \
 -d "config.minute=5" \
 -d "config.limit_by=ip" \
 'http://127.0.0.1:8001/services/demo-service/plugins'

Plugins 为services添加黑白名单

# 限制127.0.0.1访问
curl -i -X POST \
 -H "Content-Type:application/x-www-form-urlencoded" \
 -d "name=ip-restriction" \
 -d "config.deny=127.0.0.1" \
 'http://127.0.0.1:8001/services/demo-service/plugins'

Konga

Tue, 01 Aug 2023 11:46:01 +0800

Konga

Konga的本质：Konga是一个图形化界面，它最终是通过调用你配置的 Kong Admin API 来修改Kong的配置的。

文档参考：遇到复杂场景时，最好的老师依然是Kong官方文档。

一、首次登录与初始化设置

访问Konga并注册：在浏览器中打开 http://<你的服务器IP>:1337。首次访问时，Konga会要求你注册一个管理员账户。填写用户名、邮箱和密码完成注册。
登录系统：注册成功后，Konga会自动跳转到登录页面，使用刚才注册的账号密码登录即可

二、连接Konga与Kong网关

进入连接设置：登录成功后，你应该会看到"CONNECTIONS"或"Connections"界面。如果没有，请在左侧菜单或顶部导航栏中找到并点击 “Connections”。
填写Kong Admin API信息：
- Connection name：为你这个Kong连接起个名字，比如"My-Kong"或"Production"。
- Kong Admin URL：这是你Kong网关的Admin API地址。非常重要！格式通常是 http://:8001
- 如果你的Kong容器和Konga容器在同一个Docker网络（如 kong-net）中，你可以使用Kong的容器名和内部端口，例如：http://kong:8001。
- 如果你希望通过宿主机IP访问，可能需要使用宿主机的IP和映射给Kong Admin API的端口（例如 http://localhost:8001 或 http://<宿主机IP>:8001）。
激活连接：信息填写完毕后，点击 “Active” 或 “Connect” 等按钮来激活并测试连接。如果一切正常，Konga会提示连接成功。

三、 Konga核心功能与使用介绍

连接成功后，你就可以使用Konga来管理Kong了。Konga的核心功能围绕以下几个概念展开，理解它们之间的关系很重要：

概念 (Concept)	作用 (Role)	类比 (Analogy)	配置要点 (Key Configuration)
Upstream	负载均衡组：代表一个虚拟主机名，用于对后端多个Target进行负载均衡。	球队的名称	Name：为Upstream命名（如 my-api-upstream）。
Target	具体目标：代表一个物理服务（IP+Port），是Upstream组内的一个具体后端实例。必须先创建Upstream，才能添加Target。	球队里的一个球员	Target：后端服务的IP或主机名及端口（如 192.168.1.100:8080）。Weight：权重，流量分配比例。
Service	服务抽象：是上游服务的抽象，可以直接指向一个具体的URL，也可以关联一个Upstream来实现负载均衡。	比赛的战术安排	Name：服务名称。Protocol：协议（HTTP/HTTPS）。Host：可填写具体URL或关联的Upstream名称。Port：端口。Path：路径（可选）。
Route	路由规则：定义客户端请求的匹配规则（如路径、域名），将匹配的请求路由到指定的Service。	根据球衣颜色决定把球传给谁	Paths：匹配的请求路径（如 /api）。Hosts：匹配的域名（可选）。Service：选择该路由要关联的Service。

四、创建服务 (Services) 和路由 (Routes)

这是最常用的功能，用于将外部请求转发到你的后端服务。

Consul注册中心

Thu, 01 Jun 2023 11:46:01 +0800

Consul注册中心

CAP原理

一致性（Consistency）所有节点在同一时间具有相同的数据
可用性（Availablility）保证每个请求不管或者失败都有响应
分区容错（Partition tolerance）系统中任意数据的丢失或失败不会影响系统的继续运作

Consul 介绍

方便部署
采用Raft算法实现，有服务发现，key/value存储，可以做配置中心使用。有健康检查，同事提供了web管理页面

Consul角色

-dev 开发环境下的启动命令，提供基本的服务
-client 客户端，无状态的，将http和dns请求转发到服务端集群
-server 服务端，保存配置信息，可以搭建高可用的集群

Consul 内部端口

端口	说明
TCP/8300	8300端口用于服务器节点。客户端通过该端口RPC协议调用服务端接口。
TCP/UDP/8301	8301端口用于单个数据中心所有节点之间的相互通信，即对LAN池信息的同步。它使得整个数据中心能够自动发现服务器地址，分布式检测节点故障，事件广播
TCP/UDP/8302	8302端口用于单个或多个数据中心之间的服务器节点的信息同步。即对WAN池信息的同步。它针对互联网的高延迟进行了优化，能够实现跨数据中心请求。
8500	8500端口基于HTTP协议，用于API接口或WEB UI访问。
8600	8600端口作为DNS服务器，它使得我们可以通过节点名查询节点的信息。

Consul 工作原理

Consul 安装

下载地址

或者docker安装

1docker run -d --name=consul -p 8500:8500 consul:1.15.4 agent -dev -client 0.0.0.0 -ui

安装完成后，命令行输入consul 检查 consul 是否可用

Consul支持web ui界面。UI可用于查看所有服务和节点，查看所有运行状况检查及其当前状态，以及读取和设置键/值数据。用户界面自动支持多数据中心。要设置自带的UI，请使用-ui参数启动Consul代理：

consul agent -ui

UI可以在与HTTP API相同的端口上的/ui路径中使用。默认情况下，这是http://localhost:8500/ui。

注册个服务

使用HTTP API 注册个服务，使用[接口API](https://www.consul.io/api/agent/service.html API)调用