负载均衡如何分散入口压力？
- 负载均衡: 把请求分配给多个可用后端，让容量增长与单机故障不直接暴露给客户端;
- 布置位置: 可部署在客户端与应用、应用与下游服务等边界，但数据库写入必须遵守主从或路由协议;
- 健康检查: 依据存活和就绪状态剔除故障实例，恢复后再逐步加入，不能只看进程是否存在;
- 扩缩容: 新实例完成初始化后接流量，下线前排空连接，避免容量变化制造错误;
L4 与 L7 如何决定路由？
| 层次 | 观察信息 | 适用路由 |
|---|
| L4 传输层 | IP、端口、连接 | 低开销连接分配 |
| L7 应用层 | 主机名、路径、头部、消息内容 | 按域名、完整路径或参数分配 |
- 层次修正: 原文所谓 Network layer 负载均衡实际描述 L4，不能混淆成 OSI 第三层;
- TLS 终止: 若需读取加密后的 HTTP 内容，通常要在受信任入口终止 TLS，再按要求保护到后端的链路;
哪种分配算法适合当前负载？
| 算法 | 分配依据 | 主要注意点 |
|---|
| 轮询 | 依次轮转 | 默认请求成本与机器能力接近 |
| 加权轮询 | 按容量权重轮转 | 权重要随容量调整，不限于 DNS |
| 最少连接 | 当前活动连接数 | 连接数不一定代表实际工作量 |
| 最短响应时间 | 延迟并结合负载 | 观测可能滞后 |
| 最少带宽 | 当前吞吐占用 | 适合带宽差异明显的负载 |
| 哈希 | 用户、IP、URL 等键 | 有利于亲和性，也可能形成热点 |
怎样选择负载均衡的实现形态？
- 软件实现: 配置灵活、部署方便，但需要容量管理；Nginx、HAProxy 及云托管入口是原文示例;
- 硬件实现: 使用专用设备与固件承载流量，采购和升级成本较高;
- DNS 分配: 返回多个或按策略选择地址，普通轮询不自带健康检查，缓存也会延迟摘除故障地址;
- DNS 边界: 托管服务可以另加健康检查，不能从普通轮询局限推出所有 DNS 服务都无法探活;
入口自身如何避免成为单点？
- 冗余: 部署多个入口或主备切换，并考虑故障检测、地址接管和连接迁移;
- 会话亲和: 把同一用户送回同一实例有助于本地会话，但增加故障与扩缩容时的状态迁移负担;
- 长连接: WebSocket 等连接需要超时配置、连接排空与容量预算，不能只按每秒 HTTP 请求估算;
- 可观测性: 日志记录请求元数据，追踪 ID 串联跨服务调用，便于定位延迟和失败;
- 附加能力: 压缩、缓存、证书管理、重定向和固定响应属于产品特性，应逐项确认，不能由“负载均衡”名称推定;
- 云产品示例: 原文还列举 AWS ELB、Azure、Google Cloud 和 DigitalOcean 的负载均衡服务;