Kiến trúc Microservices so với Monolithic: Bạn nên xây dựng cái nào?
Một nhà sáng lập từng yêu cầu tôi xem xét một bản đề xuất kiến trúc.
Đơn vị đại lý đã đề xuất mười một dịch vụ, một message queue và một service mesh. Điều này dành cho một công cụ đặt chỗ đơn giản với con số không người dùng.
Đó là một cái bẫy.
Các quyết định về kiến trúc sẽ quyết định hóa đơn lưu trữ, tốc độ phát hành sản phẩm và kế hoạch tuyển dụng của bạn. Bạn phải biết trước chi phí trước khi giao ngân sách cho nhà phát triển.
Monolith Một monolith sử dụng một codebase, một quy trình triển khai và một cơ sở dữ liệu. Nó rất đơn giản.
Vào ngày đầu tiên, bạn chưa biết rõ các ranh giới domain của mình. Nếu bạn chia nhỏ các dịch vụ quá sớm, bạn sẽ mất thời gian để di dời những "bức tường" lẽ ra không nên tồn tại. Monolith dễ quản lý hơn khi đội ngũ của bạn còn nhỏ. Bạn chỉ cần gọi một hàm thay vì phải thiết lập một API. Khi có lỗi xảy ra lúc 2 giờ sáng, lỗi sẽ chỉ thẳng vào mã nguồn chứ không phải do lỗi mạng.
Microservices Microservices giải quyết các vấn đề về mặt tổ chức. Chúng cho phép các nhóm khác nhau phát hành mã nguồn theo lịch trình riêng của họ. Netflix sử dụng chúng để ngăn chặn một lỗi đơn lẻ làm chìm cả con tàu.
Tuy nhiên, bạn phải trả giá cho điều này mỗi ngày. Các cuộc gọi mạng làm tăng độ trễ. Tính nhất quán của dữ liệu trở nên khó khăn. Bạn cần các công cụ chuyên dụng và một đội ngũ lớn để quản lý log và tracing. Nếu không có đủ nhân sự phù hợp, bạn sẽ kết thúc với một distributed monolith. Điều này mang lại cho bạn tất cả sự phức tạp của một mạng lưới nhưng lại không có được sự độc lập.
Modular Monolith Đây là giải pháp trung gian. Nó là một ứng dụng duy nhất với các ranh giới vững chắc giữa các phần khác nhau của mã nguồn. Phần Billing không thể can thiệp vào phần cốt lõi của Orders.
Shopify và GitHub sử dụng cách tiếp cận này. Bạn có được các ranh giới rõ ràng và tránh được "network tax". Khi một phần của ứng dụng cuối cùng cần phải scale độc lập, bạn có thể tách nó ra một cách dễ dàng vì các ranh giới đã được xác định sẵn.
Cách để quyết định:
- Quy mô đội ngũ: Nếu bạn chỉ có ba người, bạn không thể quản lý các dịch vụ riêng biệt và chế độ on-call rotation cần thiết.
- Sự ổn định của sản phẩm: Nếu sản phẩm của bạn thay đổi hàng tuần, ranh giới dịch vụ của bạn sẽ trở nên sai lệch vào tháng sau.
- Vận hành: Bạn đã có cơ chế automated rollbacks và log aggregation chưa? Nếu chưa, microservices sẽ gây ra rất nhiều rắc rối.
- Khả năng mở rộng: Đừng xây dựng cho sự tăng trưởng giả định. Hãy xây dựng cho lộ trình cụ thể mà bạn có thể nhìn thấy.
Nếu câu trả lời của bạn là "chưa," hãy xây dựng một modular monolith.
Đừng yêu cầu microservices chỉ vì từ đó nghe có vẻ hiện đại. Hãy nói với đối tác của bạn về việc sản phẩm làm gì và ai sẽ là người duy trì nó.
Sản phẩm thất bại vì chúng không bao giờ được ra mắt. Một kiến trúc monolith sạch sẽ là cách nhanh nhất để tiếp cận người dùng. Hãy xây dựng điều đó trước tiên. Hãy để lưu lượng truy cập cho bạn biết khi nào đến lúc cần tách rời chúng ra.
Cộng đồng học tập tùy chọn: https://t.me/GyaanSetuAi