Hồi mới tách service cho một hệ thống quản lý đơn hàng, mình cũng máu lắm: microservice là chuẩn kiến trúc tương lai, dễ phát triển, dễ maintain, CI/CD riêng biệt, deploy phà phà. Nhưng đời không như dev nghĩ, cái service nào cũng đẹp, chỉ có cái DB là bẩn.
Hầu như các bạn mới chuyển sang microservices toàn vướng phải đúng một ổ gà: shared database. Tách code thì được, tách database là chuyện khác. Các bác nào từng scale thử sẽ biết cảm giác nghẽn connection pool là như nào: service nhỏ mà connect lên tới hàng trăm connections, Redis hay Postgres cũng thở oxy.
Thực tế mình gặp
Một lần, tụi mình scale cái order service để xử lý flash sale. Tách riêng ra rồi, autoscale ổn áp, metric ổn. Nhưng vừa traffic lên 5x là DB chết ngắt. Tại sao? Vì 5 cái service cùng quất vào 1 DB Postgres shared schema, mỗi cái mở connection riêng, pool size đụng trần. Lúc đó chỉ có rollback để sống.
Xong từ đó mới ngộ ra mấy thứ:
- Shared database là bottleneck đầu tiên khi scale microservices.
- Dù dùng ORM hay gRPC gì thì cuối cùng vẫn phải hit vô DB, và nếu không có replica, read/write separation, hoặc DB-level sharding, thì scaling chỉ là lời nói gió bay.
- Cache sai, cache không invalid đúng, là đọc nhầm data. Còn cache tốt thì nhẹ cả hệ thống, nhưng cực khó đồng bộ state giữa cache và DB.
Hệ quả
Nhiều team tưởng cứ chia microservice là xong, nhưng DB vẫn là kiểu monolith tổ bố, mọi service chung một schema, không có cách nào tracing error hiệu quả, muốn migrate schema là toang cả team QA. Gặp production chạm limit RDS là chỉ biết scale lên instance to hơn, rồi đau ví hằng tháng.
Có bác hỏi mình, thế giải pháp là gì?
- Tách database per service nếu được – đúng theo Bounded Context.
- Dùng message queue (Kafka, RabbitMQ…) để tách transaction xuyên service.
- Có budget thì vitess, cockroachdb, temporal.io cũng là hướng, nhưng không có người maintain thì chỉ là tech để show CV.
- Còn không thì ít nhất phải monitor được query, hiểu được cái DB mình đang choke ở đâu dùng pg_stat_statements cũng đủ thấy query nào đâm thủng performance.
Lời kết
Scale microservices không khó. Nhưng scale được một cái shared database sống sót qua load test, survive 3 tháng peak traffic, mới đáng gọi là “hiểu DevOps.”
Các bác nào đang build microservices bớt mộng tưởng. Microservices là một thế giới đẹp nếu các bác có tiền, có người, có thời gian, và biết mình đang đẩy cái bottleneck từ đâu sang đâu.