高并发可靠服务架构

Sat, 30 May 2026 10:00:00 +0800

高并发可靠服务架构#

构建高并发、高可用的互联网服务时，架构设计不再只是"能跑起来"，而是要在海量请求、有限资源、复杂业务链路中，做到低延迟、高吞吐、可扩展、容错强。以下结合典型 BFF + 微服务 + 云原生基础设施架构，进行系统性拆解。

GMP与并发模型

Sat, 30 May 2026 10:00:00 +0800

GMP && 并发模型深度解析#

一、GMP 高效调度#

1. 核心概念#

组件	全称	说明
G (Goroutine)	轻量级线程	栈初始 2KB（可动态增长），包含程序计数器、栈指针、寄存器状态
M (Machine)	操作系统线程	对应 OS 线程，负责执行 G 的代码，包含 g0（调度栈）、curg（当前 G）、m0（主线程）
P (Processor)	逻辑处理器	数量由 `GOMAXPROCS` 决定，持有本地运行队列（LRQ，容量 256），负责调度决策和上下文切换

G 的状态：_Gidle、_Grunnable、_Grunning、_Gsyscall、_Gwaiting、_Gdead

请求与存储最优解

Sat, 30 May 2026 10:00:00 +0800

请求与存储最优实践#

一、关于请求方式#

1. POST vs PUT 特性对比#

特性	POST	PUT
语义	创建子资源，或提交数据供处理	替换整个目标资源（幂等）
幂等性	❌ 不保证幂等（多次请求可能创建多个资源）	✅ 幂等（多次请求结果相同）
URI	通常由服务器决定最终 URI（如 `/posts` → `/posts/123`）	客户端明确指定完整 URI（如 `/posts/123`）
常见用途	创建新资源、表单提交、部分更新（PATCH 之前常用）	全量更新已知资源、创建资源（若客户端指定 ID）

2. 示例对比#

操作	使用 POST	使用 PUT
创建新文章	✅ 常见做法	也可以（客户端需自己生成 ID，如 `/articles/uuid-123`）
全量更新文章 123	❌ 可以但不推荐（不幂等）	✅ 标准做法
提交表单（购物车、联系表单）	✅	❌
上传大文件并覆盖已有文件	❌（用 PUT）	✅

3. 误区与补充#

POST 也能更新：REST 没有禁止 POST 做更新，但 PUT/PATCH 更语义明确
部分更新：标准做法是用 PATCH，因为 PUT 要求全量替换（缺失字段会被删除）
PUT 创建资源：允许，但条件是客户端能提供唯一且最终不变的 URI
部分 API 实践时，只开放 POST + PATCH，忽略 PUT
幂等性对网络重试很重要（PUT 安全，POST 不安全）

快速判断#

需要客户端指定完整 URI + 幂等（可安全重试）+ 全量替换  →  PUT
URI 由服务器决定        + 可能改变状态/创建资源       →  POST
部分更新且幂等                                          →  PATCH

二、后端存储#

1. 核心原则#

原则	说明
数据安全优先	丢失比慢更致命
按需选择	没有万能存储，只有合适场景
分层存储	热/温/冷数据分离
不可变原则	能追加不修改，能软删不硬删
可观测性	慢查询、连接池、容量必须可监控

2. 数据库选型决策#

数据关系复杂？联查多？
├─ 是 → 关系型数据库（PostgreSQL / MySQL）
│        ├─ 强一致性 + 复杂事务 → PostgreSQL
│        └─ 读多写少 + 生态成熟 → MySQL

数据量大（TB级）？写入压力大？
├─ 是 → 分布式数据库
│        ├─ 强事务 + 水平扩展 → TiDB / CockroachDB
│        └─ 最终一致性 + 超高吞吐 → Cassandra / HBase

数据结构多变？无 schema？
├─ 是 → 文档数据库（MongoDB）
│        └─ 适合：日志、用户画像、CMS

需要全文搜索？
├─ 是 → Elasticsearch（配合主存储双写）

需要缓存 + 高性能？
├─ 是 → Redis
│        └─ 适合：会话、计数器、排行榜、分布式锁

需要图关系（社交、推荐）？
├─ 是 → 图数据库（Neo4j / Amazon Neptune）

时间序列数据（IoT、监控）？
├─ 是 → 时序数据库（InfluxDB / TimescaleDB / Prometheus）

3. 分层存储架构#

                    请求路径
                       │
                       ▼
┌──────────────────────────────────────────────────────┐
│                    L1: 缓存层                         │
│   Redis / Memcached                                   │
│   - TTL 5-15分钟                                       │
│   - 缓存穿透/击穿/雪崩防护                              │
└──────────────────────────────────────────────────────┘
                       │ 未命中
                       ▼
┌──────────────────────────────────────────────────────┐
│                    L2: 热存储                         │
│   PostgreSQL / MySQL（SSD，主从集群）                  │
│   - 最近 7-30 天数据                                   │
│   - 在线服务直接访问                                    │
└──────────────────────────────────────────────────────┘
                       │ 归档策略
                       ▼
┌──────────────────────────────────────────────────────┐
│                    L3: 温存储                         │
│   归档表 / 分区表 / 对象存储（OSS/S3）                  │
│   - 30 天 ~ 1 年数据                                   │
│   - 可离线分析                                          │
└──────────────────────────────────────────────────────┘
                       │ 长期保存
                       ▼
┌──────────────────────────────────────────────────────┐
│                    L4: 冷存储                         │
│   对象存储（Glacier Deep Archive）                     │
│   - 1 年以上数据                                       │
│   - 取回时间 12-48 小时                                │
└──────────────────────────────────────────────────────┘

4. 关系型最优实践#

表设计#

-- ✅ 推荐：软删除 + 审计字段
CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE,
    status SMALLINT DEFAULT 1,           -- 1:正常 2:禁用 3:已删
    created_at TIMESTAMPTZ DEFAULT NOW(),
    updated_at TIMESTAMPTZ DEFAULT NOW(),
    deleted_at TIMESTAMPTZ,              -- NULL = 未删除
    version INT DEFAULT 1                -- 乐观锁
);

-- ✅ 使用 UUID 作为业务 ID（防遍历/分库兼容）
-- ❌ 避免用自增 ID 暴露业务量

索引策略#

场景	建议
等值查询（`WHERE email = ?`）	B-Tree 索引
范围查询（`WHERE created_at > ?`）	B-Tree 索引 + 排序方向一致
模糊查询（`LIKE 'abc%'`）	普通索引（前置通配符 `%abc` 用不到索引）
全文搜索	倒排索引（PostgreSQL tsvector / Elasticsearch）
多条件排序	联合索引（覆盖排序字段）
JSON 字段查询	GIN 索引（PostgreSQL）

索引黄金法则：

深度剖析gRPC服务通信

Sat, 30 May 2026 10:00:00 +0800

深度剖析gRPC服务通信#

一、gRPC 核心架构解析#

1.1 设计哲学：契约优先#

gRPC 采用 Contract-First（契约优先） 的设计思想，先定义接口，再实现逻辑。这种思想的优势在于：

框架高性能实现分析实战

Sat, 30 May 2026 10:00:00 +0800

Gin框架高性能实现分析与实战#

Gin框架的高性能实现与底层原理：深入Radix Tree与sync.Pool#

Gin 是 Go 语言生态中最流行的 Web 框架之一，以其出色的性能和简洁的 API 而闻名。在众多 Go Web 框架中，Gin 始终在性能基准测试中名列前茅。

OpenSource

Sat, 30 May 2026 10:00:00 +0800

OpenSource#

Weave 开源架构实践#

Weave feat/aichat_service 分支中引入对聋哑人等残障人士的对话显示支持，支持将文字、语音内容转换为手语，便利残障人士的使用
未来，我们将持续开源、迭代优化

技术民主化的理想与现实#

在技术领域，“开源"早已不是一个陌生的词汇。从Linux内核到应用研发生态系统，从TensorFlow到VS Code，开源软件构筑了现代数字世界的基石。但开源仅仅是一种软件开发模式，还是承载着更深层的社会意义？在此探讨一个可能被低估的视角：开源运动与平权理念之间的内在联系。

R&D&Architecture

高并发可靠服务架构