Cân bằng tải & Gateway

🎯 Câu hỏi cốt lõi

Khi một máy chủ không thể chịu nổi, làm thế nào để phân phối lưu lượng một cách "thông minh" đến nhiều instance máy chủ? Cân bằng tải là "người điều phối" của hệ thống phân tán hiện đại. Bài viết này thông qua các tình huống thực tế (thu ngân quán trà sữa, phân loại chuyển phát nhanh, chỉ huy giao thông) giúp hiểu sâu về triết lý thiết kế và thực tiễn kỹ thuật của cân bằng tải.

1. Tại sao cần "cân bằng tải"?

1.1 Bắt đầu từ một tình huống thực tế: quá trình phát triển kiến trúc của một website

Một công ty khởi nghiệp đã gặp vấn đề hiệu suất nghiêm trọng khi số lượng người dùng tăng nhanh:

Tình huống thực tế:

Giai đoạn 1: Máy chủ đơn
Người dùng → Máy chủ (1 nhân 2G)
       ↓
      DAU 1000 → Giờ cao điểm: 1000 người cùng truy cập
       ↓
   Vấn đề: CPU 100%, phản hồi chậm, thường xuyên sập

⚠️ Vấn đề chết người của máy chủ đơn

Nút thắt hiệu suất: CPU 100%, thời gian phản hồi > 5 giây
Điểm lỗi đơn: Máy chủ sập, toàn bộ website không khả dụng
Khó mở rộng: Chỉ có thể nâng cấp dọc (thêm CPU, RAM), đắt đỏ và có giới hạn

Kiến trúc cải tiến (có cân bằng tải):

Giai đoạn 2: Nhiều máy chủ + Cân bằng tải
Người dùng → Cân bằng tải (Nginx)
       ↓
     ├→ Máy chủ 1 (1 nhân 2G)
     ├→ Máy chủ 2 (1 nhân 2G)
     └→ Máy chủ 3 (1 nhân 2G)

✨ Hiệu quả sau khi cải tiến

Nâng cao hiệu suất: 3 máy chủ xử lý song song, thời gian phản hồi < 1 giây
Tính sẵn sàng cao: 1 máy chủ sập, các máy khác vẫn phục vụ
Mở rộng ngang: Cần thêm hiệu suất? Cứ thêm máy chủ

1.2 Ẩn dụ đời sống về cân bằng tải

Quầy thu ngân quán trà sữa

Hãy tưởng tượng bạn mở một quán trà sữa nổi tiếng:

1 quầy thu ngân: Khách xếp hàng, người phía sau không chờ nổi, đánh giá kém
3 quầy thu ngân: Nhân viên phân bổ khách đến các quầy khác nhau, hiệu suất tăng gấp 3

Cân bằng tải chính là "người phân bổ quầy thu ngân":

Người dùng (khách hàng) → Yêu cầu dịch vụ
Cân bằng tải (người phân bổ) → Phân phối yêu cầu đến các máy chủ khác nhau
Máy chủ (quầy thu ngân) → Xử lý yêu cầu

传统架构单点

🖥️

Web Server

负载: 95% 🔥

→

负载均衡架构分布式

⚖️L4 Load Balancer

🖥️

📦四层负载均衡 (L4)

工作原理

基于传输层信息（IP地址+端口）进行流量分发。不关心应用层内容，只做"快递分拣"，因此性能极高。

典型产品

LVS (Linux Virtual Server)HAProxy (TCP模式)AWS NLBAzure Load Balancer

适用场景

需要极高吞吐量的场景
TCP/UDP流量分发
不需要内容识别的场景
微服务间通信

性能对比一览

类型

处理层

性能

灵活性

成本

硬件负载均衡

L4/L7

$$$$$

四层负载均衡

L4 (传输层)

七层负载均衡

L7 (应用层)

$$$

软件负载均衡

L4/L7

2. Cân bằng tải là gì?

2.1 Cân bằng tải lớp 4 (L4): Chỉ xem số nhà

Hoạt động ở tầng vận chuyển (TCP/UDP), giống như nhân viên chuyển phát chỉ xem số nhà (địa chỉ IP + số cổng) của bạn, không quan tâm nhà bạn làm gì.

Đặc điểm:

Tốc độ cực nhanh: Chỉ chuyển tiếp địa chỉ đơn giản, không phân tích nội dung gói tin
Tình huống phù hợp: Kết nối cơ sở dữ liệu, Redis cache, máy chủ game kết nối dài
Sản phẩm tiêu biểu: LVS (Linux Virtual Server), AWS NLB, Azure Load Balancer

Nguyên lý hoạt động

Yêu cầu client → Cân bằng tải L4 → Máy chủ backend
              ↓
         Chỉ xem IP + Port
              ↓
         Chuyển tiếp nhanh (không giải nén nội dung)

2.2 Cân bằng tải lớp 7 (L7): Kiểm tra nội dung gói hàng

Hoạt động ở tầng ứng dụng (HTTP/HTTPS), giống như nhân viên chuyển phát không chỉ xem số nhà mà còn mở gói hàng kiểm tra nội dung, dựa vào nội dung để quyết định cách giao.

Đặc điểm:

Định tuyến thông minh: Có thể định tuyến tinh vi dựa trên đường dẫn URL, HTTP Header, Cookie, v.v.
Tính năng nâng cao: SSL offloading, cache nội dung, nén, WAF bảo mật
Tình huống phù hợp: Ứng dụng Web, API Gateway, kiến trúc microservice
Sản phẩm tiêu biểu: Nginx, HAProxy, AWS ALB, Envoy

Nguyên lý hoạt động

Yêu cầu client → Cân bằng tải L7 → Phân tích nội dung HTTP
              ↓
         Kiểm tra URL, Header, Cookie
              ↓
         Định tuyến thông minh đến máy chủ cụ thể

2.3 So sánh L4 vs L7

Khía cạnh	Cân bằng tải lớp 4 (L4)	Cân bằng tải lớp 7 (L7)
Tầng hoạt động	Tầng vận chuyển (TCP/UDP)	Tầng ứng dụng (HTTP/HTTPS)
Căn cứ quyết định	Địa chỉ IP + số cổng	URL, Header, Cookie, Body
Tốc độ xử lý	Cực nhanh (xử lý kernel)	Nhanh (phân tích user-space)
Mức độ phong phú	Chuyển tiếp cơ bản	SSL offloading, cache, nén, WAF
Tình huống điển hình	CSDL, game, kết nối dài	Ứng dụng Web, API Gateway, microservice
Sản phẩm tiêu biểu	LVS, AWS NLB	Nginx, HAProxy, AWS ALB

3. Vấn đề cốt lõi 1: Làm thế nào để tránh máy chủ "hỏng" vẫn nhận khách?

3.1 Kiểm tra sức khỏe: Đừng để máy chủ "ốm" kéo cả hệ thống xuống

Hãy tưởng tượng, một quầy thu ngân của bạn đột nhiên hỏng, nhưng người phân bổ không biết, vẫn liên tục đưa khách đến đó. Kết quả là hàng đợi ngày càng dài, khách hàng phàn nàn không ngớt.

Kiểm tra sức khỏe (Health Check) chính là "lính gác" ngăn chặn tình huống này. Nó định kỳ "khám sức khỏe" mỗi máy chủ, phát hiện máy "ốm" thì lập tức loại khỏi hàng đợi, đợi "khỏe lại" thì mời quay về.

3.2 Kiểm tra sức khỏe chủ động vs Kiểm tra sức khỏe thụ động

Kiểm tra sức khỏe chủ động (Active Health Check): Cân bằng tải chủ động "gõ cửa" hỏi máy chủ "bạn còn ở đó không?"

Định kỳ gửi yêu cầu thăm dò (như HTTP /health, TCP ping)
Phản hồi quá thời gian hoặc trả về mã lỗi thì coi là không khỏe
Ưu điểm: Kết quả phát hiện chính xác và đáng tin cậy
Nhược điểm: Tạo ra lưu lượng thăm dò bổ sung

Kiểm tra sức khỏe thụ động (Passive Health Check): Cân bằng tải "quan sát" tình trạng phản hồi của lưu lượng nghiệp vụ thực tế

Thống kê thời gian phản hồi, tỷ lệ lỗi của các yêu cầu thực tế
Liên tục thất bại nhiều lần thì coi là không khỏe
Ưu điểm: Không tạo thêm lưu lượng
Nhược điểm: Cần đủ mẫu lưu lượng mới có thể phán đoán

Bảng thiết lập ngưỡng

Chỉ số	Ngưỡng khỏe	Ngưỡng không khỏe	Ghi chú
HTTP status code	200-399	400+ hoặc timeout	4xx/5xx đều coi là thất bại
Kết nối TCP	Thiết lập thành công	Kết nối timeout	Kiểm tra cổng có thể truy cập không
Thời gian phản hồi	< 500ms	> 2000ms	Thời gian timeout thường đặt 2-5 giây
Số lần thất bại liên tiếp	-	3 lần	Tránh phán đoán sai do dao động nhất thời
Khoảng kiểm tra	-	5s	Quá thường xuyên sẽ tăng tải

💡 Hố thường gặp: Ngưỡng thiết lập quá "nhạy cảm"

Một nhóm đã đặt ngưỡng thời gian phản hồi của health check là 100ms, trong khi thời gian phản hồi trung bình của ứng dụng dao động từ 80-120ms. Kết quả là máy chủ thường xuyên bị đánh dấu là "không khỏe", dẫn đến lưu lượng dao động liên tục giữa trạng thái khỏe và không khỏe, tỷ lệ khả dụng tổng thể của hệ thống lại giảm.

Cách làm đúng: Ngưỡng nên được đặt là 2-3 lần P99 thời gian phản hồi, để lại đủ không gian đệm cho dao động bình thường.

4. Vấn đề cốt lõi 2: Làm thế nào để "khách quen" luôn gặp cùng một "thu ngân"?

4.1 Duy trì phiên: Để "khách quen" luôn gặp cùng một "thu ngân"

Hãy tưởng tượng bạn là khách quen của quán trà sữa, mỗi lần đến đều do cùng một nhân viên phục vụ. Cô ấy biết sở thích của bạn (nửa đường, không đá), phục vụ vừa nhanh vừa chu đáo. Nhưng nếu mỗi lần đến đều đổi người mới, bạn phải lặp đi lặp lại cùng một yêu cầu, hiệu suất giảm đáng kể.

Duy trì phiên (Session Persistence/Sticky Session) chính là giải pháp cho vấn đề này: đảm bảo yêu cầu của cùng một người dùng luôn được định tuyến đến cùng một máy chủ backend.

应用场景：

👤

用户A

👥

用户B

👨‍💼

用户C

请求

↓

⚖️负载均衡器

🍪

Cookie 插入

通过HTTP Cookie保持会话

会话映射表

sess_abc123→Server 1

sess_def456→Server 2

sess_ghi789→Server 1

↓

🖥️

Server 1

10.0.1.10

✓

选中

🖥️

Server 2

10.0.1.11

✓

🖥️

Server 3

10.0.1.12

✗

↑

三种会话保持机制对比

🍪Cookie 插入

✓不受客户端IP变化影响

✓首次请求即可保持会话

✗客户端需支持Cookie

✗存在Cookie被禁用的风险

#️⃣IP Hash

✓无需客户端支持任何机制

✓无状态，LB重启不影响会话

✗客户端IP变化会丢失会话

✗难以做到真正的负载均衡

📝粘性会话

✓结合Cookie和IP两种方式优势

✓支持会话复制和故障转移

✗实现复杂，需要应用支持

✗会话复制带来性能开销

4.2 So sánh ba cơ chế duy trì phiên

Cơ chế	Nguyên lý thực hiện	Ưu điểm	Nhược điểm	Tình huống phù hợp
Cookie chèn	LB chèn Cookie vào phản hồi, yêu cầu tiếp theo mang Cookie này	Không bị ảnh hưởng bởi IP thay đổi, duy trì ngay từ yêu cầu đầu	Client phải hỗ trợ Cookie, có thể bị tắt	Giỏ hàng thương mại điện tử, duy trì trạng thái đăng nhập
IP Hash	Hash địa chỉ IP của client, ánh xạ đến máy chủ cụ thể	Không cần client hỗ trợ, không trạng thái	IP thay đổi sẽ mất phiên, khó phân phối đều	Môi trường không Cookie, WebSocket
Bảng session dính	LB duy trì bảng ánh xạ session đến máy chủ	Hỗ trợ sao chép session và chuyển đổi dự phòng	Chiếm bộ nhớ LB, cần đồng bộ thêm	Tình huống yêu cầu tính sẵn sàng cao nghiêm ngặt

💡 Khuyến nghị sử dụng

Cookie chèn: Ưu tiên khuyến nghị, khả năng tương thích tốt
IP Hash: Chỉ dùng cho các tình huống đặc biệt như WebSocket
Bảng session dính: Kết hợp với Cookie, cung cấp khả năng chuyển đổi dự phòng

5. Vấn đề cốt lõi 3: Làm thế nào để triển khai không downtime?

5.1 Triển khai xanh-lam: Phát hành không downtime với "chuyển đổi một chạm"

Tư tưởng cốt lõi: Duy trì đồng thời hai môi trường sản xuất hoàn toàn giống nhau (môi trường xanh và môi trường lam), nhưng chỉ một môi trường phục vụ bên ngoài.

🔵

蓝环境

v1.0.0

100% 流量

🟢

绿环境

v1.1.0

0% 流量

用户流量

👤

↓

⚖️

负载均衡器

当前指向: 🔵 蓝环境

↓

🔵蓝环境v1.0.0

🖥️B1●

🖥️B2●

🖥️B3●

🟢绿环境v1.1.0

🖥️G1●

🖥️G2●

🖥️G3●

蓝绿部署流程

绿环境部署

在绿环境部署新版本，进行冒烟测试

→

切换流量

将负载均衡器指向绿环境，流量瞬间切换

→

监控观察

观察绿环境运行状态，确认无异常

→

蓝环境升级

在蓝环境部署新版本，为下次切换做准备

蓝绿部署优缺点

✅优点

零停机时间：流量切换在毫秒级完成，用户无感知
快速回滚：发现问题可立即切回原环境，风险可控
完整的预发布测试：新环境可完整测试后再接管流量
数据一致性：无需处理新旧版本同时运行时的兼容问题

❌缺点

资源成本高：需要同时维护两套完整环境，服务器成本翻倍
数据库兼容性挑战：如果涉及数据库Schema变更，需要特别处理兼容性
预热问题：新环境启动后可能需要时间预热缓存、连接池等
不适合有状态服务：对于长连接、会话保持要求高的场景处理复杂

Quy trình làm việc:

Trạng thái ban đầu: Môi trường lam chạy v1.0 (production), môi trường xanh chờ lệnh.
Triển khai phiên bản mới: Triển khai v1.1 lên môi trường xanh, thực hiện smoke test nội bộ.
Chuyển đổi lưu lượng: Trỏ cân bằng tải đến môi trường xanh, lưu lượng chuyển ngay lập tức sang v1.1.
Giám sát quan sát: Quan sát trạng thái hoạt động của môi trường xanh, xác nhận không có bất thường.
Giữ lại phiên bản cũ: Môi trường lam giữ v1.0 một thời gian (như 24 giờ), làm bảo hiểm rollback nhanh.

✨ Phân tích ưu nhược điểm

Ưu điểm	Nhược điểm
✅ Không downtime, chuyển đổi trong mili giây	❌ Chi phí tài nguyên cao, cần duy trì đồng thời hai môi trường
✅ Rollback nhanh, phát hiện vấn đề lập tức chuyển về môi trường cũ	❌ Thay đổi Schema CSDL cần xử lý đặc biệt về tương thích
✅ Môi trường mới có thể kiểm thử đầy đủ trước khi nhận lưu lượng	❌ Không phù hợp cho dịch vụ có trạng thái (như WebSocket kết nối dài)

5.2 Phát hành canary: Chiến lược "bước nhỏ chạy nhanh"

Phát hành canary lấy tên từ "chim hoàng yến trong mỏ than" lịch sử — thợ mỏ mang chim hoàng yến xuống mỏ, nếu chim có dấu hiệu bất thường nghĩa là có khí độc rò rỉ, thợ mỏ lập tức sơ tán. Trong phát hành phần mềm, phát hành canary là cho một nhóm nhỏ người dùng dùng thử phiên bản mới trước, quan sát không có vấn đề rồi mới mở rộng dần phạm vi.

流量分配比例拖动滑块调整新旧版本流量占比

稳定版 v1.0.090%

金丝雀 v1.1.010%

实时流量模拟总请求: 0 | 稳定版: 0 | 金丝雀: 0

用户请求

→

负载均衡器

⚖️

Canary:10%

→

后端服务

稳定版 v1.0.0

📦S1

📦S2

📦S3

金丝雀 v1.1.0

🧪C1

🧪C2

金丝雀发布最佳实践

📊渐进式放量

1% → 5% → 10% → 25% → 50% → 100%
每个阶段观察至少15-30分钟
关键指标：错误率、延迟、吞吐量

🎯精准用户选择

内部员工/测试用户先行
按地域：选择特定区域用户
按用户属性：VIP用户或普通用户
按设备类型：iOS/Android/Web

🛡️自动回滚机制

错误率超过阈值自动回滚
P99延迟异常触发告警
关键业务指标下降自动回滚
一键回滚：30秒内恢复旧版本

📈监控与指标

基础设施：CPU、内存、磁盘、网络
应用指标：QPS、错误率、延迟分布
业务指标：转化率、订单量、收入
用户体验：页面加载时间、交互延迟

Tư tưởng cốt lõi:

Lưu lượng nhỏ đi trước: Trước tiên đưa 1% lưu lượng vào máy chủ phiên bản mới.
Quan sát chỉ số: Liên tục giám sát tỷ lệ lỗi, độ trễ, chỉ số nghiệp vụ quan trọng.
Tăng dần lưu lượng: Nếu mọi thứ bình thường, tăng dần tỷ lệ lên 5%, 10%, 25%, 50%, 100%.
Rollback nhanh: Một khi phát hiện bất thường, lập tức chuyển toàn bộ lưu lượng về phiên bản cũ.

💡 Ưu thế của phát hành canary

Ưu thế	Mô tả
🎯 Rủi ro kiểm soát được	Ngay cả phiên bản mới có Bug nghiêm trọng, cũng chỉ ảnh hưởng đến một lượng nhỏ người dùng
📊 Xác thực thực tế	Xác thực trong môi trường production thực, đáng tin cậy hơn môi trường kiểm thử
🚀 Lặp nhanh	Nhóm có thể tự tin hơn khi thường xuyên phát hành tính năng mới
💰 Thân thiện tài nguyên	Không cần chuẩn bị hai môi trường đầy đủ như triển khai xanh-lam

6. Vấn đề cốt lõi 4: Làm thế nào để hệ thống tự "thở"?

6.1 Tự động mở rộng và thu hẹp: Để hệ thống "xếp ca linh hoạt" như nhà hàng

Hãy tưởng tượng bạn mở một nhà hàng:

Giờ cao điểm trưa: Cần 10 nhân viên phục vụ, nhưng 3 giờ chiều vắng khách chỉ cần 2 người
Nếu luôn duy trì 10 người: Chi phí nhân công bùng nổ
Nếu luôn chỉ có 2 người: Giờ cao điểm khách không chờ nổi, bỏ đi hết

Tự động mở rộng thu hẹp (Auto Scaling) chính là để hệ thống "xếp ca linh hoạt" như nhà hàng — lúc bận tự động thêm máy chủ, lúc rảnh tự động giảm máy chủ.

扩容指标：

实时监控实时

💻CPU使用率

45%

扩容阈值: 70%缩容阈值: 30%

🧠内存使用率

60%

扩容阈值: 75%缩容阈值: 40%

⚡QPS

650req/s

扩容阈值: 1000/s目标: 800/s

🖥️运行实例

3个实例

最小: 2最大: 10

扩缩容历史最近 5 次操作

📈

扩容: 2 → 3 实例

CPU使用率超过70%