← Bài trước | Series hub Chương 9: Mở Rộng Điểm Thắt Cổ Chai Database Cuối Cùng Đến ngưỡng ứng dụng của bạn gom được hàng chục triệu người dùng, Database sẽ tự động hóa thân thành điểm thắt cổ chai tối thượng. CPU giãy giụa chạm kịch trần 100%, RAM cạn kiệt, và mớ queries chạy mất tính bằng giây thay vì phần nghìn giây. Đây chính là cột mốc bắt buộc bạn phải tung ra các quân bài chiến lược phân tán database. ...

← Bài trước | Series hub | Tiếp theo → Chương 8: Đồng Bộ Hóa Clusters Bằng Distributed Locks Bên trong một ứng dụng Go chạy cô lập (standalone), để tránh chuyện hai Goroutines giành giật dẫm đạp lên nhau ghi đè chung một cục dữ liệu (Race Condition), người ta hay viện đến gã gác cửa sync.Mutex. Xui thay, lúc hệ thống của bạn phình to rải quân ra tận 10 servers nấp sau lưng một gã Load Balancer, cái sync.Mutex bỗng hóa thứ đồ bỏ vì nó chỉ khóa được mỗi cục RAM nội bộ của nhà nó. Bạn sẽ phải mưu cầu một thứ lớn lao hơn: Distributed Lock (Khóa phân tán). ...

← Bài trước | Series hub | Tiếp theo → Chương 7: Củng Cố Nền Tảng Thanh Toán Bằng Idempotent APIs Trong thế giới E-commerce hay Fintech, cơn ác mộng kinh hoàng nhất không phải là chuyện sập hệ thống, mà là trừ tiền một khách hàng tới hai lần cho cùng một hóa đơn. Cớ sự thường bắt nguồn từ mạng lag, do khách hàng sốt ruột ấn “Pay” (Thanh toán) lặp đi lặp lại, hoặc do thuật toán retry (thử lại) dập máy móc của app. ...

← Bài trước | Series hub | Tiếp theo → Chương 6: Vạch Rõ Lằn Ranh: API Gateway Đấu Với Service Mesh Một khi ứng dụng Golang của bạn bung lụa scale từ vài chục vọt lên tới hàng trăm Microservices, quản lý luồng giao tiếp trở thành một thách thức vĩ mô. Bạn sẽ liên tục va chạm với hai khái niệm gắn chặt vào nhau như hình với bóng: API Gateway và Service Mesh. ...

← Bài trước | Series hub | Tiếp theo → Chương 5: Mở Khóa Hiệu Suất Database Thông Qua Connection Pooling Nếu hệ thống Golang của bạn nghiền ngẫm business logic (logic nghiệp vụ) nhanh như chớp nhưng lại sặc nước nghẹn ứ ngay ở tầng Database, thì 90% nguyên nhân bắt nguồn từ một chiếc cấu hình *sql.DB lệch pha. 1. Thấu Hiểu *sql.DB Answer-first: Trong thế giới Golang, hàm sql.Open() KHÔNG HỀ khởi tạo một đường truyền kết nối chọc thẳng xuống database. Nó đóng vai trò khởi chạy một cỗ máy quản đốc Connection Pool (hồ chứa kết nối) an toàn luồng (thread-safe). Điều kiện bắt buộc là bạn chỉ được phép khởi tạo cái biến db này đúng một lần duy nhất trong suốt chu kỳ khởi động app. ...

← Bài trước | Series hub | Tiếp theo → Chương 4: Xóa Sổ Cơn Ác Mộng Dual-Write Ngay khi ứng dụng Golang của bạn dịch chuyển từ Monolith (kiến trúc nguyên khối) sang mô hình Event-Driven Microservices, bạn sẽ lập tức nếm mùi một cơn ác mộng kiến trúc: Vấn Đề Dual-Write (Ghi song song). 1. Vấn Đề Dual-Write Là Gì? Answer-first: Dual-Write bộc phát lúc một ứng dụng thử cố gắng vừa lưu chép xuống Database vừa thả (publish) event tới Message Broker (Kafka) cùng một lúc. Do không có vỏ bọc của một transaction phân tán (distributed transaction), chỉ một lần vấp lỗi mạng cũng đủ sức khiến hai hệ thống trên rớt nhịp đồng bộ mãi mãi. ...

← Bài trước | Series hub | Tiếp theo → Chương 3: Bảo Mật APIs Bằng Distributed Rate Limiting Nếu caching là tấm khiên che chở cơ sở dữ liệu, thì Rate Limiting (giới hạn lưu lượng) lại là bộ giáp che chắn cho các máy chủ API của bạn khỏi các cuộc tấn công DDoS và tình trạng cạn kiệt tài nguyên gây ra bởi những clients lạm dụng. Tại Sao Local Rate Limiting Thất Bại Trong Microservices Answer-first: Các hệ thống limiters lưu trên RAM cục bộ (local RAM) thất bại bởi vì Load Balancers có nhiệm vụ phân tán traffic ra nhiều nodes. Một người dùng được cấp hạn mức 100 req/sec hoàn toàn có thể lợi dụng một cluster 5 nodes để gửi thốc 500 req/sec, dễ dàng chọc thủng hàng rào giới hạn. Việc gom trạng thái tập trung (Centralized state) qua Redis là bắt buộc. ...

← Bài trước | Series hub | Tiếp theo → Chương 2: 3 Điểm Yếu Tử Huyệt Nhất Của Cache Caching là tấm khiên phòng ngự tối thượng bảo vệ các cơ sở dữ liệu trong hệ thống phân tán. Tuy nhiên, nếu triển khai cẩu thả, cache lại chính là nguyên nhân trực tiếp kéo sập toàn bộ hệ thống của bạn. Trong chương này, chúng ta sẽ mổ xẻ ba hiện tượng kinh điển về caching và cách chống lại chúng bằng Golang. ...

← Series hub Tiếp theo → Chương 1: Xuyên Phá Rào Cản C10M Để kiến tạo một hệ thống đủ sức gánh vác hàng triệu Requests Per Second (RPS) — hay còn gọi là bài toán C10M — vertical scaling (tăng cấu hình) không bao giờ là đủ. Nó đòi hỏi một Kiến Trúc Phân Tán (Distributed Architecture) được thiết kế tỉ mỉ. 1. Bước Chuyển Giao Từ C10K Sang C10M Answer-first: Trong khi C10K được hóa giải bằng mô hình non-blocking I/O (như NGINX), C10M lại chuyển điểm thắt cổ chai về phía OS kernel (nhân hệ điều hành). Các hệ thống buộc phải bỏ qua kernel (Kernel Bypass) bằng cách dùng DPDK hoặc XDP mới có thể xử lý 10 triệu kết nối mượt mà. ...

Bất chấp những tiến bộ vượt bậc của công nghệ điện toán đám mây, các ứng dụng doanh nghiệp đối mặt với sự bùng nổ lưu lượng truy cập (traffic) sớm muộn cũng sẽ đâm sầm vào một bức tường khắc nghiệt: Database và Network layer. Cội nguồn của sự cố không nằm ở phần cứng, mà là ở Architecture (Kiến trúc). Chúng ta thường cố giải quyết bài toán “Hàng triệu Requests mỗi giây” (C10M) bằng cách cứ thế quăng thêm server vào (Vertical/Horizontal Scaling), chỉ để rồi bàng hoàng nhận ra những điểm thắt cổ chai về trạng thái, bão cache stampedes, và tính không nhất quán của dual-write đánh sập cả một hệ thống cluster khổng lồ. ...