好的，各位观众老爷们，大家好！我是今天的主讲人，人称“码农界的段子手”，今天咱们聊聊 GCP Cloud Load Balancing 家族里一位低调但实力强劲的成员：内部 TCP/UDP 负载均衡器，以及它身上自带的“会话亲和性”技能。
先别急着打瞌睡，我知道负载均衡听起来就挺枯燥的，但今天我保证，用最接地气的方式，把这些技术概念掰开了揉碎了讲清楚，让大家听得懂、用得上，还能乐得合不拢嘴。
一、啥是内部 TCP/UDP 负载均衡器？（别告诉我你只知道 HTTP）
咱们先来聊聊负载均衡器。如果把你的应用程序比作一家餐厅，那么负载均衡器就是门口的迎宾员，负责把顾客（流量）均匀地分配给不同的餐桌（后端服务器）。
HTTP 负载均衡器，大家可能比较熟悉，它专门处理 HTTP/HTTPS 协议的流量，也就是咱们平时用浏览器上网的那些东西。但除了 HTTP，还有很多应用使用 TCP 和 UDP 协议，比如游戏、数据库、音视频流等等。这时候，就需要内部 TCP/UDP 负载均衡器出马了。
- 内部：顾名思义，它只在你的 VPC 网络内部工作，不对外开放。想象一下，你的餐厅有一个VIP包间，只有内部员工和邀请的贵宾才能进入，这个包间就是内部负载均衡器的作用范围。
- TCP/UDP：它支持 TCP 和 UDP 两种传输层协议。TCP 就像打电话，需要先建立连接，保证数据可靠传输；UDP 就像发短信，直接发送，速度快，但不保证一定能送达。
- 负载均衡：它能把流量均匀地分配给后端多个虚拟机实例或容器，防止某个服务器过载，保证应用的稳定性和可用性。
二、为啥要用内部 TCP/UDP 负载均衡器？（好处多到数不过来）
你可能会问，我的应用流量不大，直接用一个服务器不就行了吗？何必搞这么复杂？
少年，格局要大！随着业务发展，流量肯定会越来越多，单台服务器迟早会扛不住。这时候，内部 TCP/UDP 负载均衡器的优势就体现出来了：
- 高可用性：如果后端某个服务器挂了，负载均衡器会自动把流量切换到其他健康的服务器上，保证应用不中断。就像餐厅里，如果一个厨师生病了，其他厨师可以顶上，保证菜品供应。
- 可扩展性：随着流量增加，你可以随时添加新的后端服务器，负载均衡器会自动把流量分配给它们，实现无缝扩展。就像餐厅扩建，增加餐桌，可以容纳更多的顾客。
- 安全性：内部负载均衡器只允许 VPC 网络内部的流量访问后端服务器，可以有效防止外部攻击。就像餐厅的VIP包间，只有授权的人才能进入，保证安全。
- 流量管理：负载均衡器可以根据不同的算法（比如轮询、加权轮询、最小连接数等）分配流量，实现更精细的流量控制。就像餐厅的服务员，可以根据顾客的需求，把他们安排到不同的餐桌。
用表格总结一下：
| 优点 | 描述 | 形象比喻 |
|---|---|---|
| 高可用性 | 自动故障转移，保证应用不中断 | 厨师生病了，其他厨师顶上 |
| 可扩展性 | 随时添加新的后端服务器，实现无缝扩展 | 餐厅扩建，增加餐桌 |
| 安全性 | 只允许 VPC 网络内部的流量访问，防止外部攻击 | VIP包间，只有授权的人才能进入 |
| 流量管理 | 根据不同算法分配流量，实现精细控制 | 服务员根据顾客需求安排餐桌 |
三、会话亲和性：让老顾客永远找到熟悉的味道
重头戏来了！会话亲和性（Session Affinity），又称粘性会话（Sticky Session），是内部 TCP/UDP 负载均衡器的一项重要功能。
想象一下，你的应用程序需要维护用户的会话状态，比如购物车信息、登录状态等等。如果每次请求都被分配到不同的后端服务器，那么用户就需要频繁地重新登录、重新添加购物车，体验非常糟糕。
会话亲和性的作用就是，让来自同一个客户端的请求，始终被路由到同一个后端服务器，保证会话状态的连续性。就像餐厅的熟客，每次来都坐在同一个位置，点同样的菜，享受熟悉的服务。
会话亲和性是如何实现的呢？
内部 TCP/UDP 负载均衡器主要通过以下两种方式实现会话亲和性：
-
客户端 IP 地址：根据客户端的 IP 地址，将来自同一个 IP 地址的请求路由到同一个后端服务器。这种方式简单粗暴，但也有一些缺点，比如如果多个用户共享同一个 IP 地址（比如通过 NAT），那么他们会被路由到同一个服务器。
-
客户端 IP 地址和端口：这种方式比只使用 IP 地址更精细，可以区分来自同一个 IP 地址的不同用户。
会话亲和性的配置方法
在 GCP Console 上配置会话亲和性非常简单，只需要在创建内部 TCP/UDP 负载均衡器时，选择相应的亲和性类型即可。
- 进入 GCP Console，找到 Cloud Load Balancing。
- 创建内部 TCP/UDP 负载均衡器。
- 在后端配置中，选择会话亲和性类型（客户端 IP 地址或客户端 IP 地址和端口）。
- 完成其他配置，创建负载均衡器。
四、会话亲和性的优缺点（没有完美的技术，只有最合适的选择）
会话亲和性虽然能保证会话状态的连续性，但也有一些缺点，需要根据实际情况权衡利弊：
优点：
- 保证会话状态的连续性，提升用户体验。
- 简化应用程序的开发，不需要考虑会话状态的同步问题。
缺点：
- 可能导致流量分配不均匀，某些服务器负载过高。如果某个服务器上的用户数量特别多，那么它可能会成为瓶颈。
- 如果某个服务器挂了，那么它上面的所有会话都会丢失。就像餐厅的某个餐桌坏了，那么坐在上面的顾客就要换位置，重新点菜。
用表格总结一下：
| 优点 | 描述 | 形象比喻 |
|---|---|---|
| 保证会话状态 | 提升用户体验，简化开发 | 熟客每次都坐在同一个位置，点同样的菜 |
| 缺点 | 可能导致流量不均，服务器挂掉会丢失会话 | 某个餐桌顾客太多，服务员忙不过来；餐桌坏了，顾客要换位置重新点菜 |
五、会话亲和性的适用场景（不是所有场景都适用）
会话亲和性并不是万能的，只有在某些特定场景下才能发挥作用：
- 需要维护会话状态的应用：比如购物车、登录状态、游戏进度等等。
- 后端服务器之间没有会话共享机制的应用：如果后端服务器之间可以共享会话状态（比如通过 Redis、Memcached 等），那么就不需要会话亲和性。
六、替代方案：会话共享（让所有服务器都能记住你的喜好）
如果你的应用需要高可用性和可扩展性，同时又需要维护会话状态，那么可以考虑使用会话共享的方案。
会话共享是指将用户的会话状态存储在一个集中的存储系统中，比如 Redis、Memcached、数据库等等。这样，无论请求被路由到哪个后端服务器，都可以从存储系统中获取用户的会话状态。
会话共享的优点是：
- 提高可用性：即使某个服务器挂了，会话状态也不会丢失。
- 提高可扩展性：可以随时添加新的服务器，而不需要担心会话状态的问题。
- 实现更灵活的流量分配：可以根据服务器的负载情况，动态地调整流量分配。
会话共享的缺点是：
- 增加复杂性：需要额外的存储系统和维护成本。
- 可能存在性能瓶颈：如果存储系统性能不足，可能会影响应用的响应速度。
七、实战演练：用 Terraform 部署内部 TCP/UDP 负载均衡器
光说不练假把式，咱们来用 Terraform 实际部署一个内部 TCP/UDP 负载均衡器，加深理解。
以下是一个简单的 Terraform 配置示例：
resource "google_compute_address" "internal_ip" {
name = "internal-lb-ip"
address_type = "INTERNAL"
prefix_length = 16
network = "default" # 替换为你的 VPC 网络
region = "us-central1" # 替换为你的区域
}
resource "google_compute_health_check" "default" {
name = "tcp-health-check"
tcp_health_check {
port = 80 # 替换为你的应用端口
}
}
resource "google_compute_instance_group" "default" {
name = "instance-group"
zone = "us-central1-a" # 替换为你的可用区
instances = [
"instance-1", # 替换为你的虚拟机实例名称
"instance-2",
]
}
resource "google_compute_backend_service" "default" {
name = "backend-service"
protocol = "TCP"
health_checks = [google_compute_health_check.default.id]
backend {
group = google_compute_instance_group.default.id
balancing_mode = "CONNECTION"
}
}
resource "google_compute_forwarding_rule" "default" {
name = "forwarding-rule"
ip_protocol = "TCP"
port_range = "80-80" # 替换为你的应用端口
target = google_compute_backend_service.default.id
load_balancing_scheme = "INTERNAL"
network = "default" # 替换为你的 VPC 网络
ip_address = google_compute_address.internal_ip.address
region = "us-central1" # 替换为你的区域
}这个配置做了以下几件事：
- 创建了一个内部 IP 地址，用于负载均衡器。
- 创建了一个健康检查，用于检测后端服务器的健康状态。
- 创建了一个实例组，包含了后端服务器。
- 创建了一个后端服务，将实例组和健康检查关联起来。
- 创建了一个转发规则，将流量转发到后端服务。
运行 terraform apply 命令，就可以自动部署内部 TCP/UDP 负载均衡器了。
八、总结：选择最适合你的负载均衡方案
今天咱们深入探讨了 GCP Cloud Load Balancing 的内部 TCP/UDP 负载均衡器，以及会话亲和性这个重要功能。
记住，没有最好的技术，只有最适合你的技术。在选择负载均衡方案时，要综合考虑以下因素：
- 应用的协议类型（HTTP、TCP、UDP 等）
- 是否需要对外开放（内部或外部）
- 是否需要维护会话状态
- 对可用性和可扩展性的要求
- 预算和维护成本
希望今天的分享能帮助大家更好地理解和使用 GCP Cloud Load Balancing，打造更加稳定、高效、安全的应用程序。
最后，感谢大家的观看，如果觉得有用，记得点赞、评论、转发哦！咱们下期再见！ 😜