Kiến trúc microservice cơ bản

Bài đăng này đã không được cập nhật trong 2 năm

Bài viết này là bài viết đầu tiên của tôi về kiến trúc Microservice sau một thời gian khá ngắn tìm hiểu trực tiếp về nó, do vậy có thể sẽ có những nội dung không thưc sự đúng với mô hình gốc. Nếu bạn có góp ý gì vui lòng thảo luận thêm vào bình luận bên dưới.

Microservices - một ý tưởng xuất hiện từ năm 2014.

Kiến trúc ứng dụng

1. Monolithic

Khởi đầu với các mẫu kiến thúc monolithic, khi mà tất cả các module, service đều được tích hợp vào trong một project duy nhất. Ví dụ như hệ thống web bán hàng phát triển bằng php-mysql...

Với kiến trúc này chúng ta có thể dễ dàng xây dựng với các ứng dụng nhỏ. Nhưng vấn đề xảy ra khi hệ thống lớn lên:

Phân chia Team code
Muốn maintain phải hiểu cả hệ thống
Hệ thống chạy nặng nề và khó khăn khi muốn thay đổi công nghệ

2. SOA (Service oriented architecture)

Sau những hạn chế của monolithic thì kiến trúc SOA được sinh ra giải quyết với những hệ thống lớn, các thành phần của nó được phát triển riêng rẽ độc lập.

Trong kiểu kiến trúc này hệ thống được chia thành nhiều module nhỏ. Mỗi module được cung cấp dưới dạng gói service với nhiệm vụ riêng như: service payment, sso, ...

Tuy nhiên nó vẫn gặp phải một vấn đề là khả năng khắc phục lỗi khi 1 service gặp vấn đề, cũng như khả năng mở rộng hệ thống.

P/S: Trong cộng đồng phần mềm có nhiều hoài nghi rằng microservices không hề có gì mới mẻ. những người này cho rằng các ý tưởng về microservices chỉ là một hình thức làm khác của SOA (Service-Oriented Architecture) hay còn được hiểu là kiến trúc hướng dịch vụ.

Các chiều scale hệ thống

Thời gian gần đây chúng ta nghe đến rất nhiều đến khái niệm scale, HA, cluster vậy thực sự nó là gì? Trong một hệ thống chúng ta có thể quy ra làm 3 chiều mở rộng hệ thống.

Nhân bản và Blancer
Chia nhỏ và phân tải theo loại request (payment, content)
Sharding

Nếu hệ thống của chúng ta có thể đáp ứng cả 3 điều trên thì gần như chúng ta có thể mở rộng hệ thống một cách vô hạn.

Tại sao chúng ta cần kiến trúc này?

Hãy quay trở lại vấn đề đã nêu ở trên, khi một phần của hệ thống monolithic bị lỗi? hay khi một service của SOA bị lỗi thì điều gì sẽ xảy ra? Trong kinh nghiệm xây dựng các hệ thống kiểu SOA, thì gần như hệ thống lúc đó sẽ sụp đổ hoặc hoạt động sai lệch.

Với kiến trúc microservice, vấn đề này được giải quyết bằng cách cố gắng chia hệ thống thành các thành phần rất nhỏ, có khả năng tự nhân bản khi một instance bị lỗi và đảm bảo lỗi chỉ xảy ra cục bộ và hệ thống không sụp đổ. Vậy nhỏ đến mức nào là đủ? có một vào hướng dẫn rằng nhỏ đến mức có thể xây dựng lại toàn bộ thành phần đó trong vòng 10 ngày là đủ.

Làm thế nào để xây dựng theo kiến trúc microservice

Chúng ta có một vài mẫu thiết kế có thể sử dụng trong việc xây dựng các microservice nhằm đảm bảo nó có thể: Tự nhân bản và khắc phục lỗi cục bộ.

12 factor

Codebase: One codebase tracked in revision control, many deploys
Dependencies: Explicitly declare and isolate dependencies
Config: Store config in the environment
Backing services: Treat backing services as attached resources
Build, release, run: Strictly separate build and run stages
Processes: Execute the app as one or more stateless processes
Port binding: Export services via port binding
Concurrency: Scale out via the process model
Disposability: Maximize robustness with fast startup and graceful shutdown
Dev/prod parity: Keep development, staging, and production as similar as possible
Logs: Treat logs as event streams
Admin processes: Run admin/management tasks as one-off processes