47 lines
4.7 KiB
Markdown
47 lines
4.7 KiB
Markdown
在**商用 ITSM（IT 服务管理）SaaS 软件**背景下，系统通常需要同时服务多家企业客户（B2B 多租户），业务涵盖**员工自助服务门户、高频工单/事故处理 API、大规模第三方系统 Webhook 告警对接**以及**长耗时报表与 SLA 统计**等模块。
|
||
|
||
结合 **AWS Application Load Balancer (ALB)** 的 7 层应用层路由与流量治理能力，以下是专为 ITSM SaaS 平台设计的负载均衡架构方案：
|
||
|
||
---
|
||
|
||
1. 具体实现方式
|
||
|
||
利用 ALB 的**内容感知路由（Content-Based Routing）** 与多目标组（Target Groups）支持，将不同特性的 ITSM 业务模块拆分治理：
|
||
|
||
- **基于主机的路由（Host-Based Routing）**：
|
||
- **客户端门户流量**：将发往 `portal.itsm-saas.com` 的请求路由至“Self-Service Portal 目标组”（提供员工提交工单、查询知识库的 Web 界面）。
|
||
- **API 与集成流量**：将发往 `api.itsm-saas.com` 的流量路由至后端的微服务集群。
|
||
- **基于路径的路由（Path-Based Routing）**：
|
||
- **核心工单与事故 API（****/api/v1/incidents/*****）**：路由至部署在 Amazon ECS 容器集群上的“工单服务目标组”。
|
||
- **自动化报表与 SLA 导出（****/api/v1/analytics/*****）**：路由至独立的“报表计算目标组”，避免大数据量导出挤占核心工单处理资源。
|
||
- **第三方 Webhook 告警接入（****/api/v1/webhooks/*****）**：将来自 Zabbix、Datadog 或 Prometheus 的突发高并发告警流量，直接路由至注册为目标的 **AWS Lambda 函数**，利用 Serverless 自动弹性扩容，无须维持大规模常驻服务器。
|
||
- **安全防护与身份认证**：
|
||
- **TLS 终止与安全防护**：ALB 绑定 AWS Certificate Manager (ACM) 证书统一处理 HTTPS 解密，并在 ALB 侧挂载 **AWS WAF**，防御针对 ITSM 系统的 SQL 注入和 XSS 攻击。
|
||
- **用户身份验证**：对于自助门户访问，利用 ALB 原生集成 OIDC / 企业 SAML 身份验证功能，在流量到达后端服务前完成企业租户的 SSO 身份校验。
|
||
- **独立健康检查与弹性扩展**：
|
||
- 在各个目标组级别配置独立的 HTTP/HTTPS 健康检查（如检查后端服务的 `/healthz` 路径）。
|
||
- 目标组与 Amazon EC2 Auto Scaling 及 ECS 深度绑定，根据各模块的实际负载自动增加或缩减容器/实例节点。
|
||
|
||
---
|
||
|
||
2. 负载均衡算法配置与适用场景
|
||
|
||
ALB 支持在目标组级别配置不同的负载均衡路由算法，针对 ITSM SaaS 各模块的请求耗时特征进行针对性优化：
|
||
|
||
1. **轮询算法（Round Robin，默认）**：
|
||
- **适用模块**：服务自助门户与知识库（`portal.itsm-saas.com`）。
|
||
- **运行机制**：ALB 按照顺序将传入的 HTTP 请求依次分发给目标组内的健康节点。
|
||
- **匹配原因**：员工浏览知识库或提交简单工单的请求通常是无状态且轻量级的，单次请求处理时间相近，使用轮询即可实现均匀的负载分发。
|
||
2. **最少未完成请求算法（Least Outstanding Requests）**：
|
||
- **适用模块**：报表与 SLA 计算服务（`/api/v1/analytics/*`）。
|
||
- **运行机制**：ALB 实时统计每个后端节点当前正在处理的**未完成 HTTP 请求数**，优先将新请求发给当前未完成请求数最少的节点。
|
||
- **匹配原因**：企业客户拉取月度 SLA 报表、执行复杂跨表工单统计的请求计算量极大且耗时较长（可能需要数秒）。如果使用轮询，容易出现多个长耗时请求同时落到同一个节点上，导致该节点 CPU 100% 卡死；采用“最少未完成请求”算法可自动避开繁忙节点，实现动态避峰。
|
||
|
||
---
|
||
|
||
3. 架构与业务效果改善
|
||
|
||
- **计算资源隔离，保障 SLA 稳定性**：通过路径路由将“长耗时报表计算”与“高频事故响应 API”在目标组层级彻底物理隔离，避免某家企业客户导出大报表时拖垮整个 SaaS 平台的工单提交响应。
|
||
- **极佳的突发流量应对能力**：将外部监控系统的 Webhook 告警接口直接挂载至 AWS Lambda 函数，面对监控系统突发投递的大量告警工单时，能够毫秒级弹性响应，避免阻塞正常的 HTTP 访问。
|
||
- **降低系统架构复杂度与运维成本**：无需为自助门户、API 和 Webhook 分别部署多套负载均衡器，单个 ALB 即可完成多域名、多路径、容器与 Serverless 的统一分发。
|
||
- **提高系统容错与自愈能力**：结合目标组独立的健康检查 与 Auto Scaling 机制，一旦某个后端容器因内存溢出等问题导致健康检查失败，ALB 会立即停止向其分发流量，并由自动扩展组补齐新节点，实现客户业务零感知的自愈。 |