The Lego Monolith — A Monolith Microservice Proof of Concept

Slalom Build · 2016 · 1. Khởi đầu · Độ khó: Dễ — bài gốc

Bài đề xuất kèm proof of concept của một kiến trúc sư công ty tư vấn (Slalom), không phải hệ thống production. Mọi nhận định là "theo tác giả Slalom".

Bối cảnh

• Năm 2016, microservices đang được nói nhiều. Theo tác giả, muốn làm microservices đầy đủ thì tổ chức phải "đủ cao" trước: cấp máy nhanh (tốt nhất là cloud), monitoring đủ trưởng thành cho tracing tương quan, circuit breaker, tự hồi phục, continuous deployment và văn hoá DevOps, autoscale từng service, quản trị hợp đồng giữa service. Nhiều tổ chức chưa có các thứ đó.

Thay đổi chính

• "Lego monolith": nhiều bounded context trong một repo và một đơn vị deploy. Mỗi service là một nhóm module Gradle riêng (web, service, data), phụ thuộc giữa module được khai báo sao cho không gọi tắt được, ví dụ không gọi DAO của service khác.
• Service chỉ nói chuyện với nhau qua interface tách rời: REST (dù chạy chung process) hoặc message queue bất đồng bộ. Ví dụ trong POC: tạo đơn bán gọi REST sang service sản phẩm để kiểm tồn kho, lưu đơn, rồi publish sự kiện; service sản phẩm nghe sự kiện và trừ tồn kho theo eventual consistency.
• Mỗi service sở hữu nguồn dữ liệu riêng, có cấu hình Spring Boot riêng (cổng, datasource). Mẹo để chạy chung một classpath: đặt namespace cho profile để cấu hình không rò sang nhau, giới hạn @ComponentScan trong package của từng service.

Vì sao

• Theo tác giả: được phần lớn lợi ích của tách service (thiết kế tách rời, chọn ngôn ngữ JVM và kiểu lưu trữ riêng, bất đồng bộ) mà không phải trả trước chi phí vận hành phân tán. Một codebase thì miền nghiệp vụ còn đang đổi dễ sắp xếp lại hơn, dời code giữa service đơn giản hơn nhiều repo. Khi cần, tách một service ra thành đơn vị deploy riêng với ít công sức.
• Giới hạn tác giả tự nêu: chỉ ngôn ngữ chạy trên JVM, không scale riêng từng service, vẫn phải quản trị hợp đồng, POC còn dùng chung model, API công khai vẫn cần tracing.

Bài học cho SWE

• Ranh giới service có thể dựng và ép bằng công cụ build trước khi tách process. Đó là phần khó, còn tách deploy là phần dễ về sau.
• Liệt kê điều kiện tiên quyết của microservices (provisioning, monitoring, CD, autoscale, hợp đồng) trước khi tách.
• Giao tiếp qua queue ngay trong monolith buộc phải chấp nhận eventual consistency sớm, nên khi tách ra sẽ ít bất ngờ hơn.

Liên quan

• Shopify 2019 (modular monolith ở quy mô lớn, 2019) · Shopify 2020 · Segment 2018
• Monolith và microservices — đi và quay lại