阿里云——应用交付与负载均衡

应用交付与负载均衡

在分布式架构中，单一实例无法承受高并发流量，也存在单点故障风险。负载均衡（Load Balancing） 是解决这些问题的核心手段，它像一位经验丰富的交通指挥官，将涌入的用户请求智能地分发到后端多台健康的服务器上，从而实现高并发、高可用的服务能力。

6.1 负载均衡（SLB）：四层（CLB）与七层（ALB/NLB）深度对比

阿里云负载均衡（SLB）是一个统称，其下包含三种不同定位的产品，理解它们的区别是正确选型的关键。

传统型负载均衡（CLB - Classic Load Balancer）：
- 工作层级 ：主要基于四层（TCP/UDP） ，部分支持七层（HTTP/HTTPS）。
- 核心特点 ：
  - 性能强劲：采用集群部署，支持超高性能（每秒千万级并发连接）。
  - 功能全面：支持TCP/UDP/HTTP/HTTPS协议，具备基础的四层和七层转发能力。
  - 静态部署：监听器（Listener）和后端服务器组（Server Group）是强绑定关系，配置相对固定。
- 适用场景：对性能要求极高的四层流量转发、传统的七层Web应用、SSL卸载。
应用型负载均衡（ALB - Application Load Balancer）：
- 工作层级 ：基于七层（HTTP/HTTPS/QUIC），是CLB在七层功能的增强版。
- 核心特点 ：
  - 高级路由 ：支持基于域名、URL路径、HTTP头、查询参数、HTTP方法等丰富条件的转发规则，可精细化路由到不同后端应用。
  - 面向应用：概念上更贴近"应用"，与微服务架构天然契合。
  - 自动弹性：无需选择规格，容量可自动弹性伸缩。
  - 强大的可观测性：原生集成ARMS，提供丰富的七层监控指标（如QPS、RT、状态码）。
- 适用场景：微服务网关、容器Ingress、灰度发布、多后端服务路由（如/api路由到Java服务，/static路由到OSS）。
网络型负载均衡（NLB - Network Load Balancer）：
- 工作层级 ：基于四层（TCP/UDP/TLS），是CLB在四层功能的增强版。
- 核心特点 ：
  - 超高性能：支持超高性能（亿级并发，千万级PPS）和超低延迟。
  - 地址透传：支持保留客户端源IP地址，无需使用Proxy Protocol。
  - 双栈支持：原生支持IPv6。
- 适用场景：游戏服务器、物联网（IoT）大并发长连接、金融级实时交易、TCP/UDP协议转发。

选择指南总结表：

特性	CLB (传统型)	ALB (应用型)	NLB (网络型)
协议支持	TCP/UDP/HTTP/HTTPS	HTTP/HTTPS/QUIC	TCP/UDP/TLS
性能焦点	高并发	灵活路由	超高性能 & 超低延迟
核心优势	功能全面，稳定可靠	高级路由，微服务友好	极致四层性能，地址透传
典型场景	通用Web负载均衡	微服务、容器Ingress	游戏、物联网、金融交易

对于全新的现代化应用，应优先考虑ALB和NLB。ALB提供了无与伦比的七层流量治理灵活性，非常适合微服务架构；NLB则提供了极致的四层性能。CLB则更适合传统架构或对协议有混合要求的场景。

6.2 全局负载均衡：云解析DNS（Alibaba Cloud DNS）实现跨地域容灾

SLB解决了单一地域内的高可用问题。但如果整个地域发生重大故障（如自然灾害、大规模运营商故障）怎么办？这时就需要全局负载均衡（Global Server Load Balancing, GSLB）。

阿里云云解析DNS（Alibaba Cloud DNS） 提供了基于DNS的GSLB能力。

实现原理：

你在不同地域（如上海、深圳）部署了完全相同的应用集群，并各自创建了SLB。
在云解析DNS中，为你的域名（如www.example.com）添加两条A记录，分别指向上海和深圳SLB的公网IP。
为这两条记录启用解析线路 和健康检查 功能：
- 智能解析 ：配置"默认"线路，设置主备优先级。例如，上海IP为主，深圳IP为备。
- 健康检查：云解析DNS会定期向后端SLB的IP发送健康检查请求（如HTTP请求），探测其健康状态。

故障转移流程：

当云解析DNS检测到上海SLB 的健康检查失败（意味着上海整个集群异常）时，它会自动将DNS解析结果从上海的IP切换到健康的深圳SLB的IP。
后续所有用户对www.example.com的域名解析请求，都会得到深圳的IP地址。
尽管切换需要一定时间（受DNS TTL影响），但这实现了地域级别的容灾，保证了业务的最终可用性。

如何利用SLB和DNS设计跨可用区的故障转移方案

这是一个经典的"两地三中心"容灾架构的简化版：

同城高可用（Multi-AZ） ：在一个地域内，将多台ECS部署在不同可用区 的VSwitch中，并挂载到同一个SLB后端服务器组。SLB的健康检查会自动剔除故障可用区的异常ECS，实现同城容灾。
异地容灾（Multi-Region） ：在另一个地域部署一套完整的应用，并通过云解析DNS 的智能解析和健康检查功能，与主地域构成主备关系，实现异地容灾。

6.3 应用发布与部署：实战Serverless应用引擎（SAE）

Serverless应用引擎（SAE）是一款极富竞争力的全托管 、Serverless 化的应用托管平台。它真正实现了无需管理服务器（IaaS）和 Kubernetes 集群（CaaS），专注于应用本身的设计与开发。

SAE 的核心价值：

零基础设施管理：无需管理 ECS 或 Kubernetes Worker 节点，无需关心服务器运维、安全补丁、容量规划。
极致弹性 ：支持多种弹性策略：
- 定时弹性：在指定时间进行扩容/缩容。
- 指标弹性（HPA）：根据 CPU、内存、QPS 等指标自动扩缩容。
- 混合弹性：可弹性调用 ECIs，轻松应对突发流量，避免资源闲置。
微服务原生：无缝集成 MSE 微服务治理组件（如 Nacos），提供无损上下线、服务鉴权、灰度发布等能力。
成本优化 ：按应用实例运行时所消耗的 CPU 和内存资源量进行计费。在实例缩容到 0 时，不产生任何费用。

实战演练：将 Spring Boot 应用部署到 SAE

目标：将一个简单的 Spring Boot Jar 包应用部署到 SAE，并通过公网访问。

步骤一：应用配置与打包

确保你的 Spring Boot 应用在 application.properties 中配置了 server.port=8080（SAE 默认通过 8080 端口进行健康检查）。
使用 mvn clean package 将应用打包成一个可执行的 Jar 包。

步骤二：在 SAE 控制台创建应用

登录 SAE 控制台，点击"创建应用"。
应用基本信息 ：
- 应用名称：demo-springboot-app。
- 命名空间：选择默认命名空间。
应用部署方式：选择"JAR 包部署"，上传刚才打包好的 Jar 文件。
应用实例配置 ：
- 实例规格：选择例如 2 CPU核，4 GiB 内存。
- 实例数量：设置应用初始实例数，例如 2 个实例以实现高可用。
网络配置 ：选择我们之前创建的 prod-vpc 和对应的 VSwitch。非常重要：必须与应用需要访问的其他资源（如 RDS、Redis）处于同一 VPC 内，才能通过内网连接。
高级设置 ：
- 健康检查 ：SAE 默认会通过 :8080/actuator/health 路径进行健康检查，确保你的应用包含 Spring Boot Actuator 依赖。
点击"确认"，开始创建应用。SAE 会自动为你创建资源并拉取 Jar 包启动应用。

步骤三：配置公网访问

应用创建成功后，在"应用详情"页面，切换到"访问配置"标签页。
点击"绑定 SLB"，在公网访问标签下，选择一个已有的 SLB 或新建一个。SAE 会自动为你配置监听端口（如将 SLB 的 80 端口映射到应用实例的 8080 端口）。
绑定成功后，你会获得一个 SLB 的公网 IP 地址。

步骤四：访问应用

在浏览器中输入得到的公网 IP 地址，即可访问你的 Spring Boot 应用。

架构价值：

简化运维：你完全不需要管理底层服务器，只需关心应用代码和 SAE 的配置。
成本效益：在流量低谷时，你可以将实例数缩容到 1 甚至 0，大幅节省成本。
内置高可用：通过配置多个实例，SAE 会自动将实例分散到不同可用区，并提供健康检查与自动恢复。

通过本章，掌握了如何将后端服务高效、可靠地暴露给用户。从精细的流量路由到全局的容灾设计，再到革命性的应用部署方式，应用交付是连接用户与服务的最后一座桥梁，其设计的好坏直接决定了用户体验。