产品技术架构
本章概述矩尺平台的核心技术能力。各项功能的详细配置操作请参考"详细操作手册"或"配置指南"中的对应章节。
应用服务均衡场景
L4 负载均衡
在 L4 服务器负载均衡的场景中，矩尺平台负责将客户端的请求转发给服务器，客户端与服务器之间建立 TCP 连接。此时矩尺平台所扮演的角色类似于一台路由器或防火墙，根据 IP 和端口进行流量分发。
L7 负载均衡
基于七层内容的调度机制，管理员可以通过应用层内容来分配服务器资源，实现用户请求调度的多元化和个性化。例如：基于 URI、HOST、Cookie、User-Agent 等 HTTP 头部内容的匹配策略来选择服务器，或通过对 HTTP 头部进行请求改写和应答改写，执行页面跳转和丢弃等操作。在 L7 场景中，矩尺平台先与客户端建立 TCP 连接，获取请求报文后根据应用层内容选择合适的服务器，此时矩尺平台的角色类似于代理服务器。
详细配置参见：快速创建HTTP虚拟服务 | 快速创建TCP虚拟服务
服务器健康检查
矩尺平台通过健康检查判断后端服务的可用性，避免流量分发到不可用的服务器。支持以下方式：
- 基于网络通信状态（ICMP）：通过 Ping 等方式监控服务器运行状况，一旦无回包，实时将请求分配到其他正常服务器
- 基于 L4 协议（TCP/UDP）：通过检查 TCP、UDP 端口的通信情况来确定应用运行状态
- 基于 L7 应用层协议（HTTP/HTTPS/gRPC 等）：发送指定的请求并判断返回值确定应用健康状态
- 基于自定义脚本：通过上传 Python 脚本（类 Go 语法），综合监控服务器状态，满足多条件、关联应用等复杂健康检查需求
此外，服务器池支持绑定多个健康检查策略，策略之间支持 AND（全部通过才算健康）和 OR（任一通过即健康）两种协作模式。高级配置支持上下线分别设置超时、间隔和连续尝试次数，实现"快下线、慢上线"的防震荡策略。
负载均衡算法
矩尺平台支持多种负载均衡算法，所有算法均支持权重配置：
| 算法 | 类型 | 机制 | 适用场景 |
|---|---|---|---|
| 轮询（加权轮询） | 静态 | 按权重循环分配请求到各服务器 | 服务器性能有明确预期 |
| 一致性哈希 | 静态 | 将请求特征值映射到哈希环，分配到环上最近的节点。节点增减时仅影响相邻区间 | 需要会话粘滞的场景（如缓存服务器） |
| 最小连接数（加权） | 动态 | 将请求分配到当前连接数最少的服务器 | 服务器性能差异大，连接保持时长不一 |
| 最快响应 | 动态 | 根据响应时间动态调整权重，响应快的节点分配更多请求 | 服务器性能差异大，对实时性要求高 |
详细配置参见：服务器池用户手册
优先级分组
通过启用优先级分组，可以对服务器池中的节点设置优先级。优先级数字越大等级越高，系统优先将流量分配到高优先级分组中的健康节点。当高优先级节点可用时，不会使用低优先级节点。这一机制是实现故障回退（Fallback） 的核心——主服务器组正常时流量只走主组，主组全部故障时自动切换到备用组。
详细配置参见：服务器池用户手册
温暖上线
将新购置或维护后的服务器加入服务器池时，可以通过温暖上线方式避免新服务器被激增流量冲击。机制分为两个阶段：
- 恢复时间：新服务器上线后，在此时间段内不分配任何流量（默认 0 秒）
- 温暖时间：随后逐步增加分配到该服务器的请求量，使压力缓慢增加到稳定状态
这确保服务器在启动期间以及应用程序初始化时都能提供不间断服务。
详细配置参见：服务器池用户手册
会话保持机制
通过会话保持机制识别客户端与服务器之间交互过程的关联性，保证一系列相关联的请求被分配到同一台服务器。支持六种方式：
| 类型 | 原理 | 适用场景 |
|---|---|---|
| 源地址 | 同一 IP 的请求路由到同一服务器 | 内网系统 |
| Cookie 插入 | 负载均衡在响应中插入 Cookie，后续请求根据 Cookie 路由 | 大多数 Web 应用（推荐） |
| Cookie Hash | 对后端已有的 Cookie 值做哈希分配 | Java 应用（如已有 JSESSIONID） |
| Cookie Passive | 后端服务器生成 Cookie | 需要业务完全控制 Cookie |
| SSL Session ID | 根据 SSL/TLS 会话 ID 保持 | 非 HTTP 的 TLS 加密协议 |
| URI / URL 参数 / Header | 根据请求中的特定值保持 | RESTful API |
支持跨虚拟服务共享会话保持，使 HTTP 和 HTTPS 两个虚拟服务的会话记录互通。
详细配置参见：会话保持配置指南 | 会话保持策略用户手册
源地址转换（SNAT）
源地址转换在客户端访问过程中，将客户端的 IP 地址转换成特定 IP 后再访问真实服务器。此方案既可以保护内网 IP 的安全性，又可以解决设备旁路部署的来回路径不一致问题。支持三种转换方式：
- 转换成设备接口 IP：使用转发引擎物理接口地址
- 转换成虚拟服务 IP：使用虚拟服务的监听 IP 地址
- 转换成自定义地址池 IP：使用预设的 SNAT 地址池中的地址
溯源
设备支持对源地址转换后的客户端进行溯源，保持原有实际源地址的可读性，确保后端服务器能获取真实的客户端 IP：
- X-Forwarded-For：HTTP 协议自带，在 HTTP 扩展头部中插入客户端实际源 IP 地址信息
- Proxy Protocol：在四层末尾和七层开头之间插入客户端实际源 IP 地址信息，适用于 TCP/TCP-SSL 等非 HTTP 协议
详细配置参见：虚拟服务用户手册
SSL 卸载
SSL 卸载技术将应用访问过程中的 SSL 加解密过程转移到矩尺平台，减少服务器端的性能压力，提升客户端访问响应速度。矩尺平台具备以下 SSL 能力：
- 端到端 SSL 加密，支持单向认证和双向认证（mTLS）
- 全面的加密算法配置，支持国际标准算法和国密算法（SM2/SM3/SM4）
- SSL Session 缓存和 Session Ticket 两种会话复用机制，减少重复握手开销
- 服务器证书管理和过期预警
详细配置参见：快速创建HTTPS虚拟服务 | 国密配置与验证 | SSL 策略用户手册
分发策略与分发规则
在同一个虚拟服务内，可以创建多条具备不同优先级（高/中/低）的分发规则，每条分发规则可以指定请求路由到不同的服务器池，亦或是返回重定向响应、返回静态资源、返回指定错误码等。每条分发规则包含多条分发策略，分发策略基于源地址、URL、HOST、Cookie、Header、Method 等请求信息生效。
规则匹配遵循三层裁决模型：规则优先级 → URL 类型优先级（正则 > 完全匹配 > 前缀匹配）→ 配置先后顺序。未命中任何规则的请求由默认分发规则兜底处理。
详细配置参见：分发规则匹配逻辑详解 | 分发策略用户手册
应用性能优化
TCP 连接复用
将众多客户端请求捆绑处理，通过将前端多个 HTTP 请求复用到与后端服务器建立的一个 TCP 连接上，减少新建 TCP 连接带来的延迟，最大限度地降低客户端请求对后端服务器并发连接数的需求。
HTTP 压缩
通过标准的 HTTP 压缩技术对指定内容进行 GZIP 或 Brotli 压缩，在不增加额外网络带宽的情况下加快用户响应速度，提高整体系统性能。同时支持预压缩功能——提前压缩好文件（.gz / .br），平台直接传输，节省实时压缩的 CPU 开销。
详细配置参见：七层策略用户手册 | 静态资源托管服务配置
以上各项技术能力的详细操作和配置方法，请分别参考 "详细操作手册"（菜单结构）和 "配置指南"（场景化教程）中的对应章节。