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

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.

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ụ.

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.

1. Nhân bản và Blancer
2. Chia nhỏ và phân tải theo loại request (payment, content)
3. 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.

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à đủ.

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

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

7 principles

1. Modlle around bussiness domain
2. Automation (CI, CD)
3. Hide implementation details
4. Decentalize any thing
5. Deploy independency
6. Isolate failure
7. Highly observer (monitor health of all)

Trong bài viết tới chúng ta sẽ cùng tìm hiểu cách refactor ứng dụng để trở nên microservice!

• Kiến trúc microservice cơ bản
• Microservices series in Nginx