Chuyển từ monolith sang microservices là quyết định chúng tôi từng phải đưa ra giữa một buổi tối hệ thống đứng hình. Khách hàng gọi gấp lúc hai giờ sáng. Trang thanh toán treo, kéo theo cả module quản lý kho ngừng phản hồi. Lần theo log, cả đội mới biết chỉ một đoạn code tính khuyến mãi lỗi đã làm sập toàn bộ ứng dụng, vì mọi thứ đang nằm chung một khối. Đó là lần đầu chúng tôi thật sự thấm câu hỏi này. Bài viết dưới đây là những gì rút ra sau nhiều lần cùng khách hàng cân nhắc chuyện tách hệ thống.
Kiến Trúc Monolith Từng Phù Hợp Nhưng Dần Bộc Lộ Giới Hạn Khi Mở Rộng
Bảo Trì Và Triển Khai Ngày Càng Nặng Nề Khi Hệ Thống Phình To
Monolith, nói dễ hiểu, là kiểu xây dựng mà toàn bộ tính năng của một website hay ứng dụng — đăng nhập, giỏ hàng, thanh toán, quản lý kho — đều nằm chung trong một khối code, chạy chung một server. Với đội ngũ nhỏ mới khởi nghiệp, cách làm này rất hợp lý. Một repo, một lần deploy, không phải lo phối hợp giữa nhiều service. Chúng tôi từng dựng không ít hệ thống bán hàng theo kiểu này trong 3-4 tháng đầu, và nó chạy tốt, chạy nhanh, chạy rẻ.
Vấn đề bắt đầu lộ ra khi sản phẩm sống qua năm thứ hai, thứ ba. Code phình to dần theo từng tính năng mới. Một thay đổi nhỏ ở module khuyến mãi cũng có thể kéo sập luôn phần thanh toán, đơn giản vì hai phần này dùng chung bộ nhớ, chung tiến trình xử lý. Đội dev muốn deploy một tính năng nhỏ vẫn phải build lại, test lại toàn bộ hệ thống. Có dự án của khách hàng chúng tôi, thời gian build một lần lên tới 25-30 phút, mỗi ngày làm được vài lần release là cùng.
Triển khai cũng là nỗi đau riêng. Với monolith, mọi tính năng đóng gói chung một bản deploy. Nếu team A đã xong tính năng mới, nhưng team B đang có một đoạn code lỗi chưa fix kịp, cả bản release phải hoãn lại, dù phần của team A hoàn toàn ổn. Chúng tôi từng chứng kiến một đội ngũ vốn release hai tuần một lần, phải giãn ra sáu tuần một lần chỉ vì lịch deploy chung ngày càng khó xếp giữa nhiều nhóm.
Không Phải Ai Cũng Cần Vội Vàng Chuyển Đổi
Cái khó hơn nữa nằm ở việc mở rộng. Vào mùa sale, lượng truy cập trang sản phẩm tăng gấp 5-6 lần ngày thường, nhưng phần quản lý kho hay CRM chăm sóc khách lại gần như không đổi tải. Với monolith, muốn scale phải nhân bản nguyên khối, kéo theo cả những phần không cần scale, tốn thêm chi phí server mà hiệu quả không tương xứng. Chúng tôi từng tự động hóa audit kỹ thuật cho website của một khách hàng ngành bán lẻ, và phát hiện gần 40% tài nguyên server bị dùng lãng phí cho những module ít truy cập nhưng vẫn phải scale theo cụm.
Không phải doanh nghiệp nào cũng cần bước qua giai đoạn này. Một cửa hàng online vài nghìn đơn mỗi tháng, đội dev 3-4 người, vẫn có thể sống khỏe với monolith thêm nhiều năm nữa. Vấn đề chỉ thật sự cấp bách khi tốc độ tăng trưởng vượt tốc độ mà kiến trúc hiện tại có thể gánh. Một sai lầm chúng tôi hay gặp là thấy hệ thống chậm liền nghĩ ngay đến microservices, trong khi nguyên nhân chỉ là database thiếu index hoặc server chưa tối ưu cache. Mẹo của chúng tôi luôn là đo đạc kỹ, xem nghẽn nằm ở đâu, trước khi quyết định tái cấu trúc bất cứ điều gì.
Dấu Hiệu Cho Thấy Đã Đến Lúc Chuyển Từ Monolith Sang Microservices
Không phải cứ monolith là xấu, và không phải hễ nghe đến microservices là phải nhảy vào ngay. Nói dễ hiểu, microservices là cách chia nhỏ ứng dụng thành nhiều dịch vụ độc lập. Mỗi dịch vụ tự chạy, tự deploy, giao tiếp với nhau qua API. Chúng tôi thường khuyên khách hàng nhìn vào vài dấu hiệu cụ thể trước khi quyết định chuyển từ monolith sang microservices, thay vì chạy theo xu hướng.
- Một module như giỏ hàng cần scale gấp 10 lần vào giờ cao điểm, trong khi các module khác gần như đứng yên.
- Đội dev đã hơn 15-20 người, thường xuyên giẫm chân nhau khi cùng sửa một file, một nhánh git.
- Một lỗi nhỏ ở tính năng phụ từng khiến cả hệ thống ngừng hoạt động ít nhất một lần trong quý vừa rồi.
- Bạn muốn dùng công nghệ khác nhau cho từng phần, nhưng monolith buộc tất cả phải chung một ngôn ngữ lập trình.
Chúng tôi từng làm một dự án nền tảng đào tạo trực tuyến, nơi phần chat hỗ trợ học viên cần phản hồi realtime cực nhanh, còn phần chấm bài tự luận cần chạy mô hình AI khá nặng. Giữ chung một monolith, cả hai buộc dùng chung một ngôn ngữ, một cụm máy chủ, rất phí tài nguyên. Tách thành hai service riêng, mỗi bên chọn công nghệ phù hợp, tốc độ và chi phí đều tốt hơn hẳn.
Dấu hiệu rõ nhất, theo quan sát của chúng tôi, là khi tổ chức phát triển đã lớn đến mức một nhóm không thể ôm hết toàn bộ hệ thống trong đầu. Lúc này, chia mỗi service cho một nhóm nhỏ 4-6 người phụ trách trọn vẹn, từ code, test, đến deploy, sẽ giúp mọi thứ chạy nhanh hơn nhiều so với việc cả hai mươi người cùng đụng vào một codebase.
Một điều chúng tôi hay nhắc khách hàng: thời điểm cân nhắc tái cấu trúc backend cũng thường là lúc nên nhìn lại luôn cả phần giao diện, trải nghiệm mua hàng phía trước. Nhiều doanh nghiệp tách xong hệ thống xử lý đơn hàng thành microservices, nhưng giao diện website vẫn cũ kỹ, tải chậm, không theo kịp tốc độ backend mới. Nếu đang có kế hoạch làm mới đồng thời cả hai, đội ngũ MONA Media thiết kế web là một trong những cái tên chúng tôi từng thấy khách hàng nhắc tới khi cần làm lại giao diện bán hàng song song với nâng cấp hạ tầng kỹ thuật.
Sai lầm phổ biến là tách toàn bộ hệ thống cùng lúc, thay vì chọn một module ít rủi ro để tách trước và rút kinh nghiệm. Chúng tôi thường gợi ý bắt đầu với phần gửi email, thông báo, trước khi động đến những phần lõi như thanh toán.
Những Thách Thức Cần Lường Trước Khi Chuyển Đổi Kiến Trúc
Giao Tiếp Giữa Các Service Phức Tạp Hơn Bạn Nghĩ
Chuyển đổi kiến trúc không phải phép màu, và chúng tôi muốn nói thẳng điều này trước khi bạn bắt tay vào làm. Cái giá phải trả đầu tiên là độ phức tạp khi các service gọi qua lại lẫn nhau.
Có một dự án chúng tôi từng hỗ trợ, sau khi tách xong 12 service, một yêu cầu đặt hàng đơn giản phải đi qua 6 lần gọi API khác nhau. Từ kiểm tra tồn kho, xác thực người dùng, tính khuyến mãi, đến gọi cổng thanh toán. Mỗi lần gọi cộng thêm khoảng 20-50 mili-giây độ trễ mạng. Cộng dồn lại, trải nghiệm người dùng chậm hơn hẳn lúc còn monolith, dù mỗi service riêng lẻ đã nhanh hơn. Debug cũng khó hơn nhiều, vì lỗi giờ có thể nằm ở bất kỳ đâu trong chuỗi gọi đó.
Tệ hơn là hiệu ứng domino. Nếu service tính khuyến mãi bị chậm, toàn bộ chuỗi gọi phía sau cũng bị treo theo, dù dịch vụ thanh toán không hề có lỗi. Để tránh việc này, cần thêm cơ chế như circuit breaker — hiểu đơn giản là một “cầu dao” tự ngắt kết nối tới service đang gặp sự cố, tránh để lỗi lan ra toàn hệ thống. Đây là khái niệm mà đội ngũ chạy monolith trước đó gần như chưa từng phải bận tâm.
Ngân Sách Và Con Người Cho Hạ Tầng Giám Sát
Vì vậy, gần như bắt buộc phải đầu tư thêm công cụ giám sát, thứ mà nhiều đội chạy monolith còn chưa cần đến. Cụ thể là hệ thống logging tập trung, distributed tracing để theo dấu một request đi qua bao nhiêu service, và dashboard theo dõi sức khỏe từng phần theo thời gian thực. Chi phí cho phần hạ tầng giám sát này, theo kinh nghiệm của chúng tôi, thường chiếm thêm 15-20% ngân sách vận hành so với thời còn chạy monolith, chưa kể chi phí nhân sự để duy trì đội DevOps chuyên trách.
Về mặt thời gian, một lần chuyển đổi nghiêm túc, không phải làm cho có, thường mất từ 4 đến 9 tháng tùy quy mô hệ thống. Ngân sách cho hạ tầng mới — container hóa bằng Docker, dàn dựng Kubernetes, hệ thống hàng đợi message như RabbitMQ hoặc Kafka để các service giao tiếp không đồng bộ — có thể dao động 300-800 triệu đồng cho một hệ thống cỡ vừa. Đây là con số chúng tôi ước tính dựa trên các dự án đã triển khai, để bạn cân đối ngân sách thực tế trước khi bắt đầu.
Không ít khách hàng ngần ngại vì khoản chi phí phát sinh này, nhưng nếu nhìn đúng cách, đây là khoản đầu tư giúp hệ thống ổn định lâu dài. Chúng tôi từng chia sẻ khá kỹ về bài học cắt giảm chi phí vận hành hệ thống khi làm việc với các agency chuyển đổi số. Phần lớn khoản tiết kiệm đến từ việc tự động hóa giám sát, thay vì cắt giảm nhân sự.
Sai lầm chúng tôi thấy nhiều nhất là đội ngũ dồn hết công sức tách service, nhưng bỏ quên phần giám sát. Đến khi hệ thống lỗi, không ai biết lỗi nằm ở đâu để sửa. Mẹo ở đây khá đơn giản: đầu tư công cụ theo dõi trước hoặc song song với quá trình tách hệ thống, đừng để đến sau mới làm.
Thời Điểm Nào Là Đúng Lúc Để Đội Ngũ Của Bạn Bắt Tay Vào Chuyển Đổi
Sau nhiều dự án, chúng tôi rút ra một nguyên tắc đơn giản: đừng chuyển đổi kiến trúc chỉ vì thấy công ty khác làm vậy. Hãy chuyển khi bạn thật sự cảm nhận được nỗi đau — hệ thống chậm ở đúng những chỗ ảnh hưởng doanh thu, đội dev giẫm chân nhau mỗi ngày, hoặc một lỗi nhỏ liên tục kéo sập cả hệ thống lớn. Nếu những dấu hiệu đó chưa xuất hiện, cứ yên tâm ở lại với monolith thêm một thời gian, vừa làm vừa tối ưu dần cũng không sao.
Còn nếu bạn đã thấy rõ những dấu hiệu ấy, lời khuyên của chúng tôi là bắt đầu nhỏ. Chọn một module ít rủi ro để tách trước, đầu tư công cụ giám sát song song, và đừng vội tách hết trong một lần. Cách làm này giúp đội ngũ vừa học vừa điều chỉnh, thay vì đánh cược cả hệ thống vào một lần tái cấu trúc lớn. Nhiều khách hàng của chúng tôi, sau khi làm quen dần với việc tích hợp công nghệ mới vào hệ thống nội bộ doanh nghiệp theo từng bước nhỏ, đã chuyển đổi thành công mà gần như không có downtime nào đáng kể ảnh hưởng tới khách hàng cuối.