全面解析 CI/CD 流水线设计,涵盖 Jenkins、GitLab CI、GitHub Actions 等平台,包含完整配置示例、最佳实践和实战案例
Python 自动化脚本集锦
精选 20 个实用 Python 自动化脚本,涵盖文件处理、数据分析、网络请求、系统运维、Web scraping 等场景,所有代码可直接运行
Nginx 配置最佳实践:从入门到精通
Nginx 配置最佳实践:从入门到精通
本文全面讲解 Nginx 的配置语法、常用场景、性能优化和安全加固,帮助运维和开发人员构建高性能、高可用的 Web 服务。
一、Nginx 基础架构
1.1 Nginx 工作原理
1 | graph TB |
核心概念:
- Master 进程:管理 Worker 进程,处理配置加载、日志打开等
- Worker 进程:处理实际请求,多进程模型
- 事件驱动:非阻塞 I/O,高并发性能
- 连接复用:Keepalive 减少连接开销
1.2 安装 Nginx
1 | # Ubuntu/Debian |
1.3 目录结构
1 | # Nginx 目录结构 |
二、配置文件详解
2.1 nginx.conf 结构
1 | # 主配置文件结构 |
2.2 核心指令详解
worker_processes
1 | # 设置 Worker 进程数 |
worker_connections
1 | events { |
keepalive_timeout
1 | http { |
三、常用场景配置
3.1 静态文件服务器
1 | server { |
3.2 反向代理
1 | server { |
3.3 负载均衡
1 | # 上游服务器组 |
3.4 HTTPS 配置
1 | server { |
3.5 动静分离
1 | upstream backend { |
四、性能优化
4.1 基础优化
1 | # nginx.conf |
4.2 缓存优化
1 | # 代理缓存配置 |
4.3 连接优化
1 | http { |
4.4 FastCGI 优化(PHP)
1 | server { |
五、安全加固
5.1 基础安全配置
1 | server { |
5.2 DDoS 防护
1 | http { |
5.3 SSL/TLS 安全
1 | server { |
5.4 访问控制
1 | server { |
六、监控与日志
6.1 日志配置
1 | http { |
6.2 日志分析
1 | # 查看访问日志 |
6.3 状态监控
1 | # 启用状态模块 |
6.4 Prometheus 监控
1 | # 使用 nginx-prometheus-exporter |
七、故障排查
7.1 常见问题
1 | # 测试配置 |
7.2 错误码排查
| 错误码 | 含义 | 常见原因 | 解决方案 |
|---|---|---|---|
| 400 | 错误请求 | 请求格式错误 | 检查客户端请求 |
| 403 | 禁止访问 | 权限不足 | 检查文件权限、IP 限制 |
| 404 | 未找到 | 文件不存在 | 检查路径、root 配置 |
| 405 | 方法不允许 | HTTP 方法错误 | 检查允许的请求方法 |
| 413 | 请求体过大 | 超过限制 | 调整 client_max_body_size |
| 414 | URI 过长 | URL 太长 | 调整 large_client_header_buffers |
| 499 | 客户端关闭 | 客户端超时 | 优化后端响应时间 |
| 500 | 服务器错误 | 配置错误 | 检查 error.log |
| 502 | 错误网关 | 后端服务异常 | 检查后端服务状态 |
| 503 | 服务不可用 | 后端过载 | 检查后端负载 |
| 504 | 网关超时 | 后端响应超时 | 增加 proxy_read_timeout |
7.3 调试技巧
1 | # 增加日志详细程度 |
八、总结
Nginx 配置的关键要点:
- 基础配置:worker_processes、worker_connections、keepalive
- 常用场景:静态文件、反向代理、负载均衡、HTTPS
- 性能优化:缓存、压缩、连接优化
- 安全加固:隐藏版本、安全头、访问控制、DDoS 防护
- 监控日志:日志格式、状态监控、故障排查
记住:配置要简洁,优化要适度,安全要优先。
参考资料:
- Nginx 官方文档
- Nginx 配置最佳实践
- Mozilla SSL 配置生成器
- 《Nginx 权威指南》
微服务架构设计模式:从理论到实践
微服务架构设计模式:从理论到实践
本文系统讲解微服务架构的核心设计模式,包括服务拆分、通信、数据管理、容错等关键领域,帮助架构师构建可扩展、高可用的分布式系统。
一、微服务架构概述
1.1 什么是微服务?
微服务架构是一种将单一应用程序开发为一组小型服务的方法,每个服务:
- 运行在独立的进程中
- 通过轻量级机制(通常是 HTTP)通信
- 围绕业务能力构建
- 可独立部署和扩展
- 使用不同的技术栈
1.2 单体 vs 微服务
1 | graph TB |
| 维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 开发效率 | 高(本地调试) | 中(需要服务协调) |
| 部署复杂度 | 低(一次部署) | 高(多次部署) |
| 可扩展性 | 低(整体扩展) | 高(按需扩展) |
| 技术多样性 | 低(统一技术栈) | 高(各服务独立) |
| 故障隔离 | 低(单点故障) | 高(服务隔离) |
| 数据一致性 | 高(本地事务) | 低(分布式事务) |
1.3 何时使用微服务?
适合场景:
- 团队规模大(>10 人)
- 业务复杂度高
- 需要快速迭代
- 不同模块有不同扩展需求
- 需要技术多样性
不适合场景:
- 初创项目(快速验证)
- 团队规模小
- 业务逻辑简单
- 对一致性要求极高
二、服务拆分模式
2.1 基于业务能力拆分
按业务领域划分服务边界:
1 | graph LR |
拆分原则:
- 高内聚:相关功能放在一起
- 低耦合:服务间依赖最小化
- 单一职责:每个服务做好一件事
- 自治性:服务可独立运行
2.2 基于子域拆分(DDD)
1 | // 领域驱动设计示例 |
2.3 拆分陷阱与避免
陷阱 1:分布式单体
1 | graph TB |
问题:服务间紧密耦合,一个服务故障导致级联故障。
解决方案:
- 引入异步通信
- 添加熔断器
- 设计容错机制
陷阱 2:过度拆分
1 | ❌ 错误示例: |
三、服务通信模式
3.1 同步通信(REST/gRPC)
REST API 设计
1 | // RESTful API 示例 |
gRPC 高性能通信
1 | // order.proto |
1 | // gRPC 服务实现 |
REST vs gRPC 对比:
| 特性 | REST | gRPC |
|---|---|---|
| 协议 | HTTP/1.1 | HTTP/2 |
| 数据格式 | JSON | Protobuf |
| 性能 | 中 | 高(2-10 倍) |
| 浏览器支持 | 好 | 需要代理 |
| 生态成熟度 | 高 | 中 |
| 适用场景 | 对外 API | 内部服务通信 |
3.2 异步通信(消息队列)
事件驱动架构
1 | sequenceDiagram |
1 | // 事件发布 |
3.3 API Gateway 模式
1 | graph TB |
Spring Cloud Gateway 配置:
1 | spring: |
四、数据管理模式
4.1 数据库按服务拆分
1 | graph TB |
原则:
- 每个服务独享数据库
- 禁止跨库 JOIN
- 通过 API 或事件访问其他服务数据
4.2 CQRS(命令查询职责分离)
1 | graph TB |
1 | // 命令端 |
4.3 事件溯源(Event Sourcing)
1 | // 事件存储 |
4.4 Saga 分布式事务
1 | sequenceDiagram |
1 | // Saga 实现 |
五、容错与弹性模式
5.1 熔断器(Circuit Breaker)
1 | graph LR |
1 | // Resilience4j 配置 |
5.2 超时与重试
1 | // 超时配置 |
5.3 限流(Rate Limiting)
1 | // 令牌桶限流 |
5.4 舱壁模式(Bulkhead)
1 | // 线程池隔离 |
六、实战案例
案例 1:电商平台微服务架构
系统架构:
1 | graph TB |
服务依赖关系:
1 | // 订单服务 - 依赖其他服务 |
案例 2:服务迁移策略
从单体到微服务的演进:
1 | graph LR |
迁移步骤:
- 识别边界:分析代码库,识别业务边界
- 提取模块:将模块拆分为独立项目
- 数据拆分:按服务拆分数据库
- 服务化:实现服务间通信
- 独立部署:建立 CI/CD 流水线
1 | // 绞杀者模式 - 逐步替换 |
七、监控与可观测性
7.1 分布式链路追踪
1 | # SkyWalking 配置 |
7.2 指标监控
1 | // Prometheus 指标 |
7.3 日志聚合
1 | # ELK Stack 配置 |
八、总结
微服务架构设计的关键要点:
- 合理拆分:基于业务能力或 DDD 子域,避免过度拆分
- 通信选择:同步(REST/gRPC)+ 异步(消息队列)
- 数据管理:数据库按服务拆分,使用 CQRS/事件溯源
- 容错设计:熔断、重试、限流、舱壁
- 可观测性:链路追踪、指标监控、日志聚合
微服务不是银弹,需要权衡复杂度和收益。记住:合适的架构才是最好的架构。
参考资料:
- 《微服务架构设计模式》Chris Richardson
- 《领域驱动设计》Eric Evans
- Microservices.io
- Spring Cloud 官方文档
Docker 容器化最佳实践
全面解析 Docker 容器化的最佳实践,涵盖镜像构建优化、Dockerfile 编写、多阶段构建、安全加固、网络存储、编排部署等核心主题,包含 3 个架构图和 2 个实战案例
Linux 性能排查指南:从入门到精通
Linux 性能排查指南:从入门到精通
本文系统讲解 Linux 系统性能排查的方法论、工具链和实战技巧,帮助运维和开发人员快速定位和解决性能问题。
一、性能排查方法论
1.1 USE 方法
USE(Utilization, Saturation, Errors) 是 Brendan Gregg 提出的性能分析方法:
1 | graph TB |
检查清单:
| 资源 | 利用率 | 饱和度 | 错误 |
|---|---|---|---|
| CPU | % 使用率 | 运行队列长度 | 硬件错误 |
| 内存 | % 使用率 | Swap 使用 | OOM 错误 |
| 磁盘 | % 容量 | IO 等待时间 | IO 错误 |
| 网络 | 带宽使用 | 丢包/重传 | 连接错误 |
1.2 性能分析步骤
1 | graph LR |
标准流程:
- 发现问题:监控告警、用户反馈、日志异常
- 收集指标:使用工具收集系统指标
- 定位瓶颈:分析指标,找出瓶颈资源
- 分析原因:深入分析瓶颈原因
- 制定方案:设计优化方案
- 验证效果:实施后验证效果
1.3 性能指标阈值
| 指标 | 正常 | 警告 | 严重 |
|---|---|---|---|
| CPU 使用率 | < 70% | 70-85% | > 85% |
| 内存使用率 | < 80% | 80-90% | > 90% |
| Swap 使用率 | 0% | < 50% | > 50% |
| 磁盘使用率 | < 80% | 80-90% | > 90% |
| IO 等待 | < 10% | 10-30% | > 30% |
| 负载平均值 | < CPU 核数 | 1-2 倍 | > 2 倍 |
| 网络丢包 | 0% | < 0.1% | > 0.1% |
二、CPU 性能排查
2.1 CPU 指标解读
1 | # 查看 CPU 信息 |
负载平均值含义:
1 | 负载 0.00:系统空闲 |
2.2 CPU 排查工具
top 命令
1 | # 基本使用 |
top 输出解读:
1 | top - 14:30:00 up 10 days, 2:30, 1 user, load average: 0.50, 0.80, 0.90 |
字段说明:
us(user): 用户空间 CPU 使用率sy(system): 内核空间 CPU 使用率ni(nice): 低优先级进程 CPU 使用率id(idle): 空闲 CPU 使用率wa(iowait): IO 等待 CPU 使用率hi(hardware interrupts): 硬件中断si(software interrupts): 软件中断st(steal): 虚拟机被偷取的时间
htop 命令
1 | # 安装 htop |
vmstat 命令
1 | # 每秒采样一次,共 5 次 |
vmstat 输出解读:
1 | procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- |
pidstat 命令
1 | # 安装 pidstat |
2.3 CPU 问题诊断
场景 1:CPU 使用率高
1 | # 1. 查看整体 CPU 使用率 |
场景 2:负载高但 CPU 使用率低
1 | # 可能是 IO 等待导致 |
场景 3:上下文切换频繁
1 | # 查看上下文切换次数 |
2.4 CPU 优化方案
1 | # 调整进程优先级 |
三、内存性能排查
3.1 内存指标解读
1 | # 查看内存使用情况 |
free 命令输出解读:
1 | total used free shared buff/cache available |
3.2 内存排查工具
/proc/meminfo 详解
1 | # 查看关键内存指标 |
slabtop 命令
1 | # 查看内核 slab 缓存 |
smem 命令
1 | # 安装 smem |
3.3 内存问题诊断
场景 1:内存使用率高
1 | # 1. 查看整体内存使用 |
场景 2:Swap 使用率高
1 | # 1. 查看 Swap 使用 |
场景 3:OOM Killer
1 | # 1. 查看 OOM 日志 |
3.4 内存优化方案
1 | # 调整 swappiness(默认 60) |
四、磁盘 IO 性能排查
4.1 磁盘 IO 指标解读
1 | # 查看磁盘使用情况 |
iostat 输出解读
1 | avg-cpu: %user %nice %system %iowait %steal %idle |
4.2 磁盘 IO 排查工具
iotop 命令
1 | # 安装 iotop |
pidstat IO 统计
1 | # 查看进程的 IO |
ioping 命令
1 | # 安装 ioping |
4.3 磁盘 IO 问题诊断
场景 1:IO 等待高
1 | # 1. 查看 IO 等待 |
场景 2:磁盘空间不足
1 | # 1. 查看磁盘使用 |
场景 3:Inodes 耗尽
1 | # 1. 查看 Inodes 使用 |
4.4 磁盘 IO 优化方案
1 | # 调整 IO 调度算法 |
五、网络性能排查
5.1 网络指标解读
1 | # 查看网络接口 |
/proc/net/dev 解读
1 | cat /proc/net/dev |
5.2 网络排查工具
ss 命令
1 | # 查看所有连接 |
netstat 命令
1 | # 查看所有连接 |
tcpdump 命令
1 | # 抓包(所有接口) |
ping 命令
1 | # 基本 ping |
traceroute 命令
1 | # 追踪路由 |
5.3 网络问题诊断
场景 1:网络连接失败
1 | # 1. 检查网络接口 |
场景 2:网络延迟高
1 | # 1. 测试延迟 |
场景 3:连接数过多
1 | # 1. 查看连接数统计 |
5.4 网络优化方案
1 | # 调整 TCP 参数 |
六、综合排查案例
案例 1:Web 服务器响应慢
问题现象: 用户反馈网站访问慢,页面加载时间长。
排查步骤:
1 | # 1. 检查系统负载 |
案例 2:数据库查询慢
问题现象: 数据库查询响应时间长,应用超时。
排查步骤:
1 | # 1. 检查系统资源 |
案例 3:内存泄漏
问题现象: 服务器运行一段时间后内存耗尽,服务崩溃。
排查步骤:
1 | # 1. 监控内存使用 |
七、监控工具推荐
7.1 系统监控
| 工具 | 用途 | 特点 |
|---|---|---|
| top/htop | 实时监控 | 简单直观 |
| vmstat | 系统统计 | 轻量级 |
| sar | 历史统计 | 数据持久化 |
| dstat | 综合监控 | 功能全面 |
| glances | Web 界面 | 易于使用 |
7.2 应用监控
| 工具 | 用途 | 特点 |
|---|---|---|
| Prometheus | 指标监控 | 云原生标准 |
| Grafana | 可视化 | 丰富的图表 |
| ELK Stack | 日志分析 | 强大的搜索 |
| SkyWalking | 链路追踪 | APM 功能 |
| Zabbix | 企业监控 | 功能全面 |
7.3 快速部署监控栈
1 | # docker-compose.yml |
八、总结
Linux 性能排查的关键要点:
- 方法论:USE 方法,从利用率、饱和度、错误三个维度分析
- 工具链:top/vmstat/iostat/ss 等工具的组合使用
- 指标解读:理解每个指标的含义和阈值
- 优化方案:根据瓶颈制定针对性的优化方案
记住:监控是基础,排查是技能,优化是目标。
参考资料:
- Brendan Gregg 的性能博客
- 《Linux 性能优化实战》
- USE 方法
- Linux 性能工具速查
Git 常用命令速查:从入门到精通
Git 常用命令速查:从入门到精通
本文整理了 Git 开发中最常用的命令和技巧,涵盖基础操作、分支管理、远程协作、问题排查等场景,是开发者的速查手册。
一、Git 基础配置
1.1 用户信息配置
1 | # 全局配置(所有仓库) |
1.2 SSH 密钥配置
1 | # 生成 SSH 密钥 |
1.3 常用 Git 配置优化
1 | # 自动修正命令 |
二、仓库操作
2.1 创建仓库
1 | # 初始化新仓库 |
2.2 查看状态
1 | # 查看仓库状态 |
2.3 差异比较
1 | # 工作区 vs 暂存区 |
三、文件操作
3.1 添加文件
1 | # 添加指定文件 |
3.2 忽略文件
1 | # 创建 .gitignore 文件 |
3.3 删除文件
1 | # 删除文件(工作区和暂存区) |
3.4 移动/重命名文件
1 | # 重命名文件 |
四、提交操作
4.1 基本提交
1 | # 提交暂存区 |
4.2 提交规范
1 | # Conventional Commits 格式 |
4.3 撤销提交
1 | # 撤销工作区修改 |
4.4 查看提交历史
1 | # 简洁的提交历史 |
五、分支管理
5.1 分支基础操作
1 | # 查看分支 |
5.2 分支合并
1 | # 合并分支到当前分支 |
5.3 分支变基(Rebase)
1 | # 变基操作 |
5.4 分支管理最佳实践
1 | # 查看已合并的分支 |
六、远程协作
6.1 远程仓库操作
1 | # 查看远程仓库 |
6.2 拉取和推送
1 | # 拉取远程分支 |
6.3 标签管理
1 | # 查看标签 |
6.4 Git Flow 工作流
1 | # 初始化 Git Flow |
七、高级技巧
7.1 暂存(Stash)
1 | # 暂存当前修改 |
7.2 樱桃拣选(Cherry-pick)
1 | # 拣选单个提交 |
7.3 二分查找(Bisect)
1 | # 开始二分查找 |
7.4 子模块(Submodule)
1 | # 添加子模块 |
7.5 Git Hooks
1 | # Git Hooks 目录 |
八、问题排查
8.1 查看修改历史
1 | # 谁修改了某行代码 |
8.2 恢复丢失的提交
1 | # 查看 reflog |
8.3 解决常见问题
1 | # 问题:提交信息写错 |
8.4 性能优化
1 | # 清理不必要的文件 |
九、实用脚本
9.1 日常开发脚本
1 | # 快速创建功能分支 |
9.2 Git 配置模板
1 | # .gitconfig 模板 |
十、总结
Git 是开发者必备的工具,掌握常用命令可以大幅提升开发效率。关键要点:
- 基础操作:add、commit、push、pull
- 分支管理:branch、checkout、merge、rebase
- 问题排查:log、diff、blame、reflog
- 高级技巧:stash、cherry-pick、bisect
建议将常用命令配置为别名,并建立适合自己的工作流。
参考资料:
MySQL 备份恢复方案
全面解析 MySQL 备份恢复方案,涵盖逻辑备份、物理备份、增量备份、PITR 恢复、主从复制、自动化脚本等核心内容,包含详细步骤和可运行代码
消息队列选型与应用:RabbitMQ、Kafka、RocketMQ 全面对比
消息队列选型与应用:RabbitMQ、Kafka、RocketMQ 全面对比
本文深入分析主流消息队列的技术特点、适用场景和选型策略,结合实际案例讲解消息队列在解耦、异步、削峰等场景的最佳实践。
一、为什么需要消息队列?
1.1 核心应用场景
1 | graph TB |
1.2 场景详解
场景 1:系统解耦
问题:订单系统直接调用库存、物流、通知系统,耦合严重。
1 | graph TB |
改造前代码:
1 | // 订单服务 - 强耦合 |
改造后代码:
1 | // 订单服务 - 解耦 |
收益:
- 订单系统响应时间从 500ms 降至 50ms
- 库存/物流系统故障不影响订单创建
- 新增服务(如数据分析)无需修改订单系统
场景 2:异步处理
1 | // 用户注册 - 同步处理(慢) |
场景 3:削峰填谷
1 | graph LR |
秒杀场景:
1 | // 秒杀请求 - 削峰处理 |
二、主流消息队列对比
2.1 产品概览
| 特性 | RabbitMQ | Kafka | RocketMQ | ActiveMQ |
|---|---|---|---|---|
| 开发语言 | Erlang | Scala/Java | Java | Java |
| 发布年份 | 2007 | 2011 | 2012 | 2004 |
| 所属组织 | VMware | Apache | Apache | Apache |
| 协议支持 | AMQP | 自定义 | 自定义 | JMS |
| 消息模型 | 队列 | Topic | Topic/队列 | 队列 |
| 持久化 | 内存/磁盘 | 磁盘 | 磁盘 | 磁盘 |
| 吞吐量 | 万级 | 十万级 | 十万级 | 万级 |
| 延迟 | 微秒级 | 毫秒级 | 毫秒级 | 毫秒级 |
| 可靠性 | 高 | 中 | 高 | 高 |
| 社区活跃度 | 高 | 极高 | 高 | 中 |
2.2 架构对比
RabbitMQ 架构
1 | graph TB |
核心概念:
- Producer:消息生产者
- Exchange:消息交换机(Direct/Fanout/Topic/Headers)
- Queue:消息队列
- Consumer:消息消费者
- Binding:Exchange 和 Queue 的绑定关系
Kafka 架构
1 | graph TB |
核心概念:
- Topic:消息主题
- Partition:主题分区(物理存储单元)
- Broker:Kafka 服务器节点
- Consumer Group:消费者组
- Offset:消息偏移量
- Zookeeper:元数据管理
RocketMQ 架构
1 | graph TB |
核心概念:
- NameServer:无状态协调节点
- Broker:消息存储和转发
- Topic:消息主题
- Queue:队列(分区)
- Consumer Group:消费者组
- Producer Group:生产者组
2.3 性能对比
吞吐量测试
1 | # 测试环境 |
可靠性对比
| 场景 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 消息持久化 | ✓ | ✓ | ✓ |
| 事务消息 | ✗ | ✓ | ✓ |
| 顺序消息 | 队列内有序 | 分区有序 | 分区有序 |
| 消息重试 | ✓ | ✗ | ✓ |
| 死信队列 | ✓ | ✓ | ✓ |
| 消息追踪 | ✗ | ✗ | ✓ |
三、RabbitMQ 深度实践
3.1 安装与配置
1 | # Docker Compose 部署 |
3.2 交换机类型详解
1 | graph TB |
Direct Exchange(直连交换机)
1 | @Configuration |
Fanout Exchange(扇形交换机)
1 | @Configuration |
Topic Exchange(主题交换机)
1 | @Configuration |
3.3 消息可靠性保证
生产者确认(Publisher Confirm)
1 | @Configuration |
消费者手动 ACK
1 | @Configuration |
死信队列(DLQ)
1 | @Configuration |
3.4 延迟队列
1 | @Configuration |
四、Kafka 深度实践
4.1 安装与配置
1 | # Docker Compose 部署 |
4.2 核心概念
1 | graph TB |
4.3 生产者配置
1 | @Configuration |
4.4 消费者配置
1 | @Configuration |
4.5 顺序消息
1 | // 生产者 - 保证分区有序 |
4.6 精确一次语义(Exactly-Once)
1 | @Configuration |
五、RocketMQ 深度实践
5.1 安装与配置
1 | # Docker Compose 部署 |
5.2 生产者配置
1 | @Configuration |
5.3 消费者配置
1 | @Configuration |
5.4 事务消息
1 | // 事务消息监听器 |
六、选型指南
6.1 选型决策树
1 | graph TD |
6.2 场景推荐
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 日志收集 | Kafka | 高吞吐、顺序保证 |
| 实时计算 | Kafka | 流处理生态完善 |
| 订单处理 | RocketMQ | 事务消息、可靠性高 |
| 通知系统 | RabbitMQ | 路由灵活、延迟低 |
| 金融交易 | RocketMQ | 事务消息、精确一次 |
| 物联网 | Kafka | 海量数据、高吞吐 |
| 微服务解耦 | RabbitMQ | 协议标准、易于集成 |
6.3 混合使用策略
1 | graph TB |
七、总结
消息队列选型的关键要点:
- 明确需求:吞吐量、延迟、可靠性、顺序性
- 技术匹配:团队技术栈、运维能力
- 场景优先:不同场景选择不同方案
- 混合使用:多种 MQ 配合使用
没有最好的消息队列,只有最适合的。记住:合适的架构才是最好的架构。
参考资料:
- RabbitMQ 官方文档
- Kafka 官方文档
- RocketMQ 官方文档
- 《Kafka 权威指南》
- 《RocketMQ 技术内幕》
RESTful API 设计最佳实践
全面解析 RESTful API 设计的最佳实践,涵盖资源命名、HTTP 方法、状态码、版本控制、分页过滤、错误处理、安全认证等核心主题,包含 3 个架构图和 2 个实战案例