轻量级容器编排工具指南 在 Docker 环境中，除了 K8s，还有多种轻量级方案可以实现服务自动重启、健康检查等功能，特别适合单机或中小规模部署。 一、简单方案 1.1 Docker 自身的重启策略（最基础方案） Docker Engine 内置了容器重启策略，可直接在启动容器时配置，实现容器退出后自动重启。 常用重启策略： --restart always：无论容器因何种原因退出（包括正常退出），总是自动重启。 --restart on-failure[:max-retries]：仅在容器以非 0 状态码退出时重启，可选最大重试次数（如on-failure:3最多重启 3 次）。 --restart unless-stopped：除非手动执行docker stop，否则始终重启（包括 Docker daemon 重启时） 示例： # 启动PHP容器，配置always重启策略 docker run -d \ --name php-app \ --restart always \ # 核心：容器挂掉后自动重启 -p 80:80 \ -v /path/to/php/code:/var/www/html \ php:8.2-apache 优势： 零依赖，直接使用 Docker 原生功能，适合单机部署。 局限： 仅能监控容器本身是否存活，无法检测应用内部故障（如 PHP-FPM 假死但容器仍运行）。 1.2 ocker Compose（适合多容器应用） 如果 项目依赖其他服务（如 MySQL、Redis），可使用docker-compose管理，通过配置restart参数实现自动重启，同时支持健康检查。 docker-compose.yml示例： version: '3.8' services: php-app: image: php:8.2-apache restart: always # 容器退出后自动重启 ports: - "80:80" volumes: - ....

Vibe Coding 的复用与 Agent 调教：从一次性生成到持续进化 一、问题的本质：为什么 Agent 用着用着就不顺手了？ 很多人在体验 Vibe Coding 时都会遇到一个尴尬的转折点：第一天惊为天人，第三天开始反复改 prompt，一周后觉得还不如自己写。 这不是 Agent 变笨了，而是暴露了 Vibe Coding 最核心的挑战——代码是 AI 生成的，但需求是持续变化的。传统开发中，代码即文档，修改代码就是修改需求；而在 Vibe Coding 中，需求分散在无数次对话里，代码只是 AI 对需求的“瞬时快照”。 要真正让 Agent 越用越顺手，需要一套结构化的复用与调教策略。 二、复用策略：让知识和代码可沉淀 2.1 Prompt 模板化 不要每次都从零开始写 prompt，将成功的 prompt 固化为模板。 ❌ 低效做法： "帮我写一个用户登录接口，用 JWT，要包含验证码，还要有密码加密..." ✅ 模板化做法： 创建 templates/api-login.md： # 用户登录 API 生成模板 ## 上下文 - 框架：[FastAPI/Express/Hyperf] - 数据库：[MySQL/PostgreSQL] - 认证方式：JWT ## 功能要求 1. 接收用户名/邮箱和密码 2. 验证码校验（Redis 存储） 3. 密码 bcrypt 验证 4. 生成 JWT Token（过期时间 7 天） 5....

Kong+Konga+Consul 安装和使用 此处使用Docker安装方式 一、 安装Kong kong具体使用可参考另一篇文章：Kong API网关 为了确保 Kong、Konga 和 Consul 能够通信，Kong 和 Konga 也需要加入到同一个网络。如果你尚未创建网络，或者希望使用新的网络，可以创建一个： docker network create kong-net 1.1 安装 PostgreSQL (Kong 的数据库) Kong 需要 PostgreSQL 来存储其配置数据 docker run -d --name kong-database \ --network=kong-net \ -p 5432:5432 \ -e "POSTGRES_USER=kong" \ -e "POSTGRES_DB=kong" \ -e "POSTGRES_PASSWORD=kong" \ postgres:13 –network=kong-net: 确保数据库与 Kong、Consul 在同一网络。 -e 环境变量：设置数据库的用户名、数据库名和密码。 建议使用 PostgreSQL 9.6 或更高版本，这里使用了 13 版本。 1.2 初始化 Kong 数据库 运行一个临时容器来执行数据库迁移： docker run --rm \ --network=kong-net \ -e "KONG_DATABASE=postgres" \ -e "KONG_PG_HOST=kong-database" \ -e "KONG_PG_USER=kong" \ -e "KONG_PG_PASSWORD=kong" \ kong:3....

并发模型-协程模型 一、介绍 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 一次只处理一个请求。...

高并发系统稳定性设计 本文适用于 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） 高并发关注的是： 系统能够同时处理多少请求。...

高并发系统设计-服务降级 一、概述 1.1 什么是服务降级 服务降级（Fallback）指的是： 当系统压力过大或依赖服务不可用时，主动返回一个“可接受的替代结果”，而不是让请求失败。 例如： 正常： → 查询实时商品详情 降级： → 返回缓存商品详情 / 静态数据 1.2 降级和熔断的区别 项目 熔断 降级 目的 防止故障扩散 保证可用性 触发 服务异常 系统压力 / 异常 行为 阻断调用 返回替代结果 是否对外可用 否 是 熔断 = 不调用 降级 = 换一种方式返回 1.3 为什么需要服务降级 在高并发系统中： 资源永远是有限的。 例如： 数据库：1000 QPS, 实际请求：10000 QPS 如果不做降级：请求全部打到数据库-》系统崩溃 1.4 企业典型应用场景 场景1：商品详情页 正常： → 实时库存 + 价格 + 推荐 降级： → 缓存商品 + 默认库存 场景2：推荐系统 推荐服务挂了 → 返回热门商品 场景3：搜索系统 ES不可用...

高并发系统设计-熔断 一、概述 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：第三方接口超时 例如：...

高并发系统设计-缓存保护 一、概述 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 同时配合：...

高并发系统设计-重试 一、概述 1.1 什么是重试 重试（Retry）是指： 当一次请求失败后，在满足条件的情况下再次发起请求，以提高成功率。 例如： 请求 → 失败 → 再请求 → 成功 1.2 为什么需要重试 在分布式系统中，失败是常态： 网络抖动 RPC短暂超时 Redis瞬时不可用 MySQL连接波动 依赖服务重启 例如： 请求支付服务 → 超时 但实际服务是正常的 如果不重试：用户支付失败 但如果允许重试： 第一次失败 第二次成功 1.3 重试解决的问题 重试主要解决： 1. 短暂故障 如： 网络抖动 服务瞬断 连接超时 2.依赖服务不稳定 如： 第三方支付 / 短信 / API 3.提高成功率 1.4 重试的误区 错误做法 ： 失败 → 立即重试 → 再失败 → 无限循环 正确做法是：可控重试 + 退避策略 + 最大次数限制 二、原理 2.1 重试的核心思想 重试本质是： 用时间换成功率 但前提是：...