2个云主机做负载均衡，部署思路和关键步骤有哪些

业务从单机走到稳定对外服务，先碰到的往往是单点故障。一台服务器宕机，网站、接口、后台管理系统都会一起受影响。这个阶段，2个云主机 负载均衡通常是比较现实的选择，投入可控，结构也不算复杂，能先把可用性和并发承接能力拉起来。

对中小企业、创业项目、区域电商、SaaS后台、活动专题站这类业务来说，两台云主机加一个负载均衡入口，往往已经够用一段时间。难点常常出在几个基础环节有没有处理干净：流量怎么分、故障怎么摘除、登录状态怎么保持、文件放哪里、数据库出问题怎么办。这些地方没想清楚，双机也只是看上去更稳。

为什么很多业务会从2个云主机开始

和单台服务器相比，2个云主机最大的变化，是有了最基本的冗余。A机出故障，B机还能继续接请求，业务不至于直接中断。负载均衡器再把用户请求分到两台后端上，单机压力也会小一些。

这种方案常见于几类场景。

• 官网、企业门户、展示型网站，重点是别因为一台机器故障就整站打不开；
• API接口服务，平时流量平稳，但在活动、营销、调用集中时会有短时并发；
• 电商或活动页面，推广投放后流量容易突然上来，需要入口能分流；
• 已经在线的单机项目，想先用较低改造成本往高可用架构迈一步。

从预算看，2个云主机 负载均衡比三台、四台甚至更多节点的集群更容易落地；从运维看，节点少也有好处，团队可以先把发布、监控、日志、备份这些基本功补上。很多项目一开始的问题不在架构太小，而是配套太粗。

2个云主机负载均衡的基本架构

常见结构很直接：用户请求先进入负载均衡层，再由负载均衡器把流量分发到两台云主机。A、B两台机器部署相同版本的应用，对外提供统一服务。

典型组成

• 负载均衡入口：云厂商的SLB、ALB，或者自建Nginx、HAProxy；
• 后端云主机A、B：运行同一套应用，配置尽量保持一致；
• 共享存储或对象存储：统一管理上传文件、图片和静态资源；
• 数据库：可以先独立部署，后续再考虑主从、备份或托管；
• 缓存或会话存储：比如Redis，用来处理多机下的登录状态一致性问题。

这里有个很容易踩的坑：负载均衡不只是把流量分到两台机器。如果应用依赖本地文件、本机会话、本地缓存，或者数据库仍然是新的单点，那入口层做了分流，整体可用性也不会高到哪里去。问题只是从Web层挪到了别的地方。

部署前先确认4件事

会话要不要共享

用户登录后如果会话只保存在某一台主机本地，请求下一次被分到另一台时，就可能出现登录失效、购物车丢失、状态错乱。处理办法通常有两种：一种是开启会话保持，让同一用户尽量落到固定后端；另一种是把会话统一放到Redis这类外部组件里。短期应急可以用前者，长期运行更稳的还是后者。

上传文件放在哪里

A、B两台机器各自保存本地上传文件，切换节点后很容易出现资源找不到。尤其是商品图、附件、活动海报这类内容，一旦用户访问落到另一台主机，就可能直接404。更合适的做法是把文件放到对象存储或共享存储，应用服务器只负责处理业务请求。

数据库会不会变成新的单点

很多团队把Web层改成双机后，会误以为高可用已经做完了。但数据库如果还是单点，一旦故障，前面两台主机一样无法工作。至少要把自动备份、监控报警、恢复预案准备好；条件允许，再往主从或更高可用的方案升级。双机部署能扛住应用层故障，扛不住数据库完全不可用。

发布机制能不能配合双机

如果每次上线都是同时重启两台主机，负载均衡也帮不上太多。更稳妥的办法是分批发布：先把A机从流量池里摘掉，更新并验证后再恢复；确认没问题，再处理B机。这样就算新版本有问题，也不会把两个节点一起带下去。

常见的负载分发策略怎么选

负载均衡器一般都会提供多种算法。对于两台云主机的场景，不需要追求复杂，重点还是和业务情况匹配。

• 轮询：按顺序把请求平均分到A、B两台主机，适合两台服务器配置和处理能力接近的情况；
• 加权轮询：如果一台配置更高，或者预留给它更多资源，可以分配更多流量；
• 最少连接：优先把请求给当前连接数更少的主机，适合请求耗时差异比较大的业务；
• 源地址哈希：让同一来源的用户更容易落到固定后端，适合暂时还没完全处理好多机会话时使用。

对多数中小项目来说，轮询加健康检查已经够用了。影响稳定性的，往往是应用能不能尽量无状态化、健康检查是不是够细、异常节点能不能及时摘掉。

一个常见场景：电商活动页怎么用2个云主机负载均衡

电商活动页是比较典型的使用场景。平时访问压力不大，一到投放广告、节日促销，页面响应就会变慢，接口也容易抖。原来单机还能勉强跑，一到高峰就开始出502，登录状态也不稳定。这个时候，直接上复杂集群未必划算，先把2个云主机 负载均衡搭起来，往往更合适。

这类改造步骤通常比较固定。

1. 新增第二台云主机，把应用环境、依赖、配置和原主机对齐，别让两台机器“看起来一样，实际上不一样”；
2. 前端接入云负载均衡服务，把80和443流量统一收进来；
3. 把用户登录会话迁移到Redis，避免用户被切到另一台机器后状态丢失；
4. 把商品图、活动海报这类文件迁到对象存储，解决静态资源不一致；
5. 配置健康检查，某台主机接口异常时，自动停止向它分发流量；
6. 发布时按节点逐台更新，保证整个过程中始终有可用实例在线。

这种做法的效果通常很直接：高峰时两台主机一起承接请求，页面波动会小一些；如果A机因为磁盘异常或者服务卡死被健康检查判定失败，流量还能自动切到B机，业务不至于整个中断。当然，数据库如果还是单点，风险并没有完全消失，但和原来的单机相比，稳定性已经前进了一大步。

落地时最容易忽视的问题

• 只做双机，不做监控：没有CPU、内存、连接数、响应时间、错误率这些监控，出了问题还是靠猜。双机不是免维护，反而更需要知道哪一层先出故障。
• 健康检查太浅：只检测端口通不通，经常会误判。端口还开着，不代表应用逻辑正常，最好加一个业务级检测接口，比如能返回关键状态的健康页。
• 两台主机配置不一致：环境变量、依赖包版本、Nginx配置、定时任务只要有一处不同，就容易出现“有时正常、有时报错”。上线前最好做一次配置核对。
• 忽略安全策略：负载均衡开放公网后，安全组、WAF、HTTPS证书、回源规则都要一起梳理。入口改了，安全边界也跟着变了。
• 把负载均衡当成高可用的全部：它解决的是入口和Web层分流问题，数据库、缓存、DNS、备份这些地方照样可能出故障。

这种方案能用多久

如果业务流量不算高，架构也比较简单，团队规模有限，那么2个云主机配合负载均衡，完全可以稳定跑很长一段时间。它很适合作为从单机向高可用架构过渡的第一步，先把最危险的单点拆掉。

业务继续增长后，新的压力会慢慢冒出来：数据库越来越吃紧，后台任务和Web服务混跑互相影响，静态资源带宽上升，发布次数变多，运维要求也会跟着提高。到了这个阶段，再考虑数据库读写分离、容器化部署、自动扩缩容、CDN加速、服务拆分，会更顺手。因为前面的双机部署，已经把很多基础习惯建立起来了。

2个云主机 负载均衡不算复杂架构，但很实用。对预算有限又需要稳定性的团队来说，它是很合适的起点。把会话、文件、数据库、监控、发布流程这几件事一起处理好，双机方案才能真正发挥作用，不只是多加了一台服务器。