Phát triển hệ phân tán với kiến trúc vi dịch vụ

HỌC VIỆN CÔNG NGHỆ BƢU CHÍNH VIỄN THÔNG
---------------------------------------

NGUYỄN THỊ MINH THỦY

PHÁT TRIỂN HỆ PHÂN TÁN VỚI KIẾN TRÚC VI DỊCH VỤ

LUẬN VĂN THẠC SĨ KỸ THUẬT
(Theo định hướng ứng dụng)

HÀ NỘI - 2016


HỌC VIỆN CÔNG NGHỆ BƢU CHÍNH VIỄN THÔNG
---------------------------------------

NGUYỄN THỊ MINH THỦY

PHÁT TRIỂN HỆ PHÂN TÁN VỚI KIẾN TRÚC VI DỊCH VỤ

CHUYÊN NGÀNH : HỆ THỐNG THÔNG TIN
MÃ SỐ:

0

60.48.01.04

LUẬN VĂN THẠC SĨ KỸ THUẬT
(Theo định hướng ứng dụng)
NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS. TS. HÀ HẢI NAM

HÀ NỘI - 2016


i

LỜI CAM ĐOAN
Lu n v n n y l th nh quả
giúp đỡ, khuyến khí h

qu tr nh họ t p nghi n

quý thầy

u

s u 2 n m t i theo họ

tạo Thạ sĩ, huy n ng nh Hệ thống th ng tin

t i

ng s

hương tr nh đ o

trường Họ viện C ng nghệ Bưu

hính Viễn th ng.
T i

m đo n đây l

ng tr nh nghi n

u

th m khảo v sử dụng một số th ng tin, t i liệu từ
k trong d nh mụ

ri ng t i. Nội dung

ó

nguồn s h, tạp hí đượ liệt

t i liệu th m khảo v đượ trí h dẫn hợp ph p.
TÁC GIẢ

Nguyễn Th Minh Thủy


ii

LỜI CẢM ƠN
T i xin gửi lời ảm ơn v tri ân tới

thầy

gi o,

n bộ

Họ viện

C ng nghệ Bưu hính Viễn th ng đã giúp đỡ, tạo điều kiện tốt ho t i trong qu
tr nh họ t p v nghi n

u hương tr nh Thạ sỹ.

T i xin gửi lời ảm ơn sâu sắ tới Phó gi o sư, Tiến sĩ H Hải N m đã t n
t nh hướng dẫn, giúp đỡ v động vi n t i để ho n th nh tốt nhất “Ph t triển hệ thống
phân t n với kiến trú vi dị h vụ”.
Do vốn kiến th

lý lu n v kinh nghiệm th

tiễn òn ít n n không tránh

khỏi những thiếu sót nhất định. T i xin trân trọng tiếp thu

ý kiến

để đượ ho n thiện.
T

giả.

Nguyễn Th Minh Thủy

thầy,

iii

MỤC LỤC
LỜI CAM ĐOAN ...................................................................................................... i
LỜI CẢM ƠN ........................................................................................................... ii
MỤC LỤC ................................................................................................................ iii
DANH MỤC TỪ VIẾT TẮT....................................................................................v
DANH MỤC CÁC HÌNH VẼ................................................................................. vi
MỞ ĐẦU ....................................................................................................................1
CHƢƠNG 1. TỔNG QUAN VỀ HỆ THỐNG VI DỊCH VỤ ................................4
1.1 Giới thiệu về hệ thống vi d ch vụ ...................................................................4
1.1.1

điểm

1.1.2 Ưu điểm
1.1.3 Nhượ điểm

kiến trú hệ thống vi dị h vụ ..............................................4
kiến trú hệ thống vi dị h vụ ...............................................8
kiến trú hệ thống vi dị h vụ .........................................9

1.2 So sánh kiến trúc vi d ch vụ với kiến trúc liên quan ..................................10
1.2.1 Kiến trú hệ thống nguy n khối Monilithi System .............................10
1.3 Mô hình nguyên mẫu ....................................................................................11
1.4 Các đặc trƣng của giao d ch trong hệ thống phân tán ..............................12
1.4.1 M h nh “h i gi i đoạn” ...........................................................................12
1.4.2 Mô hình Saga ...........................................................................................13

1.4.3 M h nh đ t hỗ Reserv tion .................................................................14
1.5 Kết luận Chƣơng 1 ........................................................................................15
CHƢƠNG 2. GIẢI PHÁP MÔ HÌNH HÓA HỆ PHÂN TÁN VỚI KIẾN TRÚC
VI DỊCH VỤ ............................................................................................................17
2.1 Mô hình h a các d ch vụ ...............................................................................17
2.2 Giải pháp tích hợp trong hệ phân tán với kiến trúc vi d ch vụ ................17
2.2.1 Phân tí h kiến trú hệ thống b n h ng KSS ..........................................17
2.2.2 Phân tí h th nh phần h

n ng “Cre te meeting from Absolon” ..........19


iv

2.2.3 Phân tí h nguy n mẫu hệ thống KSS ......................................................21
2.2.4 Sơ đồ lớp hi tiết .....................................................................................30
2.2.5 Biểu đồ tuần t .........................................................................................32
2.3 Kết lu n Chương 2 ..........................................................................................35
CHƢƠNG 3. CÀI ĐẶT VÀ THỬ NGHIỆM ........................................................37
3.1 Cài đặt các vi d ch vụ ....................................................................................37
3.1.1 Apache Kafka ...........................................................................................37
3.1.2 C i đ t

dị h vụ ..................................................................................37

3.2 Cấu hình lớp Cache .......................................................................................43
3.3 Triển khai thành phần xử lý ngắt ................................................................45
3.3.1 Luồng th ng điệp h

n ng Topi . re te_or_upd te_topi ...................46

3.4 Cài đặt hệ thống ............................................................................................46
3.4.1 C i đ t m y h v nguy n mẫu ..............................................................46
3.4.2 C i đ t m i trường JDeveloper
3.4.3 C i đ t K fk

Or le .............................................47

M y ảo ............................................................................47

3.4.4 C i đ t R bitMQ ......................................................................................47
3.4.5 C i đ t So pUI .........................................................................................47
3.4.6 C i đ t D t b se – MySQA .....................................................................48
3.4.7 Chạy h

n ng ........................................................................................48

3.5 Kết luận Chƣơng 3 ........................................................................................48
KẾT LUẬN ..............................................................................................................49
TÀI LIỆU THAM KHẢO ......................................................................................55


v

DANH MỤC TỪ VIẾT TẮT
KSS

Kostumer Sales System

Hệ thống b n h ng

MS

Microservice System

Hệ thống vi dị h vụ

MAS Microservice Architectuaral
Style

Kiểu kiến trú vi dị h
vụ


vi

DANH MỤC CÁC HÌNH VẼ
Hình 1-1 Phương th c hoạt động c a lu t Conway [8] .............................................5
Hình 1-2 Microservice application database [8] ........................................................7
Hình 1-3 Mô hình l p nguyên mẫu (iterative model) [2, 7].....................................11
Hình 1-4 Xác nh n th c hiện “h i gi i đoạn” [2, 10] ..............................................13
Hình 1-5 Mô hình Saga [2, 10] ................................................................................14
Hình 1-6 M h nh đ t chỗ [2, 11] ............................................................................15
Hình 2-1 Sơ đồ ch

n ng “Cre te meeting from Abs lon” trong kiến trúc nguyên

khối [2, 14] ................................................................................................................19
Hình 2-2 Kiến trú mi roservi e ho trường hợp “Cre te meeting from Ab s lon”
[2, 25] ........................................................................................................................21

Hình 2-3 Kiến trúc microservice với máy ch KSS [2, 33] .....................................23
Hình 2-4 Kiến trúc các thành phần thư viện microservice dùng chung ...................24
Hình 2-5 Kiến trú thư viện các thành phần ơ sở Microservice ............................25
Hình 2-6 Kiến trúc các thành phần Microservice và Máy ch KSS [2, 38] .............27
Hình 2-7 Luồng th ng điệp trong microservice [2, 39] ...........................................28
Hình 2-8 Lớp đối tượng đ t chỗ (Reservation model) .............................................32
Hình 2-9 Biểu đồ tuần t cho ch
Hình 2-10 Biểu đồ cho ch

n ng “Cre te meeting from Abs lon” ..............34

n ng tạo cuộc g p ......................................................35


1

MỞ ĐẦU
Tính cấp thiết của đề tài
Ng y n y, Mi roservi es hiện đượ qu n tâm trong giới phần mềm,

ng

nghệ với nhiều b i viết, blog, thảo lu n, truyền th ng, hội thảo. Kỳ vọng về khả
n ng

Mi roservi e đ ng l n đỉnh giống như một xu hướng thời tr ng đ ng l n

rộng. Ngượ lại, một số người ho rằng, mi roservi es kh ng ó g mới lạ, hẳng
qu nó l SOA kiến trú hướng dị h vụ đượ đ nh bóng, đổi t n m th i. M

ho

những đ nh gi m ng tính ảo tường h y bảo th , kiến trú mi roservi es hiện tại
vẫn đem lại lợi í h khi thiết th

hỗ trợ phương ph p gile th

ấp một giải ph p ph t triển phần mềm ph

s hiệu quả v

ung

tạp ho do nh nghiệp.

Kiến trú hướng vi dị h vụ Mi roservi e Ar hite tu r l Style - MAS) là
một

h xây d ng hệ thống phần mềm. Một hệ thống vi dị h vụ b o gồm nhiều

dị h vụ nhỏ m gi o tiếp với nh u qu mạng. Mỗi dị h vụ ó một vòng đời ph t
triển phần mềm ri ng biệt.

ể l m việ một

h hính x ,

dị h vụ n y phải

phụ thuộ v o nh u.

ể đ nh gi lợi thế

hệ thống vi dị h vụ lu n v n đã nghi n

d ng một nguy n mẫu – một sản phẩm phần mềm d
Mẫu đượ xây d ng d

tr n một h

“Customer S les System” KSS
lu n v n sẽ nghi n

u

u v xây

tr n hệ thống vi dị h vụ.

n ng đã tồn tại

hệ thống b n h ng

ng ty Alm Br n h. Th ng qu nguy n mẫu,

h để ải thiện v đạt đượ độ sẵn s ng

o với hi phí

bảo tr thấp.
Tổng quan về vấn đề nghiên cứu

Lu n v n thạ sĩ n y sẽ nghi n

u

hiến lượ về độ sẵn s ng v bảo tr

trong một hệ thống mi roservi e. Một nguy n mẫu mi roservi e nhỏ đượ xây d ng
d

tr n một h

n ng th

tế “ re te meeting from bs lon”nằm trong hệ thống

nguy n khối về quản lý b n h ng KSS
tảng ho việ nghi n
ó tính rời rạ

o.

u

h th

Alm Br nd. Nguy n mẫu n y sẽ l nền
đảm bảo độ sẵn s ng trong những hệ thống


2

Một hệ thống mi roservi e ó thể thường xuy n mở rộng với
mới v theo thời gi n sẽ h

một số lượng lớn

dị h vụ

mi roservi e độ l p nhỏ hơn,

điều n y ó thể ảnh hưởng kh ng tốt tới vấn đề bảo tr . Lượng thời gi n v khối
lượng

ng việ một hệ thống đòi hỏi trong việ bảo tr s u khi đã đi v o kh i th

ó ảnh hưởng lớn trong trường hợp kinh do nh v giảm gi trị lợi nhu n d kiến
b n đầu. Chi phí bảo tr d

n trong suốt vòng đời

40-80%, thường l m ho hi phí bảo tr vượt qu
điều qu n trọng l lu n xem xét m
th

nó thường đượ ướ tính từ

hi phí ph t triển b n đầu. Do v y,

độ về thời gi n

hệ thống sẽ ti u tốn để

hiện bảo tr v mở rộng.
Mi roservi e

một hệ thống thường h

một số lượng nhất định

h

n ng tương t nh u. Do v y, lu n v n d định sẽ xem xét việ đóng gói

h

n ng n y nhằm hi sẻ giữ

dị h vụ với nh u giúp ho việ bảo tr một hệ thống

mi roservi e đơn giản hơn v ít tốn kém hơn. Cụ thể:
Nghi n

-

u hiến lượ đảm bảo độ sẵn s ng ho hệ thống KSS sử

dụng kiến trú mi roservi e. Cụ thể lu n v n sẽ thử nghiệm với việ

i đ t th

thi

circuit breaker và bulkhead, sau đó so s nh kết quả n y với kiến trú KSS hiện tại
Nghi n

-

u hiến lượ th y đổi ho trường hợp hệ thống KSS, t p

trung v o việ giảm thiểu hi phí bảo tr th ng qu việ thiết kế v

i đ t một

fr mework mi roservi e hung n o đó.
Mục đích, đối tƣợng, phạm vi và phƣơng pháp nghiên cứu
Phương ph p hính đượ th

hiện trong lu n v n thạ sĩ n y l sử dụng m

h nh l p đi l p lại việ tạo nguy n mẫu. Qu tr nh n y sẽ giúp t i ó kinh nghiệm
nh nh hơn khi tiếp
ũng đượ x

n kiểu kiến trú mi roservi e,

ng với đó

vấn đề nổi b t

định sớm để xem xét.

Cấu trúc luận văn
Nội dung

lu n v n đượ tr nh b y trong b phần hính như s u:

1. Phần mở đầu
- Tính cấp thiết c

đề tài

- Tổng quan các vấn đề nghiên c u


3

- Mụ đí h, đối tượng, phạm vi, phương ph p nghiên c u
2. Phần nội dung: b o gồm b

hương

CHƢƠNG 1: TỔNG QUAN VỀ KIẾN TRÚC VI DỊCH VỤ
1.1.Tổng quan về Kiến trúc vi dịch vụ .
- Kh i niệm về Kiến trú vi dị h vụ
- Ưu, nhượ điểm
Kiến trú vi dị h vụ
1.2. So sánh Kiến trúc vi dịch vụ với Kiến trúc liên quan.
- Giới thiệu về Kiến trú một khối, Kiến trú hướng dị h vụ
- Ưu, nhượ điểm
Kiến trú một khối

1.3. Kết luận Chương 1
CHƢƠNG 2: GIẢI PHÁP MÔ HÌNH HÓA HỆ PHÂN TÁN VỚI KIẾN
TRÚC VI DỊCH VỤ.
2.1. Mô hình hóa các dịch vụ
- C h xây d ng m h nh kiến trú vi dị h vụ
- Triển kh i, nguy n lý hoạt động
m h nh
2.2. Giải pháp tích hợp trong hệ phân tán với kiến trúc vi dịch vụ
điểm
hệ thống phân t n
- Khả n ng gi o tiếp giữ
dị h vụ nhỏ th ng qu API
- Khả n ng mở rộng v tí h hợp
2.3. Kết luận Chương 2
CHƢƠNG 3: THỬ NGHIỆM VÀ ĐÁNH GIÁ.
3.1. Mô hình thử nghiệm
- Xây d ng m h nh thử nghiệm
3.2. Cài đặt thử nghiệm
- C bướ
i đ t triển kh i phương ph p m h nh
3.3 Đánh giá mô hình thử nghiệm
- Ưu điểm, nhượ điểm
m h nh thử nghiệm
- ư r giải ph p
3.4. Kết luận Chương 3
3. Phần kết luận
Những đóng góp

lu n v n.

Những m t hạn hế
Hướng ph t triển tiếp theo

lu n v n.


4

CHƢƠNG 1. TỔNG QUAN VỀ HỆ THỐNG VI DỊCH VỤ
1.1 Giới thiệu về hệ thống vi d ch vụ
1.1.1 Đặc đi m c a kiến trúc hệ th ng vi dịch vụ
Hệ thống vi dị h vụ Mi roservi e System – MS đã nổi l n trong v i n m
qu để m tả một
thống

hđ

biệt

thiết kế

ng dụng phần mềm như l một hệ

dị h vụ đượ triển kh i độ l p v gi o tiếp với nh u qu mạng. Tr n th

tế, vẫn hư

ó định nghĩ

hính x

về MS. [1] đã n u l n một số đ

điểm hung

về gi o dị h qu mạng, triển kh i t động, thiết bị đầu uối th ng minh, v kiểm
so t phân ấp
nghĩ

đ

ng n ngữ v dữ liệu. Ở hương n y, nghi n
điểm

hệ thống vi dị h vụ một

u v đư r định

h h t hẽ hơn

a, Được cấu thành từ các dịch vụ
J mes Lewwis, t
đượ th m gi v o ng nh

giả [1]

ng nhóm nghi n

thế n o? T

h kết hợp

đồ v t trong thế giới v t lý. V y “th nh phần” đượ hiểu như

ó thể th y thế v nâng ấp một

Kiến trú vi dị h vụ sử dụng
đượ

th nh phần lại với nh u, giống như

giả đã đư r định nghĩ như s u: “một th nh phần l một đơn vị

phần mềm m
tạo r

ng đã n u r : Từ khi

ng nghiệp phần mềm, họ đã ó một mong muốn xây

d ng hệ thống phần mềm bằng
h m t tạo n n

u

h độ l p”.

thư viện, nhưng

“th nh phần” l t h nhỏ phần mềm th nh

h th

ơ bản

nó để

khối dị h vụ. Mỗi thư viện

oi l một th nh phần đượ li n kết với hương tr nh hính v đượ gọi trong
bộ nhớ h

n ng. Trong khi

th nh phần ngo i sẽ gi o tiếp th ng qu

hế như y u ầu một dị h vụ web, ho
Lý do hính để sử dụng
thư viện l

ơ

gọi th tụ từ x .

dị h vụ như

dị h vụ đượ triển kh i một

th nh phần

h kh ng phải l

h độ l p. Giả sử,

ó một ng

dụng [4], ng dụng n y gồm nhiều thư viện trong một tiến tr nh đơn, một s th y
đổi nhỏ ở bất kỳ th nh phần ri ng lẻ n o ũng bắt buộ phải triển kh i lại to n bộ
ng dụng. Nhưng nếu ng dụng đó bị phân t h r th nh nhiều khối dị h vụ, th khi
th y đổi th nh phần n o đó th

hỉ ó dị h vụ đó ần phải triển kh i lại.

iều n y


5

kh ng phải tuyệt đối, ó một số th y đổi sẽ l m th y đổi gi o diện
đến việ th y đổi

một số

dị h vụ dẫn

dị h vụ li n qu n, nhưng mụ đí h

một kiến

trú vi dị h vụ tốt l một kiến trú đảm bảo giảm thiểu những yếu điểm tr n.

Một đ
hệ thống l

dị h vụ như

th nh phần

định gi o diện một

một

ng n ngữ kh ng

h rõ r ng. Thường th hỉ ó

h đư r t i

nguy n tắ rõ r ng mới ó thể ng n h n m y kh h kh ng vi phạm quy

tắ đóng gói
C

việ sử dụng

th nh phần ó gi o diện rõ r ng hơn. Hầu hết

ó ơ hế để x
liệu v

điểm kh

th nh phần, dẫn đến khớp nối qu

dị h vụ tr nh điều n y bằng

h sử dụng

h t hẽ giữ

th nh phần.

ơ hế uộ gọi từ x một

h rõ

ràng.
Sử dụng dị h vụ như thế n y kh ng ó nhượ điểm.
b, Được tổ chức dựa trên các giao dịch
Khi t m

h để hi nhỏ một ng dụng lớn th nh nhiều phần, thường phải

quản lý t p trung v o

tầng

ng nghệ, dẫn đến việ h nh th nh

đội phí m y h logi , v

đội UI,

đội ơ sở dữ liệu. Khi đội đượ t h r theo

h

n y, th th m hí th y đổi đơn giản ũng ó thể dẫn đến việ tốn thời gi n
đội kh

v tốn ngân s h. Nhóm th ng minh sẽ tối ưu hó việ n y vừ đảm bảo

thời gi n vừ đảm bảo hi phí, đó l
v y họ ó thể truy

p bất

hỉ ần đội t p trung v o m y h logi , như

ng dụng n o. ây hính l lu t [5] Conw y [5] đượ

m tả ụ thể như h nh dưới đây:

Hình 1-1 Phƣơng thức hoạt động của luật Conway [8]


6

Nói tóm lại, hệ thống vi dị h vụ l hệ thống đượ tổ h
dị h giữ

th nh phần độ l p

d

tr n

gi o

hệ thống.

c, i dịch vụ là một sản phẩm không phải là một dự án
Hầu hết

ng dụng đượ ph t triển th đều sử dụng một m h nh n o đó:

mụ đí h l để ung ấp một số phần đã ho n thiện

phần mềm,

phần n y kết

hợp với nh u th nh một phần ho n hỉnh. S u khi sản phẩm phần mềm đượ ho n
th nh th nó đượ b n gi o ho kh h h ng rồi đến

nhóm bảo tr v kết thú d

án.
Hệ thống vi dị h vụ ó xu hướng ph t triển tr nh m h nh n y, th y v o đó
th đội d

n ần sở hữu sản phẩm n y xuy n suốt vòng đời

lại ho

nh ph t triển li n hệ theo ng y với người d ng uối để biết đượ phần

mềm

nó.

iều n y m ng

họ hoạt động như thế n o, điều n y ũng đồng thời l m t ng mối li n kết

ũng như gi o tiếp giữ nh ph t triển v người d ng uối.
Chính v thế,
hơn l một d

hệ thống vi dị h vụ đượ

oi l một sản phẩm phần mềm

n phầm mềm.

d, Dữ liệu được quản lý không tập trung (Decentralized)
Tất ả
phần kh

dị h vụ ó dữ liệu lưu trữ
hệ thống.

ri ng nó, t h biệt ho n to n với

iều n y thường dẫn tới kết quả l

lượ đồ ơ sở dữ

liệu thường đơn giản v nhỏ, ri ng biệt, điều n y rất tốt bởi nó sẽ đảm bảo dễ d ng
ó

i nh n tổng qu n về một lượ đồ. Dữ liệu sẽ theo một

t h ri ng, v như v y ó thể y u ầu
khác nhau.

h kh

ng một dữ liệu đượ lưu trữ ở

ũng đượ
vị trí


7

Hình 1-2 Microservice application database [8]
e, Đa ngôn ngữ
Một mi roservi e ó thể đượ hiện th
với bất kỳ

bằng bất kỳ ng n ngữ l p tr nh n o

ng nghệ lưu trữ dữ liệu n o m nhóm ư thí h. Nghĩ l mi roservi e

kh ng bị giới hạn về

ng nghệ so với phần òn lại

hệ thống.

f, Triển khai liên tục
C

mi roservi e ó thể đượ xây d ng, triển kh i v thử nghiệm độ l p với

nhau.
g, Khép kín
Mỗi dị h vụ ó h
triển kh i ri ng biệt.

logi nghiệp vụ kinh do nh

ri ng m nh v đượ

iều n y giúp ho nó ó thể th y đổi v dần dần mở rộng với

tính n ng mới m kh ng l m ảnh hưởng tới phần òn lại
khép kín (self- ont ined

ũng hỗ trợ việ l

họn

hệ thống.

tính

ng nghệ ph hợp nhất ho

một dị h vụ ụ thể linh hoạt hơn rất nhiều. C ng nghệ sẽ kh ng bị giới hạn trong
một t p

ng nghệ đượ x

h, Liên lạc ngoài dịch vụ

định trướ ho

một fr mework ụ thể n o đó.


8

Một dị h vụ đượ
th ng qu

hạy dưới tiến tr nh h

nó v

hệ thống nhắn tin như R bbitMQ v

hỉ ó thể gi o tiếp/li n lạ

thường sử dụng gi o th

request/reply.
i, Nguyên tắc chuyên biệt
Một mi roservi e n n th
gồm

hiện một h

n ng kinh do nh duy nhất, b o

th nh phần ó gắn kết h t hẽ với nh u. iều n y nghĩ l một dị h vụ sẽ

phải hịu tr h nhiệm ho một lĩnh v

n o đó v lĩnh v

n y l duy nhất.

u đi m c a kiến trúc hệ th ng vi dịch vụ

1.1.2
-

Giảm thiểu s gi t ng ph c tạp hệ thống lớn

-

Chia nhỏ ng dụng một khối cồng kềnh thành các dịch vụ nhỏ dễ quản lý,
bảo trì nâng cấp, t do chọn, nâng cấp công nghệ mới

-

Mỗi dịch vụ nhỏ sẽ định ra ranh giới rõ r ng dưới dạng RPC hay API
hướng th ng điệp

-

Mi roservi e thú đẩy phân tách rạch ròi các khối ch

n ng loose

coupling - high ohesion , điều rất khó th c hiện với ng dụng một khối.
Nếu muốn loose coupling - high cohesion trong ng dụng một khối, sẽ
phải thiết kế theo Design Pattern (Gang Of Four) và liên tục tái cấu trúc
(refactor)
-

Mỗi dịch vụ nhỏ sẽ phát triển dễ hơn, nh nh hơn, dễ viết mã kiểm thử t
động.

-

Một số dịch vụ có thuê ngoài phát triển mà vẫn bảo m t hệ thống - mã
nguồn phần dịch vụ còn lại.

ội phát triển có nhiều l a chọn công nghệ

mới, framework, CSDL mới, đ dạng để nâng cấp từng dịch vụ nhỏ, chọn
m i trường tối ưu nhất để chạy. Các dịch vụ có thể b t tắt để kiểm
nghiệm so sánh A|B, t ng tốc quá trình cải tiến giao diện. Triển kh i đều
đ n khả thi với microservice. Dịch vụ nhỏ đóng gói trong Do ker
container có thể chuyển từ m i trường phát triển s ng m i trường chạy
th t không phải cấu hình th công lại, không phải copy file quá lớn.


9

1.1.3

hược đi m c a kiến trúc hệ th ng vi dịch vụ
Nhượ điểm đầu ti n

mi roservi es ũng hính từ t n gọi

Mi roservi e nhấn mạnh kí h thướ nhỏ gọn

nó.

dị h vụ. Một số l p tr nh đề xuất

dị h vụ si u nhỏ ỡ dưới 100 dòng ode. Chi qu nhiều sẽ dẫn đến m nh mún, vụn
v t, khó kiểm so t. Việ lưu dữ liệu ụ bộ b n trong những dị h vụ qu nhỏ sẽ
khiến dữ liệu phân t n qu m
Nhượ điểm tiếp

ần thiết.
mi roservi e đến từ đ

điểm hệ thống phân t n

(distributed system):
-

Phải xử lý s cố khi kết nối ch m, lỗi khi th ng điệp không gửi được ho c
th ng điệp gửi đến nhiều đí h đến vào các thời điểm khác nhau.

-

ảm bảo giao dịch phân tán (distributed transaction) c p nh t dữ liệu đúng
đắn (all or none) vào nhiều dịch vụ nhỏ kh

nh u khó hơn rất nhiều, đ i khi

là không thể so với đảm bảo giao dịch c p nh t vào nhiều bảng trong một ơ
sở dữ liệu trung tâm
-

Theo nguyên tắc CAP (CAP theorem) thì giao dịch phân tán sẽ không thể
thỏa mãn cả 3 điều kiện: consistency (dữ liệu ở điểm khác nhau trong mạng
phải giống nhau), availablity (yêu cầu gửi đi phải ó phú đ p , p rtition
tolerance (hệ thống vẫn hoạt động được ngay cả khi mạng bị lỗi). Những
công nghệ ơ sở dữ liệu phi quan hệ (NoSQL) hay môi giới th ng điệp
(message broker) tốt nhất hiện n y ũng hư vượt qua nguyên tắc CAP.

-

Triển khai dịch vụ microservices nếu làm th

ng theo

h đã l m với ng

dụng một khối ph c tạp hơn rất nhiều. Ứng dụng một khối bổ sung các
server mới giống hệt nh u đằng sau bộ cần bằng tại. Trong khi ở kiến trúc
microservice, các dịch vụ nhỏ nằm trên nhiều máy ảo hay Docker container
khác nhau, ho c một dịch vụ có nhiều th c thể phân tán ra nhiều. Theo
Adrian Crockcroft, Hailo có 160 dịch vụ, NetFlix ó hơn 600 dịch vụ. Trong
dịch vụ đ m mây,

m y ảo, docker container, th c thể có thể linh động

b t tắt, dịch chuyển. V y cần thiết phải có một ơ hế phát hiện dịch vụ


10

servi e dis overy me h nism để c p nh t t động địa chỉ IP và cổng, mô
tả, phiên bản c a mỗi dịch vụ.
1.2 So sánh kiến trúc vi d ch vụ với kiến trúc liên quan
1.2.1 Kiến trúc hệ th ng ngu n kh i (Monilithic S stem)
Hệ thống Monilithi h y một hệ thống nguy n khối l một hương tr nh th
thi logi đơn. Bất kỳ một th y đổi đượ th

hiện với một phần

một hệ thống

nguy n khối đều li n qu n tới xây d ng v triển kh i một phi n bản mới
bộ hệ thống. M

d Alm Br nd hiện đ ng hướng tới

to n

th nh phần t i sử dụng,

tuy nhi n họ đã nhiều lần thỏ hiệp với một giải ph p hung ho một sản phẩm ụ
thể. iều n y đã dẫn tới một số hệ thống theo kiến trú nguy n khối, với một số đ
điểm hung đượ liệt k dưới đây.
a, Một cơ sở mã nguồn
To n bộ hệ thống thường nằm trong một ơ sở mã nguồn lớn. Khi ng dụng
mở rộng đồng nghĩ với việ mở rộng kí h thướ mã nguồn. Nhóm ph t triển ó thể
duy tr tương đối tốt.
b, Ngôn ngữ cụ thể
Do đ

điểm hệ thống hỉ ó một ơ sở mã nguồn n n to n bộ hệ thống

thường đượ xây d ng tr n một ng n ngữ l p tr nh duy nhất.
c, Mở rộng ngang
iều n y kh ng đồng nghĩ với việ

ó thể mở rộng bất kỳ một th nh phần

n o trong ng dụng nguy n khối. To n bộ ng dụng nguy n khối sẽ đượ mở rộng

ho

kh ng g

ả. Mở rộng đượ ho n th nh sử dụng ân bằng tải với một v i thể

hiện inst n es

ng dụng nguy n khối.

d, Kiến trúc 3 lớp
Lớp 1: Gi o diện người d ng

lient-side gồm

tr ng HTML, J v s ript

hạy tr n tr nh duyệt tr n m y tính người d ng;
Lớp 2: Cơ sở dữ liệu thường l
Lớp 3: M y h

hệ quản trị ơ sở dữ liệu qu n hệ;

ng dụng server-side)


11

e, Tiến trình đơn
Một hệ thống nguy n khối như m y h

đượ

ng dụng đượ n u ở tr n thường

hạy trong một tiến tr nh đơn.
f, Các thành phần đan xen
C

th nh phần trong một hệ thống nguy n khối kh ng ó một h sở hữu rõ

r ng, thường dẫn tới r ng buộ giữ

th nh phần.

g, òng đời triển khai dài
Việ bảo tr v mở rộng
thời gi n. Ng y ả

h

n ng ng dụng nguy n khối ti u tốn nhiều

th y đổi nhỏ nhất ũng ó thể dẫn tới nhu ầu phải xây d ng,

triển kh i v thử nghiệm to n bộ ng dụng.
1.3 Mô hình nguyên mẫu
Lu n v n d định sẽ xem xét việ đóng gói
dị h vụ nhằm hi sẻ giữ

h

n ng

một hệ thống vi

dị h vụ với nh u giúp ho việ bảo tr một hệ thống

mi roservi e đượ đơn giản hơn v ít tốn kém hơn. Cụ thể:
- Nghi n

u hiến lượ đảm bảo độ sẵn s ng ho hệ thống vi dị h vụ sử

dụng kiến trú vi dị h vụ.
- Nghi n
việ thiết kế v

u hiến lượ th y đổi giúp giảm thiểu hi phí bảo tr th ng qu
i đ t một nền tảng vi dị h vụ hung n o đó.

Một m h nh nguy n mẫu đượ xây d ng như dưới đây:

Hình 1-3 Mô hình lặp nguyên mẫu (iterative model) [2, 7]


12

Theo h nh 1.3 việ xây d ng một nguy n mẫu l một qu tr nh tuần t th ng
qu việ phân tí h, thiết kế v khởi tạo nguy n mẫu. S u khi đượ triển kh i th qu
tr nh n y l p đi l p lại với

bướ tuần t như v y.

1.4 Các đặc trƣng của giao d ch trong hệ thống phân tán
Sử dụng gi o dị h tr ns tions trong

hệ thống n-lớp truyền thống như

l hệ thống nguy n khối l tương đối đơn giản. Khi hi một hệ thống như v y
th nh

dị h vụ độ l p như l

vi dị h ụ thể, sẽ ó nhiều vấn đề ần xem xét

đến.
iều g sẽ xảy r nếu một v i
trong khi
ph hợp tr n

gi o dị h kh

th nh

gi o dị h b n trong

ng?

iều n y ó thể dẫn tới

dị h vụ ó li n qu n. Một vấn đề kh

một số r ng buộ để ng dụng ó thể tiếp tụ
kết quả, dữ liệu đượ

m kết bởi

dị h vụ thất bại

ng việ

dữ liệu kh ng

ần xem xét đó l
m nh lại d

ó thể
tr n

dị h vụ thất bại.

Trong qu tr nh thiết kế hệ thống, lu n đã xem xét một v i

h tiếp

n kh

nh u để giải quyết vấn đề n u tr n.
1.4.1 Mô hình “hai giai đoạn”
Một giải ph p đượ sử dụng rộng rãi l sử dụng x
đoạn”, th nh phần điều phối đầu ti n sẽ kiểm tr nếu tất ả

sẵn s ng x

nh n th

hiện

nh n th

hiện “h i gi i

dị h vụ th m gi đã

ommit . Tr n ơ sở kết quả bỏ phiếu

để đảm bảo tính thống nhất để h y bỏ ho

dị h vụ

x

nh n th

hiện với tất ả

dị h

x

nh n th

hiện “h i gi i đoạn” l

vụ.
Nhượ điểm lớn nhất đó l gi o th
một gi o th

ng n h n blo king . Nếu th nh phần điều phối lu n thất bại, một số

dị h vụ sẽ kh ng b o giờ giải quyết đượ

dị h vụ

húng: S u khi một dị h

vụ gửi th ng điệp bỏ phiếu tới th nh phần điều phối, nó sẽ h n ho tới khi nh n
đượ một y u ầu tiếp theo về việ xác nhận thực hiện hay khôi phụctrạng thái cũ
(rollback).


13

Hình 1-4 Xác nhận thực hiện “hai giai đoạn” [2, 10]

1.4.2 Mô hình Saga
Một giải ph p kh

để đạt đượ s nhất qu n giữ

dị h vụ l sử dụng m

hình Saga.
Trong m h nh n y h

một dị h vụ điều phối, l th nh phần hính ó trách

nhiệm kiểm so t s th m gi
nguy n tắ , tất ả

mi roservi e. M h nh n y đượ

dị h vụ th m gi v o qu tr nh xử lý một h nh động đều ó

hoạt động đền b . Khi một ho
điều phối sẽ y u ầu
iều n y

p dụng theo

nhiều dị h vụ th m gi thất bại khi xử lý, dị h vụ

dị h vụ òn lại th

ó nghĩ

l

kh ng

ó

hiện hoạt động bồi thường tương ng.
h

n ng kh i phụ

đầu rollb k nếu ó điều g s i xảy r , th y v tất ả
n ng đền b nhằm đảo ngượ bất

trạng th i b n

dị h vụ phải ung ấp h

h nh động n o vừ th

hiện.

ây ó thể oi

như một dạng giả kh i phụ trạng th i b n đầu.
Có vẻ như đây l một giải ph p tiềm n ng, tuy nhi n ó một số vấn đề đối
với xử lý bồi thường. C

th nh phần trong m h nh S g

dị h vụ th m gi v o hoạt động tr n
đền b l bất khả thi.

ó thể tương t

với

ng một dữ liệu vừ đượ sử đổi dẫn tới việ


14

Hình 1-5 Mô hình Saga [2, 10]

1.4.3 Mô hình đặt chỗ (Reservation)
M h nh đ t hỗ l giải ph p th b để đạt đượ s nhất qu n giữ
vụ. Kh ng giống với m h nh S g , m h nh đ t hỗ kh ng h

dị h

một th nh phần

điều phối trung tâm.
Khi một y u ầu th
vụ, nó đượ th

hiện một h nh động n o đó tr n một ho

hiện bằng

h gửi

nhiều dị h

s kiện th m dò. Những s kiện n y l

đ t hỗ ần xem xét v đượ trả lời với một ID đ t hỗ v một thời gi n hết hạn.
ối tượng y u ầu ho đến trướ thời gi n hết hạn ó thể x

nh n ho

h y bỏ

h nh động y u ầu trướ đó.
Một tiến tr nh đượ

hỉ định ư trú trong mỗi dị h vụ kiểm so t

Tiến tr nh n y kiểm so t tất ả

h y bỏ v x

nh n ũng như

hạn. Trong trường hợp một đ t hỗ hết hạn, tiến tr nh v

đ t hỗ.
đ t hỗ hết

t i nguy n đã đ t hỗ

đượ giải phóng.
Trong phần 2.2.1 t đề
M h nh đ t hỗ trướ

p tới giải ph p x

nh n th

ó thể đượ xem như l một gi o th

hiện “h i gi i đoạn”.
“h i bướ th nh

ng”


15

Hình 1-6 Mô hình đặt chỗ [2, 11]
C

th nh phần b n trong đ t hỗ ó

Reservation đ t hỗ : tạo r
th ng điệp “đ t hỗ”. Ngo i th

đ t hỗ reserv tion khi nh n đượ một

hiện một số h nh động th ng thường như

ơ sở dữ liệu nó òn đ t một bộ đếm ho
việ x

nhiệm vụ s u:
p nh t

một thời gi n hết hạn như l một phần

nh n xử lý y u ầu.

Validation x

nh n : đảm bảo rằng một đ t hỗ l vẫn hợp lệ trướ khi kết

thú tiến tr nh.
Expiration Hết hạn : đ nh dấu
đổi. Ví dụ: Nếu một y u ầu ó m
đ t hỗ, hệ thống ó thể b
đầu ũng trở n n mất hiệu l

đ t hỗ kh ng hợp lệ khi điều kiện th y

ưu ti n

o hơn muốn một số dữ liệu đã đượ

bỏ đ t hỗ b n đầu để đ p ng y u ầu.

t hỗ b n

v biến mất với hệ thống khi dữ liệu đ t hỗ bị lấy

lại. Hết hạn ũng ó thể xảy r khi hết giờ, như trong “

dữ liệu đượ đ t hỗ

trong 24 giờ”.
1.5 Kết luận Chƣơng 1
Chương 1 đã đư r đượ

kh i niệm hung nhất v

đ

điểm về hệ

thống vi dị h vụ ũng như hệ thống nguyên khối. Ngo i r , hương I òn n u lên
đượ mụ đí h xây d ng m h nh nguy n mẫu ũng như đư r một m h nh
nguy n mẫu đượ xây d ng một

h tuần t l p đi l p lại đượ sử dụng xuy n suốt


16

lu n v n. ồng thời, hương I

lu n v n đã đư r

l m nền tảng ho s phân tí h hệ thống

hương II.

loại gi o dị h phân t n để

17

CHƢƠNG 2. GIẢI PHÁP MÔ HÌNH HÓA HỆ PHÂN TÁN
VỚI KIẾN TRÚC VI DỊCH VỤ
2.1 Mô hình h a các d ch vụ
Trong hương n y, một nguy n mẫu hệ thống b n h ng KSS – Kostomer
S les System đượ sử dụng để minh họ qu tr nh m h nh hó

dị h vụ trong hệ

thống phân t n với kiến trú vi dị h vụ.
Th ng qu nguy n mẫu, lu n v n sẽ nghi n

u m

phương ph p triển kh i nhằm ph t huy tính linh hoạt
đượ độ sẵn s ng

h nh triển kh i v

kiến trú vi dị h vụ v đạt

o, hi phí bảo tr thấp. Trong qu tr nh ph t triển nguy n mẫu,

vấn đề ần xem xét về l m thế n o để đạt đượ kết quả mong muốn về độ sẵn s ng
v

hi phí bảo tr sẽ đượ tr nh b y hi tiết v

đượ
h

oi l một phần
n ng đ

trưng

b o gồm một số

giải ph p đượ l

họn

iđ t

nguy n mẫu. Lu n v n t p trung v o m h nh hó một số
hệ thống KSS ở đó mỗi h

n ng đượ thiết kế kiến trú

mi roservi e.

Xử lý gi o dị h li n dị h vụ l một vấn đề ần đượ giải quyết trong thiết kế
theo m h nh kiến trú vi dị h vụ. Do v y, ần xem xét v th
để xử lý

hiện một phương n

gi o dị h phân t n trong hệ thống mi roservi e. Tóm lại, nếu một dị h

vụ thất bại, điều qu n trọng l kh ng ó g đượ x

nh n th

hiện ở

dị h vụ

kh . Nếu kh ng, hệ thống sẽ kết thú với một trạng th i kh ng nhất qu n.
Ngo i r , một vấn đề ần đượ giải quyết l l
để xử lý

gi o dị h phân t n một

họn m h nh tiềm n ng n o

h tối ưu? V l m thế n o để mở rộng khung

microservice chung (microservice framework)?
2.2 Giải pháp tích hợp trong hệ phân tán với kiến trúc vi d ch vụ
2.2.1

hân tích kiến trúc hệ th ng bán hàng (KSS)
Thành phần m y h KSS l một phần trong một hệ thống ng dụng lớn hơn

l hệ thống b n h ng KSS hiện đ ng đượ kh i th . Hệ thống b n h ng KSS l
ng ụ hính đượ sử dụng bởi
điện thoại

Alm Br nd.

gi o dị h vi n tại

trung tâm tiếp thị qu