我们在一次促销活动期间，部署在菲律宾的数据服务平台频繁出现异常。随着并发用户数量瞬间暴涨，后端服务无法承载流量压力，出现严重延迟甚至直接宕机。尽管我们使用了性能较高的裸金属服务器，但面对突如其来的高并发，这种传统部署架构依然显得力不从心。
在这次经历之后，我决心对现有服务进行架构重构，最终选择了以 容器化 + 自动扩容 为核心的技术方案。本文将分享我的具体实践过程，包括容器编排、负载感知的自动扩容策略以及菲律宾地区部署的特别考量。
原始架构中，服务是以单体部署在两台高配物理服务器上，部署在菲律宾本地数据中心。系统采用 Nginx + PHP-FPM + MySQL，使用 Keepalived 实现主备高可用。但一旦流量集中打入某一台服务器，CPU 使用率迅速飙升至 100%，服务响应时间急剧上升，并最终出现超时和502错误。
我们识别出三个主要瓶颈：
- 单点服务资源上限：即使服务器配置再高，物理资源依旧有限。
- 部署缺乏弹性：负载无法横向扩展。
- 手动扩容滞后性：响应速度跟不上流量波动。
容器化架构改造方案
为了解决上述问题，我决定使用 Kubernetes 来对系统架构进行容器化改造，核心思路包括：
拆分单体服务为独立微服务（如 Web、API、Worker）
使用 Docker 容器进行打包与部署
使用 Kubernetes 管理服务编排、负载分发与扩缩容
技术栈选择：
| 组件 | 技术栈 |
|---|---|
| 容器管理 | Docker |
| 编排平台 | Kubernetes（部署于菲律宾区域节点） |
| 自动扩容 | HPA (Horizontal Pod Autoscaler) |
| 服务暴露 | Ingress + Nginx Controller |
| 状态存储 | MySQL (独立部署) + PersistentVolume |
| 日志监控 | Prometheus + Grafana + Loki |
实施步骤详解
1. 应用容器化改造
我将原有 PHP-FPM + Nginx 架构拆分为两个容器服务：
- nginx-service：仅负责静态资源与反向代理
- php-api-service：运行 PHP 应用逻辑，使用 fpm 模式接收请求
并统一打包为如下 Dockerfile：
FROM php:8.1-fpm
RUN docker-php-ext-install mysqli pdo pdo_mysql
COPY ./src /var/www/html
WORKDIR /var/www/html
Nginx 配置通过 ConfigMap 注入，服务通过 Ingress 暴露。
2. Kubernetes 部署与初始副本设置
部署配置示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: php-api
spec:
replicas: 2
selector:
matchLabels:
app: php-api
template:
metadata:
labels:
app: php-api
spec:
containers:
- name: php
image: registry.example.com/php-api:latest
resources:
requests:
cpu: "250m"
memory: "512Mi"
limits:
cpu: "1000m"
memory: "1024Mi"
3. 启用自动扩容 (HPA)
我们设置基于 CPU 利用率的 HPA 策略，当容器平均 CPU 超过 70% 时自动横向扩容：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: php-api-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-api
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
4. 高并发测试验证
在部署完毕后，我们模拟了突发 1000 QPS 的访问压测，结果如下：
| 指标 | 改造前（平均） | 改造后（平均） |
|---|---|---|
| 响应时间 | 1.8 秒 | 220 毫秒 |
| 宕机率 | 17% | 0% |
| CPU 利用率 | 100% | 70-85% 动态调整 |
| 平均可用副本 | 2 | 动态 4~8 副本 |
通过容器化和自动扩容，系统在高并发场景下表现稳定，完全杜绝了之前频繁宕机的问题。
菲律宾部署的特殊考量
菲律宾本地的云服务资源有限，部分区域带宽质量波动较大。在实际部署过程中，我采取了以下应对策略：
- 选用菲律宾马卡蒂的 GCP 区域节点，具备良好网络链路
- 使用本地 CDN（Cloudflare 菲律宾节点）缓存静态资源
- 日志与监控统一上报至香港区域 Prometheus 集群，避免本地磁盘 I/O 饱和
- 服务镜像推送至 Philippines 区域 Harbor 仓库，提升部署速度
这次的架构演进让我深刻体会到，弹性与可扩展性才是应对高并发的根本解决之道。相比不断堆高硬件配置，容器化和 Kubernetes 带来的资源调度能力和动态扩容机制显得更加高效与可持续。
建议有类似问题的团队尽早进行服务容器化改造，特别是在南亚或东南亚部署时，应结合当地网络与基础设施实际，合理配置资源、监控与容灾策略，以保证服务在高并发环境下依旧稳定可靠。
