Giới thiệu tổng quan sơ bộ về Microservices

All about web applications and software engineering.

1. Microservices
SOLID
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

2. nhất mà ở đó xử lý cả việc Authentication và Payment.
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).

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

4. để 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.

5. 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).

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

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