Top 6 nguyên lý thiết kế microservices cho lập trình viên có kinh nghiệm

Với anh đã có kinh nghiệm thiết kế, phát triển các hệ thống có áp dụng các nguyên lý thiết kế microservices không còn là điều xa lạ.

Tuy nhiên với các anh em mới bắt đầu, việc áp dụng tốt các nguyên lý thiết kế microservices sẽ giúp anh em phát triển tốt hệ thống. Hệ thống cũng có thể scale up, scale down tốt về sau.

Bản thân các nguyên lý đã được đúc rút ra từ rất rất nhiều các lập trình viên có kinh nghiệm khi họ sử dụng microservices. Chính vì thế, anh em nên bỏ chút ít thời gian đọc và ghi nhớ các nguyên lý thiết kế này.

Các cụ dạy rồi, học từ cái ông đã làm sai, đã gặp vấn đề luôn là cách học tốt mà.

1. Single Responsibility Principle

Với anh em developer đã có kinh nghiệm thì nguyên lý này cũng không phải mới mẻ gì. Single Responsibility Principle là chữ S nằm trong SOLID. Mà SOLID thì quá nổi tiếng trong giới phần mềm.

Nội dung của nguyên lý này nói rằng mỗi microservices mà anh em thiết kế hoặc implement chỉ nên handle một công việc (handle only one thing). Microservices chỉ nên giao tiếp với microservices để hoàn thành task của nó. Nhưng về mặt lý thuyết, bản thân nó vẫn chỉ handle một việc duy nhất. Chính vì chỉ xử lý một việc duy nhất, nó đáp ứng được S trong SOLID.

Ví dụ: Anh em đang thiết kế hệ thống ecommerce. Thương mại điện tử yêu cầu người dùng đăng nhập, cho phép người dùng thanh toán đơn hàng. Trường hợp này ta cần hai microservices, một để xác thực người dùng (Authentication Service), microservice thứ hai dùng để thanh toán (Payment Service). Không nên viết một Service duy nhất mà ở đó xử lý cả việc Authentication và Payment.

  Microservices: Cưỡi ngựa xem hoa

2. Decentralized Data Management (Dữ liệu phi tập trung)

Trái ngược với dữ liệu tập trung (Centralized). Nguyên lý này trong thiết kế microservices khuyên ta nên thiết kế sao cho dữ liệu không tập trung ở một nơi (Decentralized).

Mỗi microservices nên quản lý dữ liệu của riêng nó. Việc mỗi microservices tự quản lý được data mà nó cần đảm bảo sự độc lập, khả năng mở rộng và độ tin cậy.

Anh em có thể đặt câu hỏi tại sao lại nói về độ tin cậy? Độ tin cậy ở đây được hiểu là khi một microservices khác down (hoặc gặp bất cứ vấn đề gì), các microservices được tin cậy vẫn có thể hoạt động bình thường (do bản thân không có liên kết gì với các microservices khác).

Như hình trên đây thì 3 microservices User, Messages, Friends. Bản thân mỗi microservices có một database riêng, MessageDB có thể dùng MongoDB, trong khi Users với Friends dùng các RDBMS khác?

Tới đây một số anh em có thể thắc mắc. Ủa rồi keep cho data độc lập ai chả muốn, nhưng nếu cần data ở microservices khác thì sao? Chẳng lẽ cứ giữ khăng khăng như thế? Đây đây, cái số 3 đây sẽ giải quyết vấn đề này.

Tham khảo việc làm PHP hấp dẫn trên TopDev

3. API-Driven Design

Nguyên lý thứ 3 trong nguyên lý thiết kế microservices là API-Driven. Bắt đầu với định nghĩa API-Driven ha.

API-driven development is the practice of designing and building APIs first, then creating the rest of an application around them.

Phát triển API-driven là thực hành thiết kế và xây dựng API trước, sau đó với xây dựng phần còn lại của ứng dụng xung quanh các API đã làm

Nguyên lý này vô cùng hữu ích khi thiết kế, xây dựng và làm việc với mô hình microservices. Theo nguyên lý này, microservices nên thiết kế xung quanh API. Mỗi microservices cung cấp rõ ràng một bộ API để giao tiếp với các microservices khác.

4. Stateless

Để hiểu được nguyên lý này, anh em cần phân biệt được sự khác nhau giữa Stateful và Stateless.

Trong các điểm khác biệt, có một điểm anh em cần lưu ý. Stateless sẽ không quan tâm tới state hiện tại của request. Nếu một microservices xử lý giỏ hàng của khách hàng trong hệ thống ecommerce, services đó sẽ không quan tâm trạng thái hiện tại của request là gì. Bản thân nó sẽ luôn xử lý request bằng cách lấy toàn bộ giữ liệu giỏ hàng và tiến hành bước tiếp theo.

Chính sự không quan tâm tới state hiện tại giúp bản thân microservices độc lập, có thể scale up và có độ ổn định cao.

Nhưng trong quá trình phát triển microservices. Giữ cho stateless không phải là dễ nha anh em.

5. Loose Coupling

Loose Coupling trong nguyên lý thiết kế microservices cũng giống như Loose Coupling trong hướng đối tượng (Object Oriented Design). Nguyên lý này nhắm tới việc loại bỏ một vài class, package và module.

Loose Coupling cũng mang ý nghĩa lỏng lẻo. Nguyên lý này nói rằng các microservices nên được liên kết lỏng lẻo với nhau, không nên liên kết chặt chẽ với nhau. Việc không có mối liên kết chặt chẽ giữa các microservice đảm bảo khả năng scale cho các microservices.

Như hình bên trái, các microservices có mối liên hệ chặt chẽ với nhau. Việc này dẫn tới các microservices bị phụ thuộc vào nhau, khó trở nên độc lập. Ngược lại, Loosely Coupled cho phép các microservices chỉ có một vài liên kết giữa các microservices.

6. Auto scaling

Nguyên lý cuối được đều cập liên quan tới nguyên lý thiết kế microservices là Auto-scaling (tự động mở rộng).

Thực chất một hệ thống khi lựa chọn áp dụng microservices, bản thân hệ thống đó đã cân nhắc hoặc ít nhất là có nhu cầu về scale (mở rộng). Bản thân mỗi microservices phải có thể tự mở rộng khi có nhiều hơn các request. Giảm bớt các instance đi trong trường hợp chỉ có số ít các request.

Ví dụ: nếu số lượng user truy cập tới microservices tăng, bản thân microservices phải tự mở rộng được. Khi user giảm truy cập, các instance trước đó phải được xoá bớt đi.

Hiện nay, Kubernetes có thể đáp ứng yêu cầu này. Nên lúc thiết kế anh em nhớ cân nhắc yếu tố Scaling để tận dụng tối đa Cloud, các công cụ như Kubernetes

Cụ thể như thế nào sẽ viết rõ cho anh em trong bài viết khác ha. Bài viết này chỉ nói về các principles (nguyên lý thôi)

7. Tham khảo thêm về thiết kế microservices

Một số cuốn sách cũng như tài liệu hay về nguyên lý thiết kế microservices anh em có thể tham khảo

• Stateful vs. Stateless: Understanding the Key Differences
• Pattern: Microservice Architecture
• Atomic design – Ưu nhược điểm từ kinh nghiệm thực tế

Cảm ơn anh em đã dành thời gian cho bài viết – Thank you for your time for article – Happy coding!

Tác giả: Kiên Nguyễn

Xem thêm:

• Building Microservices Application – Phần mở đầu: Bức tranh tổng thể
• Truy vấn dữ liệu MongoDB
• Software engineer phát triển bản thân như thế nào?

Xem thêm Việc làm Developer hấp dẫn trên TopDev