12 cách trong hành trình cải thiện monolith trước khi chuyển sang microservices

Đội ngũ của bạn cuối cùng cũng quyết định loại bỏ hệ thống monolith cồng kềnh đã lỗi thời?

Bạn đã có một chặng đường dài với nó, nhưng giờ đây việc duy trì monolith mất nhiều công sức hơn là phát triển tính năng mới. Đã đến lúc thử một hướng tiếp cận khác.

Microservices hiện đang rất được ưa chuộng, vậy có lẽ đã đến lúc bạn nên tìm hiểu kỹ hơn xem tại sao?

Một lời khuyên chân thành từ mình là đừng vội “khai tử” monolith. Với một chút chuẩn bị kỹ lưỡng, nó hoàn toàn có thể hỗ trợ bạn trong suốt quá trình chuyển đổi.

Dưới đây là 12 quá trình chuyển đổi và gợi ý giúp quá trình chuyển từ monolith sang microservices diễn ra trơn tru và hiệu quả hơn.

1. Hiểu rõ mình đang làm gì

Việc chuyển đổi sang microservices không chỉ là thay đổi cách viết code mà còn là thay đổi cả mô hình vận hành của công ty. Bạn sẽ cần làm quen với một tech stack phức tạp hơn, đồng thời đội ngũ quản lý cũng cần thích nghi với mô hình tổ chức mới và nó thường là các nhóm nhỏ, đa chức năng.

Trước khi bắt đầu quá trình chuyển đổi từ monolith sang microservices, điều quan trọng nhất là bạn cần hiểu rõ mình đang dấn thân vào điều gì. Việc viết lại hệ thống không chỉ đơn thuần là thay đổi cách bạn viết mã, mà còn là một sự thay đổi toàn diện trong mô hình vận hành của công ty. Điều này đòi hỏi không chỉ kỹ sư phần mềm phải học một tech stack mới phức tạp hơn, mà đội ngũ quản lý cũng cần tái cấu trúc lại quy trình, tổ chức các nhóm thành các team nhỏ chức năng chéo. Trước khi quyết định, hãy đảm bảo rằng bạn đã nghiên cứu đầy đủ những đánh đổi giữa microservices và những giải pháp thay thế khác như modular monoliths.

Bạn có thể bắt đầu bằng việc đọc tài liệu, thử các dự án mẫu như:

• Xây dựng C# Microservice với Jenkin và CI/CD
• CI/CD cho Microservices trên DigitalOcean Kubernetes
• CI/CD với .Net Microservices

2. Lên kế hoạch chuyển đổi rõ ràng

Khi đã chắc chắn lựa chọn con đường microservices, bước tiếp theo là lập một kế hoạch chi tiết. Việc phá vỡ một hệ thống monolith trong khi vẫn phải giữ nó hoạt động ổn định là một nhiệm vụ đầy thử thách. Kế hoạch nên bao gồm việc gỡ bỏ các phụ thuộc trong monolith, xác định các microservice cần thiết, thiết kế mô hình dữ liệu, xây dựng cơ chế đồng bộ giữa các cơ sở dữ liệu cũ và mới, đảm bảo khả năng tương thích ngược của API, và đo lường hiệu năng hệ thống hiện tại để đặt mục tiêu cụ thể cho hệ thống mới. Đối với các hệ thống phức tạp, áp dụng các kỹ thuật như Domain-Driven Design sẽ rất hữu ích.

Những việc cần chuẩn bị:

• Gỡ rối các dependency bên trong monolith
• Xác định các microservices cần thiết
• Thiết kế lại data model phù hợp với microservices
• Chuẩn bị cách migrate và đồng bộ dữ liệu giữa monolith và microservices
• Thiết kế API có backward compatibility
• Đo lường baseline hiệu suất hệ thống hiện tại
• Đặt mục tiêu cho hiệu suất và độ sẵn sàng của hệ thống mới

3. Gom tất cả vào một Monorepo

Khi tiến hành tách rời các phần trong monolith, việc đưa toàn bộ mã nguồn vào một monorepo sẽ giúp dễ dàng theo dõi và kiểm soát các thay đổi. Bên cạnh đó, monorepo còn hỗ trợ việc khôi phục khi gặp sự cố trở nên nhanh chóng hơn. Nếu hệ thống monolith của bạn vốn đã nằm trong một repository riêng, thì việc bổ sung các thư mục mới cho từng microservice là một bước tiếp theo rất tự nhiên.

4. Dùng một CI pipeline chung

Trong quá trình phát triển song song giữa monolith và các microservice, việc thiết lập một pipeline CI/CD chung là điều cần thiết. Một pipeline hiệu quả sẽ giúp bạn kiểm tra và triển khai mã nhanh chóng, giảm thiểu lỗi phát sinh khi chuyển đổi. Nếu dùng monorepo, bạn nên sử dụng các công cụ hỗ trợ như Bazel hoặc Pants để chỉ chạy test với những phần thay đổi. Ngoài ra, cần cấu hình các luồng deployment riêng cho từng microservice và cho cả monolith để có thể quản lý dễ dàng.

5. Tăng cường kiểm thử một cách chặt chẽ

Không thể thiếu trong quá trình refactor là một hệ thống test tự động vững chắc. Các bài test sẽ giúp bạn tự tin hơn khi cập nhật mã mà không làm phát sinh lỗi hồi quy. Bạn nên áp dụng mô hình “testing pyramid”: chú trọng vào unit test, bổ sung integration test và chỉ một số ít acceptance test. Điều quan trọng là phải chạy các bài test thường xuyên, cả trong môi trường local lẫn CI/CD.

Refactor code sẽ an toàn hơn nhiều nếu bạn có đủ test đảm bảo không có regression. Bạn nên xây dựng một kiến trúc test theo hình kim tự tháp gồm:

• Unit test (nhiều)
• Integration test (vừa đủ)
• Acceptance test (ít nhưng cần thiết)

6. Cài đặt API Gateway hoặc Reverse Proxy để điều hướng request

Khi microservices được triển khai, bạn cần một cơ chế định tuyến lưu lượng đến đúng nơi cần xử lý, phần nào đã tách sẽ do microservice đảm nhận, còn phần chưa tách thì vẫn do monolith xử lý.

Có 2 cách chính:

• API Gateway: định tuyến request dựa vào user, cookie, feature flag…
• HTTP Reverse Proxy: định tuyến HTTP request, thường áp dụng với phần frontend của monolith.

Giải pháp phổ biến là sử dụng HTTP Reverse Proxy để định tuyến dựa trên URL, cookie, user hoặc feature flag. Những công cụ này không chỉ phục vụ quá trình chuyển đổi mà còn tiếp tục đóng vai trò quan trọng trong vận hành hệ thống microservices về sau như cân bằng tải, phân luồng và dự phòng. Ngay cả sau khi chuyển đổi hoàn tất, các gateway/proxy này vẫn cần thiết để load balancing, circuit breaker, v.v.

Khi microservices được triển khai dần, bạn sẽ cần định tuyến request giữa phần đã migrate (microservices) và phần chưa (monolith).

7. Dùng “Monolith-in-a-box” nếu áp dụng container

Nếu bạn có ý định triển khai microservices trên Docker hoặc Kubernetes, hãy xem xét áp dụng mô hình “monolith-in-a-box”, tức là đóng gói monolith vào trong container. Đây là một cách tốt để làm quen dần với công nghệ container và chuẩn bị cho bước tiếp theo là triển khai microservices độc lập. Quá trình học tập mình có thể đề xuất như sau:

1. Học Docker và container
2. Chạy monolith bằng Docker
3. Viết và chạy microservices trong container
4. Khi thành thạo, học tiếp về Kubernetes

8. Chuyển dần, bắt đầu nhỏ

Chuyển sang mô hình microservices là một hành trình dài và cần có thời gian để thích nghi. Đừng ép buộc đội ngũ phải “chuyển hóa” ngay lập tức.

Hãy bắt đầu với những bước nhỏ, chọn những chức năng đơn giản, ít phụ thuộc để tách trước, ví dụ như authentication service. Điều này sẽ giúp cả nhóm có thời gian học hỏi, làm quen với tư duy phân tán, cũng như thiết lập các SLA, giám sát, cảnh báo và chiến lược triển khai phù hợp.

9. Dùng Feature Flags để bật tắt tính năng

Feature flags là một công cụ rất mạnh khi bạn muốn thay đổi chức năng mà không cần deploy lại toàn bộ ứng dụng. Trong quá trình chuyển đổi, bạn có thể dùng feature flags để bật tắt các tính năng được di chuyển từ monolith sang microservice mà không cần deploy lại.

Quy trình điển hình khi migrate với feature flag:

1. Xác định phần cần chuyển đổi
2. Bao bọc nó bằng feature flag → deploy lại monolith
3. Viết microservice thay thế → triển khai
4. Kiểm thử tính năng
5. Khi ổn định, tắt flag của monolith → chỉ chạy trên microservice

Điểm mạnh là nó tách biệt triển khai với việc release, giúp kiểm soát dễ dàng hơn.

10. Modular hóa Monolith

Trước khi chuyển sang microservices, bạn nên modularize hệ thống monolith hiện tại để tránh mang theo những “cục bùi nhùi” sang hệ thống mới.

Một monolith được tổ chức theo mô hình module, nó chính là nơi các module giao tiếp với nhau qua public API sẽ giúp bạn dễ quản lý hơn và từng bước bóc tách mà không ảnh hưởng đến toàn hệ thống, và tránh kiến trúc N-tier chồng chéo, dễ lỗi.

Bạn có thể áp dụng các pattern như Strangler Fig hoặc Anticorruption Layer để tái cấu trúc theo cách tuần tự, tránh làm ảnh hưởng đến các phần đã ổn định.

• Strangler Fig

Dần thay thế từng phần nhỏ từ “rìa” vào trung tâm, qua một facade trung gian gọi về monolith khi cần.

• Anti-Corruption Layer

Tạo lớp chuyển đổi giữa các module thay đổi nhanh, để giảm ảnh hưởng dây chuyền.

11. Tách dữ liệu và modeling data

Một trong những nguyên lý quan trọng nhất của microservices là mỗi service phải có cơ sở dữ liệu riêng biệt. Nếu các service dùng chung cơ sở dữ liệu, bạn đang tạo ra coupling về dữ liệu và điều này đi ngược lại triết lý của microservices.

Trong quá trình chuyển đổi, bạn sẽ phải tách database của monolith thành nhiều database nhỏ hơn, đôi khi phải chấp nhận dữ liệu dư thừa mức denormalization (tái sử dụng hoặc nhân bản dữ liệu) để đảm bảo data locality.

Ngoài ra hãy thiết lập các cơ chế như data mirroring để đảm bảo đồng bộ dữ liệu trong thời gian chuyển đổi giữa hệ thống cũ và mới (data mirroring, dual-write…).

12. Bổ sung Observability

Cuối cùng nhưng không kém phần quan trọng, bạn cần đầu tư vào observability với khả năng theo dõi quan sát hệ thống.

Trước khi tách nhỏ, hãy đo đạc hiệu năng của monolith làm baseline. Sau đó, thiết lập hệ thống logging, metrics và alerting tập trung để so sánh và giám sát các microservices. Điều này không chỉ giúp đảm bảo chất lượng hệ thống mới, mà còn là cơ sở để phát hiện lỗi nhanh chóng và cải thiện liên tục sau khi chuyển đổi.

Hành trình từ monolith đến microservices không hề dễ dàng, nhưng nếu thực hiện đúng từng bước và có sự chuẩn bị kỹ lưỡng, bạn sẽ tránh được rất nhiều rắc rối về sau. Hãy chuyển đổi một cách tuần tự, áp dụng CI/CD để giữ vững chất lượng mã, và giữ toàn bộ dự án trong một nơi dễ kiểm soát để luôn có thể quay lại nếu gặp sự cố. Chúc bạn thành công!

#ntechdevelopers