Mã nguồn mở

1. Giới thiệu chung về Monolithic Architecture

1.1 Monolithic Architecture là gì?

Monolithic Architecture là kiểu kiến trúc phần mềm trong đó toàn bộ ứng dụng được xây dựng như một khối thống nhất (monolith). Tất cả các thành phần như giao diện người dùng (UI), xử lý nghiệp vụ (business logic), và truy cập dữ liệu (data access) đều được tích hợp chung trong một ứng dụng duy nhất, chạy trên một tiến trình (process) hoặc một máy chủ. Điều này khiến việc triển khai (deployment) và quản lý ban đầu trở nên đơn giản, đặc biệt phù hợp cho các ứng dụng nhỏ hoặc ở giai đoạn khởi đầu.

1.2 Những trở ngại gặp phải của Monolithic Architecture

Mặc dù ban đầu dễ phát triển và triển khai, nhưng khi ứng dụng lớn dần lên, Monolithic Architecture bộc lộ nhiều hạn chế:

• Khó mở rộng (Scalability): Toàn bộ ứng dụng phải mở rộng cùng nhau thay vì chỉ mở rộng phần cần thiết. Ví dụ: nếu chỉ một module xử lý thanh toán cần nhiều tài nguyên hơn, vẫn phải scale cả hệ thống.
• Triển khai phức tạp (Deployment complexity): Chỉ cần thay đổi một chức năng nhỏ cũng buộc phải build và triển khai lại toàn bộ ứng dụng.
• Khó bảo trì và phát triển (Maintenance & Development): Khi số lượng dòng code lớn, việc tìm hiểu, sửa lỗi, hoặc thêm chức năng mới sẽ mất nhiều thời gian và dễ gây lỗi dây chuyền.
• Độ tin cậy thấp (Reliability): Một lỗi ở bất kỳ module nào cũng có thể khiến toàn bộ ứng dụng ngừng hoạt động.
• Giới hạn công nghệ (Technology lock-in): Khó áp dụng nhiều công nghệ khác nhau cho từng phần hệ thống (ví dụ: muốn module này dùng Java, module kia dùng Python).

1.3 Tại sao lại chuyển sang dùng Microservices?

Chính những hạn chế trên là động lực để các tổ chức dần chuyển sang Microservices Architecture – một kiến trúc trong đó ứng dụng được chia nhỏ thành nhiều dịch vụ độc lập (microservices), mỗi dịch vụ có chức năng riêng, có thể phát triển, triển khai và mở rộng tách biệt.

Lợi ích của Microservices so với Monolithic:

• Dễ mở rộng: Chỉ cần scale các dịch vụ cần nhiều tài nguyên.
• Triển khai linh hoạt: Có thể cập nhật từng dịch vụ mà không ảnh hưởng đến toàn hệ thống.
• Khả năng chịu lỗi cao: Nếu một dịch vụ gặp sự cố, các dịch vụ khác vẫn hoạt động.
• Đa dạng công nghệ: Mỗi dịch vụ có thể sử dụng công nghệ, framework, ngôn ngữ lập trình phù hợp nhất.
• Dễ bảo trì và phát triển: Các nhóm phát triển có thể làm việc song song trên các dịch vụ khác nhau mà ít xung đột.

2. Tìm hiểu về Microservices Architecture

2.1 Microservices Architecture là gì?

Microservices Architecture là một phong cách kiến trúc phần mềm trong đó ứng dụng được chia thành nhiều dịch vụ nhỏ, độc lập (microservices). Mỗi microservice đảm nhiệm một chức năng nghiệp vụ riêng biệt, có cơ sở dữ liệu và vòng đời triển khai riêng. Các microservice giao tiếp với nhau thông qua giao thức nhẹ (thường là HTTP/REST, gRPC, hoặc message queue). Kiến trúc này cho phép các nhóm phát triển làm việc song song, triển khai nhanh chóng và dễ mở rộng theo nhu cầu.

2.2 Ưu điểm của Microservices

• Khả năng mở rộng linh hoạt (Scalability): Chỉ cần scale những dịch vụ cần nhiều tài nguyên thay vì toàn bộ hệ thống.
• Triển khai độc lập (Independent Deployment): Cập nhật hoặc thay đổi một dịch vụ không làm gián đoạn toàn bộ ứng dụng.
• Khả năng chịu lỗi cao (Fault Isolation): Lỗi trong một microservice ít ảnh hưởng đến các dịch vụ khác.
• Đa dạng công nghệ (Polyglot): Các dịch vụ có thể viết bằng nhiều ngôn ngữ, framework, hoặc cơ sở dữ liệu khác nhau.
• Hỗ trợ tổ chức đội ngũ (Team autonomy): Mỗi nhóm phát triển có thể phụ trách một dịch vụ riêng, tăng tốc độ phát triển.

2.3 Nhược điểm của Microservices

• Độ phức tạp cao (Complexity): Việc quản lý nhiều dịch vụ nhỏ, phụ thuộc lẫn nhau, khó hơn một hệ thống monolithic.
• Chi phí vận hành (Operational Overhead): Cần hạ tầng phức tạp hơn để triển khai, giám sát, logging, monitoring.
• Communication overhead: Các dịch vụ phải giao tiếp qua mạng, làm tăng độ trễ và rủi ro khi kết nối.
• Quản lý dữ liệu phân tán: Mỗi dịch vụ có cơ sở dữ liệu riêng, việc đồng bộ dữ liệu và transaction xuyên dịch vụ trở nên khó khăn.
• Triển khai đòi hỏi DevOps mạnh: Cần CI/CD, container (Docker), orchestrator (Kubernetes) để quản lý.

2.4 Chuyển từ Monolithic sang Microservices

Quá trình chuyển đổi thường theo lộ trình:

1. Phân tích hệ thống monolithic: Xác định các module chính (User, Order, Payment, Inventory...).
2. Tách dịch vụ theo domain: Mỗi domain nghiệp vụ thành một microservice riêng.
3. Xây dựng API Gateway: Là cổng trung gian để client giao tiếp với các microservices.
4. Dùng container hóa: Docker/Kubernetes để đóng gói và triển khai microservices.
5. Tích hợp CI/CD: Đảm bảo triển khai nhanh chóng, liên tục.
6. Giám sát và logging: Sử dụng các công cụ như Prometheus, Grafana, ELK stack.

2.5 Communication giữa các Microservices

Có hai cách giao tiếp chính:

• Synchronous (đồng bộ): REST API, gRPC. Thường dùng cho yêu cầu trực tiếp từ client → service.
• Asynchronous (bất đồng bộ): Message broker (RabbitMQ, Kafka). Dùng cho luồng dữ liệu lớn, xử lý song song, hoặc event-driven architecture.

2.6 Quản lý source code của Microservices

Có hai mô hình chính:

• Monorepo: Tất cả microservices nằm trong một repository chung. Ưu điểm: dễ quản lý version, CI/CD tập trung. Nhược điểm: repo lớn, khó kiểm soát khi team đông.
• Polyrepo (Multi-repo): Mỗi microservice có repo riêng. Ưu điểm: độc lập, dễ trao quyền cho từng team. Nhược điểm: khó đồng bộ dependency và version giữa các repo.

Thực tế, nhiều công ty chọn multi-repo cho các dịch vụ cốt lõi nhưng vẫn có monorepo cho dịch vụ nhỏ để giảm phức tạp.

So sánh Monolithic vs. Microservices

So sánh Monolithic vs. Microservices

(còn tiếp)