Cơn ác mộng khi hệ thống microservices phình to
Thử tưởng tượng bạn đang quản lý 20 microservices. Bỗng một ngày, IP Database thay đổi hoặc bạn cần cập nhật một API Key quan trọng ngay lập tức. Theo cách cũ, bạn sẽ phải vào từng service, sửa file .env, rồi restart lại toàn bộ 20 container đó.
Cách làm này vừa tốn thời gian vừa đầy rủi ro. Chỉ một service quên update, hệ thống sẽ “toang” ngay. Mình từng phải thức đến 2 giờ sáng rà soát từng file config chỉ vì lỡ tay sót một service trong cluster. Đó là một trải nghiệm không hề dễ chịu chút nào.
Tại sao MySQL hay Redis không phải là lựa chọn tối ưu?
Khi gặp vấn đề này, nhiều bạn nghĩ ngay đến việc dùng MySQL hoặc Redis để lưu cấu hình. Tuy nhiên, thực tế phát sinh nhiều bất cập:
- MySQL/PostgreSQL: Giống như dùng xe tải để chở một phong thư. Việc duy trì hàng trăm kết nối chỉ để lấy vài dòng config là sự lãng phí tài nguyên cực lớn.
- Redis: Tốc độ rất nhanh nhưng mặc định ưu tiên hiệu suất hơn tính nhất quán (Consistency). Trong quản lý cấu hình, tính nhất quán là tối thượng. Bạn chắc chắn không muốn Service A nhận config cũ trong khi Service B đã nhận config mới.
- File vật lý: Việc đồng bộ file giữa hàng chục server khác nhau là một cực hình về mặt vận hành.
etcd – “Bộ não” của những hệ thống phân tán
etcd sinh ra để giải quyết triệt để những bài toán này. Đây là database dạng key-value phân tán, viết bằng Go và sử dụng thuật toán đồng thuận Raft. Nó đảm bảo dữ liệu luôn đồng nhất trên mọi node. Bạn có biết? etcd chính là trái tim của Kubernetes, nơi lưu trữ toàn bộ trạng thái của cluster.
Điểm ăn tiền nhất của etcd là khả năng Watch. Thay vì service phải liên tục hỏi “Có gì mới không?”, etcd sẽ chủ động đẩy thông báo ngay khi có thay đổi. Điều này giúp ứng dụng cập nhật cấu hình gần như tức thời (real-time).
Hướng dẫn cài đặt etcd trên Linux
Chúng ta sẽ cài đặt etcd phiên bản binary trên Linux (Ubuntu/CentOS). Đây là cách nhanh nhất để làm quen trước khi bạn triển khai các mô hình phức tạp hơn trên K8s.
# Tải phiên bản v3.5.0
ETCD_VER=v3.5.0
GOOGLE_URL=https://storage.googleapis.com/etcd
GITHUB_URL=https://github.com/etcd-io/etcd/releases/download
DOWNLOAD_URL=${GOOGLE_URL}
rm -f /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz
rm -rf /tmp/etcd-download-test && mkdir -p /tmp/etcd-download-test
curl -L ${DOWNLOAD_URL}/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz -o /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz
tar xzvf /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz -C /tmp/etcd-download-test --strip-components=1
rm -f /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz
# Đưa vào thư mục hệ thống
sudo mv /tmp/etcd-download-test/etcd /usr/local/bin/
sudo mv /tmp/etcd-download-test/etcdctl /usr/local/bin/Kiểm tra cài đặt bằng lệnh etcd --version. Để bắt đầu vọc vạch, bạn chỉ cần chạy node đơn lẻ bằng lệnh:
etcdLúc này, etcd sẽ lắng nghe tại cổng 2379 (cho client) và 2380 (để các node giao tiếp với nhau).
Thao tác dữ liệu với etcdctl
Chúng ta dùng công cụ etcdctl để tương tác với DB. Một lưu ý sống còn: etcd có 2 phiên bản API là v2 và v3. Hãy luôn set biến môi trường sau để dùng v3 (tiêu chuẩn hiện nay):
export ETCDCTL_API=31. Thêm và lấy dữ liệu
Dùng put để lưu và get để truy xuất:
# Lưu config
etcdctl put /configs/db_url "postgres://user:pass@localhost:5432/mydb"
# Lấy giá trị
etcdctl get /configs/db_url2. Theo dõi thay đổi (Watch)
Mở hai cửa sổ terminal để thấy sự lợi hại. Ở terminal 1, hãy chạy lệnh watch:
etcdctl watch /configs/api_keyỞ terminal 2, bạn cập nhật giá trị mới:
etcdctl put /configs/api_key "new-secret-key"Terminal 1 sẽ hiện giá trị mới ngay lập tức. Trong code (Go hay Node.js), bạn có thể dùng hàm callback để tự động cập nhật biến môi trường mà không cần restart app.
Ứng dụng cho Service Discovery
Hãy coi Service Discovery như một cuốn danh bạ tự động. Khi Service B khởi tạo, nó đăng ký mình vào etcd với một thời gian sống (TTL) nhất định thông qua cơ chế Lease.
Service B phải gửi tín hiệu “keep-alive” liên tục để duy trì sự hiện diện. Nếu Service B sập, nó ngừng gửi tín hiệu, etcd sẽ tự động xóa key đó sau khi hết TTL. Service A (đang watch) sẽ biết ngay lập tức để không gửi request vào IP lỗi nữa. Điều này giúp hệ thống tự phục hồi cực kỳ linh hoạt.
Kinh nghiệm xương máu khi vận hành
Sau vài lần “ăn hành” với etcd, đây là những thứ mình ước mình biết sớm hơn:
- Đừng quên backup: Một lần lỡ tay xóa data mà không có backup, mình đã khiến cả cluster “bay màu” trong 5 phút. Hãy luôn tạo snapshot định kỳ:
etcdctl snapshot save backup.db. - Số lượng node: Luôn chọn số lẻ (3, 5, hoặc 7) để tránh lỗi “split-brain”. Với hầu hết hệ thống tầm trung, cụm 3 node là con số hoàn hảo.
- Disk I/O là then chốt: etcd ghi log (WAL) liên tục để đảm bảo an toàn. Nếu dùng Cloud, hãy ưu tiên ổ SSD hoặc NVMe. Ổ HDD chậm sẽ khiến latency của cluster tăng vọt.
- Giới hạn kích thước: etcd không phải kho lưu trữ file. Mỗi key-value nên dưới 1.5MB. Chỉ nên lưu cấu hình và metadata tinh gọn.
Lời kết
Làm chủ etcd là bước tiến lớn nếu bạn muốn xây dựng hệ thống microservices chuyên nghiệp. Thay vì vất vả sửa config thủ công, hãy để etcd tự động hóa mọi thứ một cách tin cậy. Chúc các bạn sớm làm chủ được “bộ não” mạnh mẽ này!
