负载均衡方案系统架构前端层负载均衡器（LB）：这是整个架构的入口点，负责接收来自客户端的请求。它可以是硬件负载均衡

前端层
- 负载均衡器（LB） ：这是整个架构的入口点，负责接收来自客户端的请求。它可以是硬件负载均衡器，如 F5 BIG-IP，也可以是基于软件的负载均衡器，如 Nginx 或 HAProxy 在 Go 应用场景中可自行编写代码实现简单的负载均衡逻辑。
- 对客户端透明，客户端只与负载均衡器进行通信，不知道后端服务器的存在。
应用层
- 服务器集群：由多个相同配置的应用服务器组成，运行相同的 Go 应用程序代码。每个服务器都能独立处理请求，但通过负载均衡器进行任务分配以实现高并发处理。
- 可根据实际需求动态扩展或缩减服务器数量。采用容器化技术（如 Docker）和编排工具（如 Kubernetes）能更方便地管理服务器集群。
数据存储层
- 数据库：存储应用程序所需的数据。可以使用关系型数据库（如 MySQL）或非关系型数据库（如 MongoDB），根据数据的特点和应用需求选择合适的数据库类型。
- 为了保证数据的高可用性和一致性，可以采用主从复制、集群等技术方案。例如 MySQL 的主从复制架构，主数据库负责写入操作，从数据库负责读取操作，通过读写分离减轻主数据库的压力并提高读取性能。同时，使用缓存（如 Redis）来存储热点数据，减少对数据库的访问频率，进一步提高系统性能。

轮询算法（Round Robin）
- 依次将请求分配给每个后端服务器，轮流进行。例如有服务器 A、B、C，第一个请求分配给 A，第二个给 B，第三个给 C，然后第四个又回到 A，如此循环。这种算法实现简单，能平均分配负载，但没有考虑服务器的实际性能差异。
加权轮询算法（Weighted Round Robin）
- 根据服务器的性能、配置等因素为每个服务器分配一个权重。性能好、配置高的服务器权重较大，会被分配更多的请求。例如服务器 A 权重为 3，B 权重为 2，C 权重为 1，那么在分配请求时，A 获得的请求数量相对更多。
最少连接算法（Least Connections）
- 负载均衡器会记录每个后端服务器当前的连接数，新的请求会被分配到连接数最少的服务器上。这种算法能够根据服务器的实时负载情况进行分配，但对于新启动或长时间空闲的服务器可能存在不公平分配的情况。
源 IP 哈希算法（IP Hash）
- 根据客户端的 IP 地址计算一个哈希值，然后根据哈希值将请求分配到对应的服务器上。相同 IP 地址的客户端请求总是会被分配到同一台服务器上，适用于需要保持会话一致性的场景，如用户登录状态、购物车信息等。

定期检测
- 负载均衡器按照一定的时间间隔（如每隔 5 秒）向后端服务器发送健康检查请求，如发送一个简单的 HTTP 请求并检查响应状态码。
- 对于应用服务器，可以检查关键服务是否正常运行，如数据库连接、特定端口监听等情况。对于数据库服务器，可以检查数据库的连接性、查询响应时间等指标。
响应阈值判断
- 设置响应时间阈值和错误率阈值。如果服务器的响应时间超过设定的阈值或者错误率高于一定比例，则认为服务器不健康。
- 当发现服务器不健康时，负载均衡器将其从可分配服务器列表中暂时移除，直到它恢复健康状态再重新加入。

基于 Cookie 的会话保持
- 负载均衡器在将请求转发到后端服务器时，会在响应中插入一个自定义的 Cookie，后续客户端的请求中带有这个 Cookie，负载均衡器根据 Cookie 信息将请求路由到之前处理该请求的服务器上。
粘性会话（Sticky Sessions）
- 通过在负载均衡器上配置会话粘性规则，使得来自同一个客户端的一系列请求总是被转发到同一台后端服务器上。可以基于源 IP 地址、用户会话 ID 等信息实现粘性会话。

监控指标收集
- 收集负载均衡器和后端服务器的各种性能指标，如请求处理量、响应时间、CPU 使用率、内存使用率、网络流量等。通过 Prometheus 等监控工具进行数据采集，并使用 Grafana 等可视化工具展示监控数据，以便及时发现系统瓶颈和异常情况。
日志记录
- 记录负载均衡器的请求转发日志以及后端服务器的应用日志。详细记录请求的来源、目标服务器、处理时间、响应状态码等信息。通过 ELK（Elasticsearch、Logstash、Kibana）堆栈对日志进行集中管理和分析，便于排查问题和进行系统审计。