摘要
2024 年 3 月至 10 月，我作为系统架构师参与了某省级政务一体化服务平台项目的设计与开发工作。该平台面向省内千万居民，提供社保查询、不动产登记、企业办事等线上政务服务，项目采用微服务架构，用户访问存在明显的潮汐流量特征，高峰期并发请求可达每秒 8000 次，存在单点压力过大、服务响应超时等风险。为保障平台高可用与高性能，我主导了负载均衡方案的选型、架构设计与落地实施。本文首先介绍项目背景与本人工作职责；然后阐述静态、动态、基于场景的三类负载均衡策略的分类与原理；最后结合项目实践，论述负载均衡技术在网关层、应用服务层、数据库层的落地应用，分析实施过程遇到的问题与优化手段。实践证明，负载均衡方案有效分流请求，平台高峰期可用性达到 99.9%，满足政务系统的业务需求。
正文
随着互联网业务规模持续扩张，用户并发访问量快速增长，单体应用难以承载海量流量，分布式、微服务架构被广泛应用。在分布式系统中，多台服务器共同对外提供服务，如何将客户端请求合理分配到后端服务节点，避免部分服务器过载、部分服务器资源闲置，是保障系统高可用、高吞吐的核心问题。负载均衡技术就是通过流量调度策略，将业务请求分发到多个后端服务实例，充分利用集群资源，提升系统整体处理能力，同时实现故障节点自动隔离，提高系统容错能力。负载均衡按照调度逻辑可以分为静态负载均衡、动态负载均衡、基于场景的负载均衡三大类，在高并发业务系统中被广泛使用。
2024 年 3 月，我所在的软件公司承接了某省级政务一体化服务平台建设项目。该平台整合社保、医保、不动产、市场监管等 20 余项政务业务，面向全省个人用户与企业用户提供线上办理服务。平台用户访问存在显著的潮汐特性：工作日上午 9 点至 11 点为访问高峰，大量用户集中办理业务，并发请求峰值约 8000QPS；夜间时段流量锐减，QPS 不足 200。我在项目中担任系统架构师，主要负责系统总体架构设计、中间件选型、高可用方案设计，重点完成负载均衡体系的方案设计、测试验证，并指导开发团队落地实施。项目存在的核心痛点：一是高峰期流量集中，若请求分配不均，部分服务实例 CPU、内存占满，造成接口超时；二是服务实例存在差异，不同服务器硬件配置、负载状态不同，固定分配策略容易导致负载失衡；三是政务业务存在多种请求类型，文件上传、数据库查询、简单页面查询的资源消耗差异巨大，需要结合业务场景做流量调度。
负载均衡策略主要分为静态负载均衡、动态负载均衡、基于场景的负载均衡三类。
静态负载均衡策略，调度规则在配置时预先设定，不感知后端服务器实时负载状态，按照固定规则分发请求。常用策略包含轮询策略、加权轮询策略、IP 哈希策略。。
动态负载均衡策略，调度器会实时采集后端节点的运行指标，依据服务器当前负载情况动态分配流量，指标一般包含 CPU 使用率、内存占用、当前连接数、请求响应时间等。常见策略有最少连接策略、加权最少连接策略、最快响应策略。最少连接策略，。
基于场景的负载均衡策略，结合业务请求本身的内容特征进行流量调度，不再单纯依靠连接数或者 IP。常见策略包括 URL 哈希、请求内容路由、地理位置调度。URL 哈希策略，对请求 URL 做哈希运算。
在本省级政务平台项目中，我设计了多层负载均衡架构，分为四层：DNS 层、Nginx 网关层、微服务注册中心层、数据库读写分离层，针对不同层级选用适配的负载均衡策略。
第一层 DNS 负载均衡，采用基于地理位置的场景化负载均衡。政务平台部署省内两个机房，分别在省会与南部地市。通过 DNS 解析，将用户请求按 IP 地域调度到就近机房，降低跨地域网络延迟。省会用户访问省会机房，南部地市用户接入南部机房，两个机房互为灾备，当其中一个机房故障时，DNS 自动切换流量，实现机房级容灾。
第二层是 Nginx 网关层，作为平台流量入口。网关层选用加权轮询（静态）结合健康检查机制。平台网关后端部署 6 台 Nginx 节点，服务器硬件配置有差异，4 台高配服务器权重设置为 3，2 台普通服务器权重为 1。Nginx 持续探测后端服务实例状态，一旦某个实例接口返回错误、超时，自动摘除故障节点，不再分配流量。在项目压力测试阶段，我们发现单纯静态加权轮询在突发流量下，会出现部分实例连接堆积。于是我们在网关增加动态最少连接策略作为补充，当节点连接数超过阈值，动态调整流量分配，有效解决流量突增带来的负载不均问题。
第三层微服务内部负载均衡，针对不同微服务选用不同策略。对于社保查询这类简单查询微服务，请求处理速度快，服务实例配置一致，采用轮询策略；对于事项办理微服务，业务逻辑复杂，处理耗时差异大，采用加权最少连接动态策略，实时采集实例连接数与 CPU 负载，优先分发请求给负载低的实例。针对文件上传微服务，采用基于 URL 哈希的场景策略，相同文件资源请求转发到同一个存储实例，提升缓存命中率。在项目上线初期，我们遇到一个问题：动态负载均衡频繁采集节点指标，在每秒数千请求下，带来了微小的调度延迟。我们优化指标采集频率，将采集间隔由 1 秒调整为 3 秒，平衡调度精度与性能开销，问题得到解决。
第四层数据库层负载均衡，采用基于业务场景的读写分离负载均衡。政务平台大量请求是查询操作，写入请求占比不足 10%。我们使用 MyCat 中间件做数据库负载均衡，解析 SQL 语句，写请求路由到主库，读请求分发到多个从库节点，读请求内部采用轮询策略，分担主库查询压力。同时，对于报表类的慢查询 SQL，单独路由到专用分析从库，防止慢查询挤占普通业务查询资源，实现业务流量隔离。
平台上线之后，负载均衡体系发挥了良好效果。工作日高峰期，8000QPS 请求被均匀分发到各个服务实例，各节点 CPU 负载稳定维持在 40%~65%，没有出现单点过载，接口平均响应时间控制在 200ms 以内。当某个微服务实例发生故障，负载均衡组件在 3 秒内完成故障节点摘除，用户几乎无感知。平台整体可用性达到 99.99%，顺利通过政务系统验收。
在项目复盘阶段，我也总结了负载均衡设计的经验与不足。静态策略简单高效，但无法应对服务负载动态变化；动态策略适配流量波动，但存在少量调度开销；基于场景的负载均衡可以实现业务流量隔离，但架构复杂度更高，需要做好请求解析。本项目不足之处在于，负载均衡权重配置依靠人工经验，后续计划引入监控数据自动动态调整权重，实现智能化负载调度。
综上所述，负载均衡是分布式系统保障高可用、高性能的核心技术。在政务平台项目中，通过分层、组合使用多种负载均衡策略，有效实现流量分发、故障隔离、资源充分利用，保障省级政务平台稳定对外提供服务。在后续的分布式系统架构设计中，我会持续优化负载均衡方案，结合弹性伸缩、智能流量调度技术，进一步提升系统面对突发流量的处理能力。
