从零搭建高可用云上 Web 服务：腾讯云 CVM、CLB 与云数据库实践

一、背景

很多中小型 Web 项目在早期通常部署在一台云服务器上：Nginx、后端服务、数据库全部放在同一台机器里。这种架构简单、成本低，但随着访问量增长，会逐渐暴露出几个问题：

第一，单机故障会导致整个服务不可用。 第二，数据库与业务服务抢占 CPU、内存和磁盘 I/O。 第三，扩容不方便，每次升级都容易影响线上访问。 第四，安全边界不清晰，数据库直接暴露在公网会带来风险。

因此，本文介绍一种较通用的云上 Web 服务架构：使用腾讯云 CVM 部署业务服务，使用 CLB 做流量负载均衡，使用 TencentDB 托管数据库，并结合安全组、内网访问和健康检查提升系统可用性。

二、目标架构

一个基础高可用架构可以设计为：

用户请求先进入腾讯云负载均衡 CLB，CLB 根据转发规则将请求分发到多台 CVM。每台 CVM 运行相同的 Web 应用。业务服务通过内网连接腾讯云数据库 MySQL。数据库不开放公网访问，仅允许来自业务服务器安全组的内网访问。

整体链路如下：

用户浏览器 → CLB → 多台 CVM → TencentDB MySQL

这种架构的优势是清晰的： 业务服务可以水平扩容；单台 CVM 故障不会导致服务整体不可用；数据库由云厂商托管，备份、监控、主从高可用能力更完善；数据库不暴露公网，安全性更高。

三、CVM 部署业务服务

以一个 Node.js 或 Java Spring Boot 服务为例，建议每台 CVM 只承担业务服务和必要的反向代理工作。

常见部署方式如下：

# 安装基础环境
sudo apt update
sudo apt install -y nginx git curl

# 拉取代码
git clone https://example.com/demo-app.git
cd demo-app

# 安装依赖并启动服务
npm install
npm run build
npm run start

如果是生产环境，不建议直接用命令行启动进程，可以使用 systemd、PM2 或容器方式托管进程。例如使用 PM2：

npm install -g pm2
pm2 start app.js --name demo-app
pm2 save
pm2 startup

Nginx 可以作为本机反向代理，将 80 端口请求转发到后端服务端口：

server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

四、使用 CLB 做负载均衡

腾讯云 CLB 可以将公网流量分发到多台后端 CVM。配置时重点关注三项：

第一，监听器协议。Web 服务通常使用 HTTP 或 HTTPS。如果要做证书统一管理，可以在 CLB 层终止 HTTPS。

第二，后端服务器组。将多台 CVM 加入同一个后端服务池，并设置相同的服务端口。

第三，健康检查。CLB 会定期访问后端服务的健康检查路径，例如：

/health

后端应用可以提供一个简单接口：

app.get('/health', (req, res) => {
  res.status(200).send('ok');
});

当某台 CVM 异常时，CLB 会自动停止向它转发流量。等服务恢复后，再重新加入转发列表。

五、数据库使用内网连接

数据库建议使用腾讯云云数据库 MySQL，而不是部署在业务 CVM 上。业务服务通过内网地址访问数据库，避免公网暴露。

应用配置示例：

DB_HOST=10.0.0.12
DB_PORT=3306
DB_USER=app_user
DB_PASSWORD=your_password
DB_NAME=demo

同时，数据库安全组只允许业务 CVM 的安全组访问 3306 端口。这样即使数据库没有公网访问入口，也能被业务服务正常连接。

数据库账号也不要直接使用 root。可以为业务系统创建独立账号，并只授予必要权限：

CREATE USER 'app_user'@'%' IDENTIFIED BY 'strong_password';
GRANT SELECT, INSERT, UPDATE, DELETE ON demo.* TO 'app_user'@'%';
FLUSH PRIVILEGES;

六、发布与扩容建议

当需要发布新版本时，可以采用滚动发布方式：

先从 CLB 后端列表中摘除一台 CVM； 在该 CVM 上更新代码并重启服务； 确认健康检查通过后重新加入 CLB； 然后继续更新下一台 CVM。

这种方式可以降低发布过程中的服务中断风险。

当访问量增长时，也可以横向增加 CVM。只要新机器部署相同应用，并加入 CLB 后端服务池即可。

七、监控与告警

一个线上服务至少需要关注以下指标：

CVM 的 CPU、内存、磁盘使用率； CLB 的请求数、错误率、后端健康状态； 数据库的连接数、慢查询、QPS、磁盘空间； 应用自身的错误日志和接口耗时。

建议将应用日志统一输出到文件或日志服务中，便于排查问题。例如 Nginx 日志、应用错误日志、接口访问日志都可以单独管理。

八、总结

从单机部署演进到云上高可用架构，并不一定需要非常复杂的技术栈。通过 CVM、CLB 和云数据库的组合，就可以搭建一个具备基础高可用、可扩展和安全隔离能力的 Web 服务架构。

这类架构适合大多数中小型业务系统、企业官网、管理后台、API 服务和小程序后端。后续如果业务继续增长，还可以进一步引入容器服务、缓存 Redis、对象存储、日志服务和自动化发布流水线。