Posts

Drone CICD自动化部署指南 一、Drone核心优势与架构设计 1.1 为什么选择Drone 官方文档 Drone作为轻量级云原生CI/CD工具，相比Jenkins具有显著优势： 资源占用低：基于Docker容器化运行，单个Pipeline平均内存消耗<100MB 云原生支持：原生集成Kubernetes、Docker等云原生技术栈 配置即代码：完全通过.drone.yml定义流程，版本可控 高性能：测试显示并发构建能力比Jenkins高3-5倍16 1.2 企业级架构设计 [Gitee/GitHub] → [Drone Server] → [Docker Runner] (开发环境) ↘ [K8s Runner] (生产环境) ↘ [SSH Runner] (特殊场景) 二、 注册 OAuth 应用 （Gitee为例） 登录 Gitee → 点击右上角头像 → 设置 → 第三方应用 → 创建应用 填写应用信息： 应用名称：Drone CI（自定义） 应用描述：Drone CI/CD 工具（自定义） 授权回调地址：http://你的服务器IP或域名/login（必须正确，否则无法登录） 应用主页：http://你的服务器IP或域名 权限选择：（最少权限原则）user_info，projects，pull_requests，hooks 提交后，记录生成的 Client ID 和 Client Secret（后续配置需要） 三、安装 Drone 服务器和 Runner Drone 由两部分组成： Drone Server：管理项目、接收仓库事件、协调任务 Drone Runner：执行流水线任务（编译、测试、部署等） 3.1 手动启动 Drone Server docker run -d \ --name drone-server \ --restart always \ -p 80:80 \ # 端口映射（生产环境建议加 HTTPS） -v /var/lib/drone:/data \ # 数据持久化 -e DRONE_RPC_SECRET=your_agent_secret \ # 自定义密钥（与 Runner 保持一致） -e DRONE_GITEE_CLIENT_ID=你的Gitee Client ID \ # 替换为 Gitee 应用的 Client ID -e DRONE_GITEE_CLIENT_SECRET=你的Gitee Client Secret \ # 替换为 Gitee 应用的 Secret -e DRONE_GITEE_SERVER=https://gitee....

轻量级容器编排工具指南 在 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: - ....

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 重试的核心思想 重试本质是： 用时间换成功率 但前提是：...