Microservices là gì? Đó là cách xây phần mềm thành nhiều dịch vụ nhỏ chạy độc lập, mỗi dịch vụ có dữ liệu và việc triển khai riêng, nối với nhau qua mạng. Ngược lại, monolith (kiến trúc một khối) gom toàn bộ hệ thống thành một ứng dụng triển khai cùng nhau. Với phần lớn doanh nghiệp vừa và nhỏ, lời khuyên thực tế của chúng tôi là bắt đầu bằng một monolith được chia module gọn gàng, và chỉ tách dịch vụ khi có lý do cụ thể.
Nghe có vẻ "microservices" hiện đại hơn, nhưng hiện đại không đồng nghĩa với phù hợp. Microservices giải quyết những vấn đề của tổ chức lớn, với nhiều đội cùng phát triển song song. Nếu bạn chưa có những vấn đề đó, bạn sẽ trả chi phí của giải pháp mà không nhận được lợi ích.
Hai kiến trúc khác nhau ở đâu
Hãy hình dung một cửa hàng. Monolith giống một cửa hàng có nhiều quầy trong cùng một tòa nhà: một lối vào, một kho chung, một sổ sách. Microservices giống một chuỗi nhiều cửa hàng nhỏ ở nhiều địa điểm, mỗi nơi có kho và sổ riêng, phải gọi điện và vận chuyển để phối hợp với nhau.
Chuỗi nhiều điểm bán linh hoạt khi quy mô lớn, nhưng việc phối hợp tốn công thật. Trong phần mềm cũng vậy:
- Nhiều dịch vụ nghĩa là nhiều thứ phải cài đặt, theo dõi, bảo mật và sao lưu
- Một thao tác đi qua nhiều dịch vụ, nên khi lỗi xảy ra việc dò nguyên nhân khó hơn
- Dữ liệu nằm rải rác, đảm bảo số liệu nhất quán giữa các dịch vụ là bài toán riêng
- Chi phí hạ tầng và nhân sự vận hành tăng lên
Vì sao doanh nghiệp vừa và nhỏ thường nên bắt đầu bằng monolith
Một monolith được chia module cẩn thận vẫn có ranh giới rõ ràng: bán hàng, kho, nhân sự, báo cáo là các khối riêng trong cùng ứng dụng. Cách chia này được trình bày trong bài chia phần mềm thành module.
Lý do chọn con đường này:
- Đơn giản để vận hành: một ứng dụng để triển khai, giám sát và sao lưu
- Dữ liệu nhất quán: đơn hàng xác nhận và trừ kho xảy ra trong cùng một giao dịch, hoặc cả hai thành công hoặc cả hai không
- Phát triển nhanh hơn ở giai đoạn đầu: ít phần ghép nối, ít chỗ phải thống nhất
- Chi phí hợp lý: phù hợp với việc giao theo giai đoạn, bản đầu nhỏ chạy trước
- Đường lui: module nào lớn lên đến mức cần tách, bạn vẫn có thể tách sau vì ranh giới đã sạch
Điều then chốt: monolith tốt và monolith lộn xộn là hai thứ hoàn toàn khác nhau. Lợi ích chỉ có khi các module được giữ ranh giới rõ ràng từ đầu.
Khi nào mới nên tách dịch vụ
Tách một phần khỏi khối chính có lý khi bạn gặp một hoặc nhiều tình huống sau:
- Một chức năng cần chịu tải rất khác phần còn lại, ví dụ nhận lượng yêu cầu lớn từ ứng dụng của khách hàng và cần mở rộng riêng
- Một phần cần công nghệ khác hẳn, ví dụ xử lý AI hoặc xử lý ảnh chạy nền
- Nhiều đội cùng phát triển, và việc chờ nhau đã thành vướng mắc thực sự
- Một chức năng phải triển khai thường xuyên hơn hẳn phần còn lại
- Yêu cầu cách ly vì bảo mật hoặc tuân thủ cho một phần dữ liệu cụ thể
Chú ý rằng tách một dịch vụ không có nghĩa là phải làm tất cả thành microservices. Nhiều hệ thống chạy tốt với một khối chính cộng một hai dịch vụ phụ cho đúng phần cần tách.
Câu hỏi nên đặt trước khi chọn
Trước khi nghe ai đó đề xuất microservices, bạn có thể hỏi:
- Vấn đề cụ thể nào mà kiến trúc này giải quyết cho doanh nghiệp tôi
- Ai sẽ vận hành, theo dõi và sao lưu nhiều dịch vụ sau khi bàn giao
- Chi phí hạ tầng và bảo trì tăng thêm là gì so với một khối
- Nếu sau này cần tách, phương án hiện tại có cho phép tách không
- Tôi có nhận được mã nguồn và dữ liệu của tất cả các phần không
Một bên tư vấn trung thực sẽ trả lời được các câu này bằng ngôn ngữ dễ hiểu, không chỉ dùng thuật ngữ.
Khi lời khuyên này không áp dụng
Không phải mọi trường hợp đều nên bắt đầu bằng monolith. Nếu bạn là một nền tảng dự kiến phục vụ số lượng người dùng rất lớn ngay từ đầu, có nhiều đội kỹ thuật độc lập, hoặc cần các phần hệ thống co giãn độc lập ngay từ ngày đầu, thì tách dịch vụ sớm có thể hợp lý. Một số hệ thống cũng buộc phải tích hợp với dịch vụ bên ngoài, khi đó phần tích hợp thường tách riêng.
Ngược lại, với một phần mềm nội bộ cho vài chục đến vài trăm người dùng, hiếm khi cần đến microservices. Quyết định cuối cùng phụ thuộc vào quy mô, đội ngũ và kế hoạch phát triển của bạn, nên cần được bàn cụ thể trong buổi phân tích quy trình chứ không áp dụng máy móc.
Chọn công nghệ cho khối chính
Kiến trúc là một lựa chọn, công nghệ là lựa chọn khác. Cả hai framework mà chúng tôi dùng cho backend đều phù hợp để dựng một monolith chia module gọn: bài Python Django cho phần mềm doanh nghiệp giải thích vì sao Django phù hợp với phần mềm quản lý, và khi nào nên cân nhắc lựa chọn khác.
Bước tiếp theo
Nếu bạn đang cân nhắc hệ thống mới và muốn một ý kiến cụ thể về kiến trúc, hãy mô tả quy mô người dùng và quy trình hiện tại. Chúng tôi phân tích rồi đề xuất theo từng giai đoạn. Xem dịch vụ viết phần mềm theo yêu cầu cho doanh nghiệp hoặc gửi yêu cầu báo giá khi bạn sẵn sàng.
