一、项目概述及个人工作职责

本人曾参与政企综合服务门户平台的设计、开发与运维工作，该平台面向辖区内企业与市民提供线上办事、政策查询、业务申报、数据公示等核心 Web 服务，日均独立访问量超 8 万，高峰期（政务办理工作日上午、政策发布时段）并发请求峰值可达 3000+/ 秒。

项目初期系统采用单台应用服务器部署，随着用户量与业务模块持续迭代，逐渐出现响应延迟高、单点故障、服务器资源利用率不均等问题：高峰期 CPU、内存满载导致页面加载超时，单服务器宕机直接造成全平台服务中断，严重影响政务服务体验。为解决上述痛点，项目组决定引入集群架构与负载均衡技术，搭建多节点 Web 应用集群，实现请求分发、故障转移与性能扩容。

本项目整体技术栈采用Nginx 作为七层负载均衡器，后端部署多台 Tomcat 应用服务器，搭配 MySQL 主从数据库、Redis 缓存集群，整体架构为典型的分布式 Web 集群架构。我在项目中担任系统架构师与运维负责人，主要负责集群架构方案设计、负载均衡策略选型与配置、服务器集群部署、压力测试、线上运维调优，同时配合开发团队完成应用服务的无状态改造，保障负载均衡架构稳定落地与长期运行。

二、常见三种负载均衡算法及基本原理

负载均衡算法是负载均衡设备 / 软件实现请求分发的核心规则，决定客户端请求如何分配到后端集群节点。行业内 Web 系统最常用的三种算法为轮询算法、加权轮询算法、最小连接数算法，下面分别阐述其原理、特点与适用场景。

（一）轮询算法（Round Robin）

轮询是最基础、使用最广泛的静态负载均衡算法。基本原理：负载均衡器按照顺序轮流将客户端请求依次分发到后端每一台应用服务器。假设后端存在 Server1、Server2、Server3 三台节点，第一个请求分发至 Server1，第二个请求分发至 Server2，第三个请求分发至 Server3，第四个请求再次回到 Server1，以此循环往复，所有后端节点获得的请求数量基本均等。

该算法属于无差别分发，不考虑服务器硬件性能、当前负载、连接数等状态，仅按固定顺序分配请求。优点是逻辑简单、配置便捷、计算开销极小；缺点是无法适配节点性能差异，若集群中服务器配置参差不齐，会出现高性能节点资源闲置、低性能节点过载的问题。适用于所有后端服务器硬件配置、性能完全一致，且业务请求处理耗时相近的场景。

（二）加权轮询算法（Weighted Round Robin）

加权轮询是轮询算法的优化版本，同样属于静态负载均衡算法，解决了普通轮询无法区分节点性能的问题。基本原理：管理员为每一台后端服务器配置权重值，权重数值大小代表服务器的处理能力，权重越高，分配到的请求数量越多。负载均衡器根据权重比例进行请求分发，不再采用平均分配模式。

例如：后端有三台服务器，Server1 权重设为 3，Server2 权重设为 2，Server3 权重设为 1。理想分配比例为 3:2:1，请求会按照比例依次分发，整体上高性能节点承担更多流量。该算法依旧不感知服务器实时运行状态，仅依靠预设权重分发请求。优点是可根据硬件配置差异化分配流量，资源利用率优于普通轮询；缺点是无法动态感知服务器实时负载，若某台节点突发故障或业务拥堵，仍会持续分配请求。适用于服务器性能有明确差异、业务流量相对稳定的 Web 集群。

（三）最小连接数算法（Least Connections）

最小连接数是典型的动态负载均衡算法，会实时感知后端节点运行状态，也是高并发、长连接 Web 系统的首选算法。基本原理：负载均衡器实时统计每一台后端服务器当前正在处理的活跃连接数，新的客户端请求会被分发至当前活跃连接数最少的节点。若多台节点连接数相同，则按照轮询规则分配。

该算法会动态跟随服务器负载变化调整流量分配，自动避开繁忙节点。对于处理时长不一致的请求（如文件上传、复杂表单提交、大数据查询等长耗时请求），能有效平衡各节点压力。优点是动态适配服务器实时负载，容错性强，应对突发流量、长连接业务表现优异；缺点是需要持续统计、比对连接数，会略微增加负载均衡器的计算开销。适用于请求处理时长差异大、并发波动明显、存在长连接业务的 Web 系统。

三、负载均衡技术在本 Web 项目中的落地实现

结合政企服务门户的业务特点、流量特征与服务器配置，我们采用Nginx 作为七层反向代理与负载均衡载体，分层次设计负载均衡方案，同时结合业务场景混合使用上述负载均衡算法，并配套服务健康检查、会话保持、故障转移等机制，完整实现 Web 系统的负载均衡架构。

（一）整体架构规划

项目采用两级架构实现流量分发：公网用户请求首先到达前端 Nginx 负载均衡集群，由 Nginx 根据预设算法将请求转发至后端 Tomcat 应用服务器集群；应用层内部接口调用、静态资源访问也做了轻量化负载均衡处理。后端共部署5 台 Tomcat 应用节点，其中 2 台为高配服务器（8 核 16G），3 台为标准配置服务器（4 核 8G），硬件性能存在明显差异；业务分为普通页面访问（短请求）、业务申报 / 文件上传（长请求）两大类，流量工作日早间达到峰值，并发波动较大。结合该现状，我们区分业务模块选用不同负载均衡算法，做到精准分流。

（二）核心负载均衡算法选型与配置实现

1. 静态页面、公共查询模块：加权轮询算法平台首页、政策公示、公告查询等纯静态页面、简单查询接口，请求处理速度快、单次耗时短、无长连接，请求特征统一。针对这类业务，我们使用加权轮询算法。根据服务器硬件性能配置权重：2 台高配 Tomcat 节点权重设置为 5，3 台标准节点权重设置为 3。Nginx 按照 5:3 的比例分配流量，让性能更强的服务器承担更多静态请求，充分利用硬件资源。同时开启 Nginx 内置的节点健康检查机制，定时向后端节点发送探测请求，若节点连续多次无响应，自动将其从集群中临时剔除，不再分配请求，节点恢复后自动重新加入集群，避免单点故障影响服务。

2. 业务申报、文件上传、大数据查询模块：最小连接数算法线上业务申报、附件上传、历史数据批量查询等业务，请求处理耗时久、会产生持续活跃连接，不同请求处理时长差距极大。若使用轮询类静态算法，极易出现部分节点连接堆积、负载飙升的问题。因此该类核心业务统一采用最小连接数算法。Nginx 实时监控每台 Tomcat 节点的活跃连接数，新的申报、上传请求优先转发给当前连接数最少的服务器。当某一台节点因处理大文件导致连接数激增时，新请求会自动分流至其他空闲节点，从根源上避免单节点过载，保障核心政务业务稳定运行。

3. 兜底流量与故障容灾：轮询算法针对系统内部运维接口、后台管理端等低并发、访问量极小的模块，直接使用基础轮询算法。这类接口访问频率低、请求量小，服务器负载始终处于低位，轮询算法逻辑简单、开销最低，完全可以满足需求。

（三）配套优化策略，保障负载均衡效果

1. 应用服务无状态改造负载均衡集群要求后端所有应用节点无状态，否则用户会话会出现丢失问题。我们对原有 Web 应用进行改造，将用户 Session 统一迁移至 Redis 分布式缓存，所有 Tomcat 节点共享 Redis 会话数据。无论用户请求被分发到哪一台服务器，都能正常读取登录状态，彻底解决轮询分发带来的会话失效问题。

2. 会话保持配置针对部分需要连续操作的业务流程（分步表单填报），在 Nginx 中开启简易会话保持，基于客户端 IP 绑定节点，保证同一用户在一次业务流程中持续访问同一台后端服务器，提升操作连贯性。

3. 压力测试与算法调优架构部署完成后，我们使用压测工具模拟 3000 + 并发峰值流量进行全场景压测。根据压测结果微调各服务器权重、连接数阈值，反复验证三种算法在不同流量下的表现。压测结果显示：集群整体响应时间从原来的 1.8s 缩短至 0.4s 以内，单节点 CPU 利用率稳定在 40%~60%，无节点过载情况，服务可用性提升至 99.99%。

（四）线上运维效果总结

该套负载均衡方案上线运行至今，稳定支撑平台每日高并发访问。加权轮询保证静态资源高效分发，最小连接数动态平衡长耗时业务压力，基础轮询适配低并发运维接口，三种算法各司其职。系统彻底解决了原有单节点架构的响应慢、单点故障问题，服务器资源利用率大幅提升，后期业务扩容时，仅需新增 Tomcat 节点并修改 Nginx 配置权重即可快速接入集群，具备良好的横向扩展能力。

四、总结

负载均衡是分布式 Web 系统架构中不可或缺的核心技术，通过合理选择负载均衡算法、搭建集群架构，能够有效分摊服务压力、提升系统并发能力、消除单点故障。在本次政企综合服务门户项目中，我结合服务器硬件差异、业务请求特征，差异化使用轮询、加权轮询、最小连接数三种经典算法，配合无状态改造、健康检查、会话保持等配套方案，成功搭建高可用、高性能的 Web 负载均衡集群。

在实际项目落地中我也认识到，没有万能的负载均衡算法，静态算法简单高效但无法感知实时负载，动态算法适配复杂业务但存在少量性能开销。在后续系统迭代中，我们还计划引入 IP 哈希、URL 哈希等算法适配特殊业务，并结合云原生容器化架构实现服务弹性伸缩，进一步优化负载均衡体系，持续提升 Web 系统的稳定性与承载能力。