Splitting a Monitoring Monolith into Separate Components
Bài tóm tắt trivago 2018 2. Tăng trưởng Độ khó: Dễ
trivago · 2018 · 2. Tăng trưởng · Độ khó: Dễ — bài gốc
Ví dụ quy mô nhỏ: đề tài luận văn cử nhân của một sinh viên làm ở trivago. Hữu ích như một ca tách monolith ở mức một công cụ nội bộ, không phải hệ sản phẩm.
Bối cảnh
- Team Website-Performance có một ứng dụng PHP nguyên khối (Symfony, Orchestra) kéo metric từ API của các CDN (ChinaCache, Edgecast…) và vài dịch vụ khác, đẩy vào InfluxDB qua Graphite. Code nhiều phụ thuộc chéo giữa các module.
Thay đổi chính
- Vẽ sơ đồ lớp PHP để tìm ranh giới, rồi tách từng module CDN thành một service Go riêng, mỗi service chỉ lo một API.
- Đổi đích: thay InfluxDB bằng Prometheus; mỗi service là một exporter.
- Edgecast: Prometheus scrape; dùng go-kit, middleware kiểu "onion" cho log và metric.
- ChinaCache: API hay timeout nên nếu chỉ chờ scrape thì metric sẽ mất; dùng Pushgateway đẩy khi có dữ liệu. Bỏ go-kit vì thấy thừa cho service nhỏ.
- Cấu hình qua biến môi trường (12-factor); đóng container, chạy trên Nomad, đăng ký Consul để Prometheus tự tìm.
- Mở mã nguồn hai exporter.
Vì sao
- Theo trivago, lợi chính là giảm độ phức tạp: ít phụ thuộc, dễ đọc, gom nhiều công cụ thu thập về một (Prometheus); goroutine giúp truy vấn song song nhanh hơn. Metric thu được không đổi.
Bài học cho SWE
- Tách monolith hợp lý nhất khi các phần độc lập tự nhiên (mỗi module một API ngoài, không chia sẻ dữ liệu); đó là ranh giới rẻ để cắt (Monolith và microservices — đi và quay lại).
- Đổi ngôn ngữ và đổi hệ monitoring cùng lúc với việc tách là gộp nhiều thay đổi; ổn ở quy mô công cụ nội bộ, rủi ro hơn với hệ sản phẩm.
- Cùng một framework (go-kit) có thể vừa với service này và thừa với service kia.
Liên quan
Được nhắc tới trong
Công ty (1)
Bài tóm tắt (4)