Microservice Cho Doanh Nghiệp

Tài liệu

MICROSERVICE

TÀI LIỆU MICROSERVICE

Mục Lục
1

2

Tổng quan tài liệu...................................................................................................2
1.1

Mục đích tài liệu...................................................................................................2

1.2

Phạm vi tài liệu.....................................................................................................2

1.3

Thuật ngữ và viết tắt.............................................................................................3

Mục Lục.................................................................................................................. 3
2.1

Công Nghệ Nền Tảng...........................................................................................3

2.1.1

Triển khai đa nền tảng....................................................................................3

2.1.2

Tương thích với các thư viện backend hiện có của hệ sinh thái.....................4

2.1.3

Yêu cầu về công nghệ và các thư viện - patterns áp dụng..............................4

2.2

Chức Năng Kiến Trúc...........................................................................................7

2.2.1

Mỗi service được cài đặt trên một máy chủ riêng biệt....................................7

2.2.2

Áp dụng API Gateway điều hướng các service..............................................8

2.3

Triển Khai...........................................................................................................29

2.3.1

Triển Khai On -Primises (Triển khai máy chủ tại chỗ).................................29

2.3.2

Triển Khai Trên Cloud.................................................................................31

2.4

Quản Trị Microservice........................................................................................33

2.4.1

Thành phần trong microservice....................................................................33


Tài liệu

MICROSERVICE

2.4.2
2.5

Vận hành microservice.......................................................................................43

2.5.1

Yêu cầu phần cứng.......................................................................................43

2.5.2

Công cụ triển khai........................................................................................44

2.5.3

Yêu cầu nguồn lực.......................................................................................44

2.6

1

Công cụ quản lý Microservice......................................................................37

Xử lý các sự cố trên microservie.........................................................................45

2.6.1

Phản hồi chậm..............................................................................................45

2.6.2

Service ngừng hoạt động do quá tải hoặc timeout........................................45

2.6.3

Lỗi đồng nhất dữ liệu trên các service..........................................................46

2.6.4

Lỗi API Gateway..........................................................................................46

2.6.5

Lỗi Connection refused................................................................................47

TỔNG QUAN TÀI LIỆU

1.1 Mục đích tài liệu
 Tài liệu này nhằm đặc tả yêu cầu người sử dụng cho hệ thống microservice
1.2 Phạm vi tài liệu
 Tài liệu này dành cho Tech Lead, Dev, Devops,Software Architecture.
 Tài liệu là bộ tài liệu “Mô tả xây dựng hệ thống Microservice” với các phần:
 Công Nghệ Nền Tảng
 Chức Năng Kiến Trúc


Tài liệu

MICROSERVICE

 Triển Khai
 Quản Trị
 Vận Hành Kiến Trúc
1.3 Thuật ngữ và viết tắt

2

STT

Thuật ngữ/ Viết tắt

Ý nghĩa

1

HA

High Availability

2

REDUN

Redundancy(Dự phòng)

3

RELIABILITY

RELIABILITY (Độ tin cậy)

4

CQRS

Command and Query Responsibility Segregation

5

FAO

FAILOVER(Chuyển đổi dự phòng)

6

REPLICATION

REPLICATION(Sao chép)

7

RESILIENCY

RESILIENCY(Khả năng phục hồi)

8

SCALABILITY

SCALABILITY(Khả năng mở rộng)

9

MICROSERVICE

MIC

10

DDD

DOMAIN-DRIVEN DESIGN

MỤC LỤC

2.1 Công Nghệ Nền Tảng
2.1.1 Triển khai đa nền tảng
 Microservice phù hợp triển khai trên các nền tảng khác nhau,trên các ngơn

ngữ,database khác nhau,có thể triển khai trên cả windows lẫn linux,linh hoạt
về stack công nghệ.


Tài liệu

MICROSERVICE

2.1.2 Tương thích với các thư viện backend hiện có của hệ sinh thái
 Các thư viện trong phiên bản .Net 5.0 có khả năng tương thích với các thư

viện backend hiện tại,1 số thư viện cũ hơn sẽ cần điều chỉnh wrap lại hoặc
upgrade lên version mới hơn.

2.1.3 Yêu cầu về công nghệ và các thư viện - patterns áp dụng

 Về u cầu cơng nghệ để có thể triển khai,áp dụng mơ hình microservice cần
tối thiểu ASP.NET Core API phiên bản >= 2.0 trở lên,ngoài ra cần có các
yêu cầu về phần cứng,tối thiểu :
Bộ xử lý : 64 bit - 2 lõi, Ram : 2 GB , Ổ cứng : 32 GB
Theo khuyến nghị của microsoft và cộng đồng phát triển phiên bản .Net 5.0
là lựa chọn phù hợp cho việc nâng cấp bởi đây là phiên bản đầu tiên hợp
nhất giữa .NET Framework 4.8 và .NET Core 3.1 thành 1 nền tảng duy nhất
cho tất cả các loại ứng dụng gọi là .NET 5.0, còn .NET 6 là phiên bản lớn

tiếp theo của .NET 5.0 là bản hỗ trợ lâu dài (LTS) nên là phiên bản được
đánh giá hoạt động ổn định ,hỗ trợ hầu hết các thư viện cũ từ phiên bản .Net
3.0.
Chúng ta sẽ sử dụng mẫu pattern mở rộng Domain-Driven Design CQRS
để phát triển cho mơ hình microservice,lý do chọn pattern :
Domain-Driven Design CQRS sẽ xử lý các bài toán phát triển phần mềm
tập trung vào nghiệp vụ,mẫu pattern này có hơn 15 năm phát triển,có cộng
đồng sử dụng rộng lớn nên rất ổn định,dễ triển khai mở rộng.
Chúng ta phát triển ứng dụng phục vụ theo nhu cầu khách hàng nên không ai
hiểu các yêu cầu của hệ thống bằng khách hàng.
Khi khách hàng giải thích hệ thống cho chúng ta hiểu, họ sẽ giải thích về các
domain của nó. Chính vì thế các domain sẽ làm trọng tâm và cơng việc của


Tài liệu

MICROSERVICE

chúng ta là xây dựng nó thành các mơ hình để cho tất cả mọi người cùng
nắm vấn đề.
Do đó cần thiết kế sao cho khơng chỉ lập trình viên hiểu mà ngay cả khách
hàng, những người không hiểu biết về mặt kỹ thuật cũng có thể nhìn vào
nắm được trọng tâm của vấn đề.
Về kiến trúc :
CQRS là sử mở rộng của mơ hình trong DDD. Đặc trưng quan trọng của
CQRS là việc tách hai phần logic đọc và ghi dữ liệu ra hai phần riêng biệt:
Phần ghi dữ liệu: được thực hiện qua việc send các command tới các handler
thơng qua command bus. Comand hanlder đóng vai trò tương tự domain
service sẽ tương tác với các model để thực hiện các nghiệp vụ thay đổi dữ
liệu.

Phần đọc dữ liệu: được thiết kế riêng không lệ thuộc vào các model của phần
ghi dữ liệu. Do đó có thể linh hoạt trong việc truy xuất database, cũng như
sử dụng các data source khác nhau để tối ưu về tốc độ truy xuất.


Tài liệu

MICROSERVICE


Tài liệu

MICROSERVICE

Với các hệ thống lớn mơ hình CQRS sẽ giải quyết tốt các vấn đề:
 Cho phép phát triển và tối ưu phần đọc dữ liệu riêng biệt với phần ghi
dữ liệu.
 Việc mơ hình hố các nghiệp vụ ghi dữ liệu dưới các command cho
phép che đậy tốt các logic nghiệp vụ, giúp việc mở rộng dễ dàng hơn.
 Tính sẵn sàng (high availability) và tính nhất quán mơ hình dữ liệu.
 Cho phép xử lý các nghiệp vụ logic phức tạp

2.2 Chức Năng Kiến Trúc
2.2.1 Mỗi service được cài đặt trên một máy chủ riêng biệt

 Trong microservices, các chức năng được tách thành nhiều microservices và
nếu sử dụng cùng một cơ sở dữ liệu trung tâm thì microservices khơng cịn
độc lập. Thay đổi dữ liệu của một service có thể làm hỏng các services khác.
Do đó, mỗi microservice phải có cơ sở dữ liệu riêng.

Tài liệu

MICROSERVICE

 Mỗi service có thể có một CSDL riêng biệt để lưu trữ thông tin cần
thiết cho nghiệp vụ của service đó.
 Một microservice chỉ có thể truy xuất vào CSDL riêng của nó mà
khơng có quyền truy xuất vào CSDL của microservices khác.
 Trong một số hoàn cảnh, để hoàn thành một tác vụ cần phải cập
nhật nhiều CSDL. Khi đó CSDL của microservices khác chỉ nên
được cập nhật qua API của những dịch vụ này (không trực tiếp thay
đổi CSDL).
Việc phân tách tách các microservices cho phép lựa chọn các công nghệ
quản lý dữ liệu khác nhau (SQL hay NoSQL,...nhiều CSDL khác nhau
cho các microservices). Tuy nhiên, với các giao dịch phức tạp liên quan
đến nhiều microservices, giao dịch phải được thực hiện qua API.

2.2.2 Áp dụng API Gateway điều hướng các service

 Điều hướng các service trên một domain duy nhất :
Điều này cho phép che giấu thơng tin hệ thống với bên ngồi,giảm thiểu
các vấn đề về bảo mật khi mà có quá nhiều các services được public ra
internet. Hơn nữa các vấn đề về xác thực (authentication), phân quyền, SSL.


Tài liệu

MICROSERVICE

Khi backend mở rộng, client cũng dễ nâng cấp vì chỉ cần truy cập đến các
route của API Gateway thay vì trỏ đến các services mới.
Từ ASP.NET Core API phiên bản 2.0 trở lên đều hỗ trợ thiết kế
Microservices và đặc biệt là thiết kế API Gateway với Ocelot hoặc Azure.

 Cân bằng tải và giám sát các hoạt động của các service:
API Gateway kiêm cả vai trò load balancer của hệ thống,requests không
được gửi trực tiếp đến backend nên giảm tối đa rủi ro hệ thống bị quá
tải,ngăn các cuộc tấn công bằng cách thêm lớp bảo vệ các loại tấn công như
ddos, slq injections,...
 Giám sát, cảnh báo, tình trạng các service :

Trong hệ thống microservice,yêu cầu khi vận hành là cần đội ngũ
Devops/Operator/System Admin có kinh nghiệm và 1 hệ thống
Monitoring-Alert, hệ thống monitoring này hiện có nhiều bộ cơng cụ open


Tài liệu

MICROSERVICE

source để monitor. Chẳng hạn như Signoz, Prometheus, Grafana
,Pinpoint,Zabbix,ELK Stack v.v.
Có thể tham khảo một số cơng cụ phía trên như sau để áp dụng :

Prometheus:
 Mơ hình dữ liệu đa chiều
 Ngôn ngữ truy vấn linh hoạt
 Hỗ trợ nhiều biểu đồ
 Dễ dàng cấu hình cảnh báo

 Chỉ cần 1 máy chủ là có thể hoạt động được
 Hỗ trợ Push các time-series thông qua 1 gateway trung gian.
 Prometheus sử dụng Alert manager để lý và gửi cảnh báo đi
 Prometheus cung cấp giao diện đơn giản đề tạo truy vấn và hiển thị
biểu đồ
 Kết hợp với Grafana để hiện thị dữ liệu dưới dạng nhiều kiểu biểu
đồ khác nhau.


Tài liệu

MICROSERVICE

Signoz:
 Cung cấp giao diện người dùng tích hợp cho metric & traces
 Chạy các truy vấn dành riêng cho doanh nghiệp
 Chạy aggregation trên các tag tùy chỉnh
 Cung cấp hỗ trợ gốc cho OpenTelemetry
 Được xây dựng bằng cách sử dụng modern stack bao gồm Golang
và React trong TypeScript.


Tài liệu

MICROSERVICE

 Cài đặt dễ dàng sau khi đáp ứng được các yêu cầu tối thiểu.
 Bảo trì thiết lập tương đối dễ dàng,giúp cải thiện hiệu suất.

 Cấu hình đồng bộ dữ liệu giữa các service với nhau

Trong giao tiếp giữa các service cần sự đồng bộ (nghĩa là service này
gọi service khác và chờ đợi phản hồi để thực hiện tiếp ) ta có 1 số
phương thức giao tiếp phổ biến như sau :
 Giao tiếp qua HTTP/2


Tài liệu

MICROSERVICE

Với giao thức HTTP/2 ta có một cơng nghệ hỗ trợ rất tốt của
Google là gRPC. gRPC tối ưu hoá và tăng tốc việc giao tiếp
giữa các service với nhau trong kiến trúc microservice. Sử dụng
protocal Buffer giúp giảm kích thước Request và Response data,
RPC đơn giản trong việc tạo ra các giao tiếp giữa các service
với nhau.

 Giao tiếp qua REST API (Restful API sử dụng giao thức
HTTP/1)
Với cách giao tiếp này ta sẽ gọi service trực tiếp,toàn bộ logic
định tuyến message nằm trên mỗi điểm cuối và các service có


Tài liệu

MICROSERVICE

thể giao tiếp trực tiếp. Mỗi microservice sẽ expose một REST
API và một microservice cụ thể hoặc một client bên ngồi có

thể gọi một microservice khác thơng qua REST API của nó.

 Giao tiếp qua API Gateway


Tài liệu

MICROSERVICE

Theo phương thức giao tiếp này, tất cả yêu cầu từ client đều đi
qua cổng kết nối API. Sau đó cổng kết nối API định tuyến các
yêu cầu này tới từng microservice phù hợp. Cổng kết nối API
Gateway sẽ xử lý yêu cầu người dùng bằng cách gọi đến service
thông qua REST API.

 Giao tiếp qua Message Broker
Mỗi một service đóng vai trị là nguồn cấp message gửi các
message khơng đồng bộ đến một queue hoặc topic. Sau đó


Tài liệu

MICROSERVICE

những microservice xử lý message đó sẽ lấy nguồn từ một
queue hoặc topic. Kiểu giao tiếp này sẽ tách biệt nguồn cung
message và nơi cần sử dụng message. Nó sử dụng một khu vực
trung gian để lưu trữ các message cho đến khi những service
cần đến có thể xử lý những message đó. Như vậy, các
microservice gửi message sẽ không hề biết những microservice

nào sử dụng message.

 Lưu lịch sử đồng bộ - tự động đồng bộ khi mất kết nối,mất điện

 Khi có lỗi xảy ra chúng ta phải biết được điều gì đang hoạt động
sai,nguyên nhân gây ra lỗi. Điều đó có nghĩa là phải có hệ thống log


Tài liệu

MICROSERVICE

tốt để có thể tìm ra ngun nhân dẫn đến lỗi, một hệ thống Log trung
tâm mà tất cả các microservice sẽ gửi log message đến và cho phép
điều tra, tìm kiếm bất cứ khi nào muốn.


Ta có thể sử dụng Sentry hoặc ELK Stack,đây là 1 trong 2 open
source phần mềm mã nguồn mở được đông đảo cộng đồng sử dụng
cho phép ghi lại lịch sử đồng bộ,phát hiện, theo dõi, hỗ trợ sửa lỗi
theo thời gian thực, nâng cao trải nghiệm của người dùng.

 Trong quá trình vận hành các service,thực tế ln có các sự cố về mất
kết nối mạng,mất điện hoặc do các nguyên nhân bất khả kháng làm
cho hệ thống bị ngắt,bị downtime ảnh hưởng đến hoạt động cơng ty
do đó ta cần có cơ chế tự theo dõi các service và tự động khởi
động,đồng bộ lại giữa các service với nhau,để làm điều này chúng ta
cần áp dụng Health Check một open source cho phép kiểm tra real –
time sự hoat động của các service ,phát hiện service nào đang
stop,service nào đang chạy ổn định qua đó có cơ chế cấu hình cho

phép chạy các job tự động để khôi phục hệ thống nhanh chóng.

 Xử lý sự cố trên các microservice
a. Các service hoạt động độc lập, một service bị sự cố sẽ khơng ảnh

hưởng tới các service cịn lại.


Tài liệu

MICROSERVICE

Để xử lý vấn đề này ta sẽ vận dụng mơ hình vách ngăn (Bulkhead
Pattern).
Mơ hình thiết kế này giúp hệ thống vẫn vận hành tốt khi lỗi xảy ra ở
một service con. Trong thiết kế vách ngăn, các yếu tố của một hệ
thống được phân lập thành các nhóm để nếu một service bị lỗi, những
services khác sẽ tiếp tục hoạt động. Nó được đặt tên dựa theo thiết kế
phân vùng (vách ngăn) của thân tàu. Khi gặp sự cố thân tàu bị xâm
nhập, chỉ có phần bị hư hỏng mới bị chìm,các bộ phận khác vẫn hoạt
động bình thường. Để đạt được các yếu tố trên, cần vận dụng các
pattern như single-responsibility pattern, asynchronouscommunication pattern, fail-fast hay failure-handling patterns, …

b. Giải pháp HA (High Availability) cho toàn bộ hệ sinh thái
Hệ thống chịu tải,tính sẵn sàng cao có 3 yếu tố quan trọng
quyết định hệ thống có bền vững,ổn định hay không gồm:
Performance, Availability, và Scalability


Tài liệu

MICROSERVICE

 Performance: Tốc độ phản hồi của hệ thống, được đo
bằng đơn vị thời gian, có thể là giây hoặc mili giây. Hệ
thống hoạt động càng nhanh thì người dùng làm được
nhiều việc hơn, đem lại lợi ích to hơn. Hệ thống quá
chậm sẽ đem lại trải nghiệm không tốt,ít hoặc khơng có
ai sử dụng.

 Availability: Tính sẵn sàng hoạt động của hệ thống vào
mọi thời điểm, được đo bằng uptime.
Ví dụ như trong 100 ngày, hệ thống hoạt động 99 ngày
cịn 1 ngày die thì uptime là 99/100 = 99%.
Uptime của các hệ thống lớn như Facebook, Google,
Uber phải luôn >99%, chỉ cần ngưng hoạt động vài phút
là các cơng ty sẽ thiệt hại từ vài nghìn cho tới vài triệu
đô.

 Scalability: Khả năng mở rộng của hệ thống. Liệu khi
có đơng user hơn thì hệ thống có thể mở rộng (scale)
được khơng? Việc scale có thể thực hiện dễ dàng, nhanh
chóng hay khơng? Chi phí scale như nào?
Ví dụ: lượng người dùng tăng gấp 10, ta chỉ cần tăng gấp 2
hoặc gấp 5 lần server là phục vụ được, hệ thống có scalability
cao. Tuy nhiên, nếu lượng user tăng gấp 100 lần server,lúc này
không thể thêm server để phục vụ chừng đó người dùng,thì tính
scalability thấp sẽ dẫn đến sập hệ thống là điều không tránh
khỏi.

Tài liệu

MICROSERVICE

Do đó để hệ thống đáp ứng HA,ta có thể kết hợp 1 số giải pháp
kỹ thuật như sau :

- Load Balancing nhiều lớp (LB) :
Load Balancing là một thiết bị (phần cứng hoặc phần mềm) cho
phép cân bằng tải đến nhiều server.
LB giúp hệ thống phân tải các request tới đều các Server
(Application hoặc Database),cơ chế làm việc của LB liên tục
kiểm tra trạng thái của các server trong hệ thống, nếu trạng thái
của server là khỏe mạnh (healthy) nó sẽ gửi quest tới,nếu server
unavailable hoặc khơng có response trả về LB sẽ khơng gửi
request tới server đó nữa,cho tới khi server đó khơi phục trở lại
thì LB sẽ thêm lại server đó vào.
Bằng cách cân bằng tải các request tới ứng dụng trên nhiều
server, LB sẽ giảm tải cho từng server,ngăn bất kỳ một máy chủ
server nào trở thành một điểm lỗi duy nhất (Single point of
failure) , do đó cải thiện khả năng đáp ứng và tính sẵn sàng của
ứng dụng. Nhất là khi scale hệ thống theo chiều ngang
(horizontal scaling)


Tài liệu

MICROSERVICE

Có nhiều thuật tốn để LB điều phối các request tới các resource,đơn
giản,phổ biến nhất là sử dụng thuật tốn “Round Robin” (thuật tốn ln
chuyển vịng), theo đó các máy chủ sẽ được xem ngang hàng và sắp xếp
theo một vòng quay, các truy vấn dịch vụ sẽ lần lượt được gửi tới các
máy chủ theo thứ tự sắp xếp. Ngồi ra cịn rất nhiều thuật tốn phức tạp
khác, tuy nhiên trên thực tế chưa có một thuật tốn LB nào thực sự hồn
hảo,chỉ mang tính tương đối.


Tài liệu

MICROSERVICE

- Triển khai Kubernetes cluster pattern:

Kubernetes là nền tảng mã nguồn mở, chạy trong môi trường production,
thiết kế và phát triển bởi Google, kết hợp với những ý tưởng tốt nhất từ cộng
đồng,là tập hợp các máy chủ (node) để chạy các ứng dụng được
tạo trong Container.

Với mơ hình Kubernetes cluster ứng dụng luôn sẵn sàng hoạt động 24/7
cho phép lập trình viên triển khai liên tục các phiên bản của ứng dụng nhiều
lần trong ngày. Việc đóng gói ứng dụng vào container giúp ứng dụng phát
hành, cập nhật dễ dàng, nhanh chóng khơng có downtime. Kubernetes giúp
đảm bảo các ứng dụng container chạy ở bất kì đâu, bất kì lúc nào chúng ta
mong muốn.Do đó đây cũng là giải pháp HA lý tưởng đảm bảo tính sẵn sàng
cao của hệ thống.


Tài liệu

MICROSERVICE

- Triển khai high availability cho database gồm:
a. Streaming replication
Streaming replication giúp ta xây dựng 1 hệ thống database dự
phòng cho database PostgreSQL,cho phép truy vấn dữ liệu trên
database dự phịng, giúp giảm tải cho database chính.
Streaming Replication hoạt động dựa trên việc chuyển các WAL
file từ database chính (hay master) sang database dự phịng (hay
slave). Sau đó, áp dụng các WAL file này vào database dự phòng.
Trong cộng đồng kỹ thuật hay gọi đó là tiến trình recovery, apply
hoặc replay.


Tài liệu

MICROSERVICE

b. Load Balancing + Failover cho PostgreSQL
Trong hệ thống lớn,nếu dồn toàn bộ yêu cầu xử lý tập trung vào
một database server sẽ đem lại rủi ro rất cao,dẫn đến quá tải và
phụ thuộc. Scale sẽ giảm áp lực cho database chính và tăng khả
năng chịu tải của hệ thống,khi scale cũng đặt ra một số vấn đề
như dữ liệu không đồng nhất giữa các database scale, khiến dữ
liệu bị sai lệch giữa các lần truy cập, việc insert dữ liệu xảy ra
đồng thời giữa các database server, khiến việc conflict dẫn đến
gây lỗi và dữ liệu không đồng nhất. Ngồi ra, quản lý các
database scale khơng hiệu quả sẽ lãng phí và khiến hiệu suất
giảm thiểu.

Tài liệu

MICROSERVICE

Để giải quyết vấn đề này, ta cần thiết kế một mơ hình master-slave,
theo đó master đóng vai trị là database chính - đóng vai trị thực hiện
xử lý câu lệnh insert, update, delete. Các database slave được đồng bộ
dữ liệu từ master, slave đóng vai trị read-only, chỉ thực hiện được câu
lệnh select ở slave.
Khi đó các câu lệnh truy vấn select sẽ được chia đều ra các slave +
master, giảm áp lực đến database master. Bởi dữ liệu chỉ insert, update,
delete vào một master duy nhất, nên việc insert đồng thời giữa các