..

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
---------------------------------------

BÙI MINH CHIẾN

THIẾT KẾ VÀ XÂY DỰNG MICROSERVICE VỚI KHẢ NĂNG
ĐÁP ỨNG SỰ THAY ĐỔI VỀ QUY MÔ

Chuyên ngành : CÔNG NGHỆ THÔNG TIN

LUẬN VĂN THẠC SĨ KỸ THUẬT
CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN:
PGS.TS. CAO TUẤN DŨNG

Hà Nội – Năm 2019


LỜI CAM ĐOAN
Tôi – Bùi Minh Chiến – xin cam đoan
• Luận văn tốt nghiệp (LVTN) Thạc sĩ này là cơng trình nghiên cứu của bản thân
tơi dưới sự hướng dẫn của PGS.TS Cao Tuấn Dũng.
• Các kết quả nêu trong Luận văn tốt nghiệp là trung thực, không phải là sao chép
tồn văn của bất kỳ cơng trình nào khác.

Hà Nội, ngày … tháng … năm 2019
Tác giả LVThS

Bùi Minh Chiến

1


LỜI CẢM ƠN
Đầu tiên, tôi xin được gửi lời cảm ơn sâu sắc nhất tới Thầy giáo – PGS.TS Cao
Tuấn Dũng – Phó viện trưởng, Viện Cơng nghệ thơng tin và Truyền thông, Trường Đại
học Bách Khoa Hà Nội đã hướng dẫn và cho tôi những lời khuyên trong quá trình thực
hiện luận văn này.
Tiếp theo, tơi xin chân thành cảm ơn các thầy cô trong Viện Công nghệ thông tin
và truyền thông, Viện đào tạo sau đại học, Trường Đại học Bách Khoa Hà Nội đã tạo
điều kiện cho tơi trong suốt q trình học tập và nghiên cứu tại trường.
Cuối cùng, tơi xin bày tỏ lịng cảm ơn tới những người thân trong gia đình, bạn bè
đã động viên và giúp đỡ để tơi hồn thành bản luận văn này.
Hà Nội, ngày … tháng … năm 2019
Tác giả LVThS

Bùi Minh Chiến

2


MỤC LỤC

LỜI CAM ĐOAN ..........................................................................................................1
LỜI CẢM ƠN ................................................................................................................2
MỤC LỤC ......................................................................................................................3
DANH MỤC BẢNG BIỂU ...........................................................................................5

DANH MỤC HÌNH ẢNH .............................................................................................6
MỞ ĐẦU .........................................................................................................................7
1. Đặt vấn đề.............................................................................................................7
2. Phương pháp đề xuất ..........................................................................................7
3. Bố cục luận văn ....................................................................................................8
CHƯƠNG 1: GIỚI THIỆU CHUNG VỀ KIẾN TRÚC HỆ THỐNG .....................9
1.1.

Kiến trúc một khối (Monolithic) .....................................................................9

1.1.1.

Khái niệm ......................................................................................................9

1.1.2.

Ưu nhược điểm của kiến trúc Monolithic ................................................10

1.2.

Kiến trúc hướng dịch vụ (SOA) ....................................................................11

1.3.

Kiến trúc dịch vụ siêu nhỏ (Microservice) ...................................................12

1.3.1.

Khái niệm ....................................................................................................13


1.3.2.

Các thành phần cơ bản của Microservice ................................................14

1.3.3.

Các kiến trúc Microservice ........................................................................16

1.3.4.

Ưu nhược điểm của kiến trúc Microservice .............................................18

1.3.5.

Các nguyên tắc khi phát triển Microservice ............................................20

CHƯƠNG 2: CÁC ĐẶC TÍNH MICROSERVICE .................................................23
2.1.

Các đặc tính của Microservice ......................................................................23

2.2.

Tính ổn định (Stability) .................................................................................23

2.3.

Tính sẵn sàng (Availability) ..........................................................................23

2.4.


Tính co giãn (Scalablity) ................................................................................24

2.5.

Tính mở rộng (Elasticity) ..............................................................................27

2.6.

Tính độc lập (Independent) ...........................................................................27

2.7.

Tính đa chiều (Polyglot) ................................................................................28

CHƯƠNG 3: THIẾT KẾ HỆ THỐNG .....................................................................30
3.1.

Mô tả bài tốn .................................................................................................30

3.2.

Mơ hình hệ thống ...........................................................................................31

3.2.1.

Bộ tổng hợp (Aggregator) ..........................................................................32
3



3.2.2.

Bộ cân bằng tải (Load balancing) .............................................................33

3.2.2.1.

Virtual Message Router (VMR) .............................................................34

3.2.2.2.

Các tính năng chính của VMR ...............................................................34

3.2.3.

Bộ xử lý yêu cầu (Microservice) ................................................................35

CHƯƠNG 4: THỬ NGHIỆM VÀ ĐÁNH GIÁ ........................................................37
4.1.

Công nghệ và mơi trường sử dụng ...............................................................37

4.1.1.

Ngơn ngữ lập trình .....................................................................................37

4.1.2.

Mơi trường sử dụng ....................................................................................37

4.2.


Các tiêu chí đánh giá......................................................................................37

4.3.

Cài đặt và kết quả thử nghiệm......................................................................38

4.3.1.

Triển khai cài đặt hệ thống ........................................................................38

4.3.2.

Thử nghiệm .................................................................................................42

KÊT LUẬN ..................................................................................................................52
TÀI LIỆU THAM KHẢO...........................................................................................53

4


DANH MỤC BẢNG BIỂU
Bảng 1: Kết quả khi thực hiện với 1 Microservice ............................................................. 43
Bảng 2: Kết quả khi thực hiện với 2 Microservice ............................................................. 43
Bảng 3: Kết quả khi thực hiện với 3 Microservice ............................................................. 44
Bảng 4: Kết quả khi thực hiện với 4 Microservice ............................................................. 44
Bảng 5: Kết quả khi thực hiện với 5 Microservice ............................................................. 45
Bảng 6: So sánh giữa thử nghiệm 1 (1 microservice) và thử nghiệm 2 (2 microservice) .. 48
Bảng 7: So sánh giữa thử nghiệm 1 (2 microservice) và thử nghiệm 2 (3 microservice) .. 49


5


DANH MỤC HÌNH ẢNH
Hình 1: Kiến trúc ngun khối monolithic ....................................................................10
Hình 2: So sánh giữa kiến trúc một khối và kiến trúc microservice .............................14
Hình 3: Kiến trúc cơ bản của microservice ...................................................................15
Hình 4: Mơ hình tổng hợp (Aggregator Pattern) ...........................................................17
Hình 5: Mơ hình Proxy (Proxy Pattern) ........................................................................17
Hình 6: Mơ hình đường ống (Pipeline Pattern) .............................................................18
Hình 7: Tính sẵn sàng của Microservice .......................................................................24
Hình 8: Khối co giãn (Scale Cube)................................................................................25
Hình 9: Co giãn theo trục X ..........................................................................................25
Hình 10: Co giãn theo trục Z .........................................................................................26
Hình 11: Co giãn theo trục Y ........................................................................................26
Hình 12: Ví dụ về tính Polyglot của Microservice ........................................................29
Hình 13: Giao diện phần dữ liệu đầu vào ......................................................................31
Hình 14: Mơ hình hoạt động của hệ thống ....................................................................32
Hình 15: Hình ảnh hệ thống đang gửi tin nhắn .............................................................33
Hình 16: Các thành phần của VMR ..............................................................................34
Hình 17: Mơ hình tương tác giữa các Solace với nhau .................................................35
Hình 18: Giao diện chương trình ...................................................................................38
Hình 19: Cấu hình bộ Aggregator .................................................................................39
Hình 20: Cấu hình bộ xử lý ...........................................................................................39
Hình 21: Khởi động bộ Aggregator ...............................................................................40
Hình 22: Khởi động bộ Aggregator thành cơng ............................................................40
Hình 23: Trạng thái kết nối thành công tới server Solace trên giao diện ......................41
Hình 24: Khởi động bộ xử lý.........................................................................................41
Hình 25: Khởi động bộ xử lý thành cơng ......................................................................42
Hình 26: Kết quả so sánh số lượng yêu cầu được đáp ứng ...........................................46

Hình 27: Kết quả so sánh độ lệch chuẩn về đỗ trễ đáp ứng các yêu cầu.......................46
Hình 28: So sánh tương quan giữa khả năng đáp ứng yêu cầu và độ lệch chuẩn của độ
trễ về thời gian đáp ứng .................................................................................................47
Hình 29: So sánh giữa thử nghiệm 1 (1 microservice) và thử nghiệm 2 (2 microservice)
.......................................................................................................................................48
Hình 30: So sánh tương quan giữa thử nghiệm 1 (1 và 2 microservice) với thử nghiệm
2 (2 và 3 microservice) ..................................................................................................50
Hình 31: So sánh kết quả cuối cùng giữa thử nghiệm 1 và thử nghiệm 2.....................50
6


MỞ ĐẦU
1. Đặt vấn đề
Nhu cầu sử dụng các dịch vụ mọi lúc ngày càng tăng cao trong thời đại số ngày
càng phát triển như vũ bão hiện nay. Chính vì nhu cầu ngày một tăng như thế nên rất
nhiều dịch vụ đã chuyển sang nền tảng trực tuyến để mau chóng bắt cặp với xu hướng
và mục tiêu chính là phục vụ được nhu cầu người dùng kịp thời mọi nơi mọi lúc.
Cùng với đó sự phát triển của điện toán đám mây đã thúc đẩy đã thay đổi mạnh
mẽ cách mà các nhà phát triển ứng dụng và cách triển khai ứng dụng. Chính vì sự phát
triển rất mạnh và nhanh đó khiến cho các loại ứng dụng và kiến trúc dịch vụ thay đổi
theo rất nhiều theo nhu cầu của người sử dụng thay vì thay đổi theo thời gian như trước.
Sự thay đổi đó là phù hợp để trải nghiệm của người sử dụng trong thời đại số này luôn
được đáp ứng tại mọi thời điểm để dịng thơng tin khơng bị ngắt qng hay bị ứ đọng
mà luôn được đáp ứng bởi các dịch vụ một cách kịp thời và nhanh chóng.
2. Phương pháp đề xuất
Nếu sử dụng các kiến trúc nguyên khối thì khi lượng người dùng tăng lên, để đáp
ứng được lượng truy cập tăng cao thì bên cung cấp dịch vụ sẽ phải nâng số máy chủ lên
để đáp ứng được lượng truy cập đó. Nhưng để triển khai thêm thêm máy như thế thì mất
khá nhiều thời gian vì phải triển khai gần như nguyên cả 1 hệ thống như thế trên máy ảo
vì một số hệ thống gồm rất nhiều chức năng bên trong nhưng không phải chức năng nào

mà người dùng sử dụng lúc đó khiến cho chức năng đó cũng được bổ sung để đáp ứng
mặc dù khơng cần thiết khiến cho việc lãng phí. Chính điều đó nên giải pháp cho việc
đáp ứng nhu cầu người dùng tăng cao đó là nâng số lượng dịch vụ mà người dùng đang
cần thiết đó lên để vẫn đáp ứng được yêu cầu nhưng mà vẫn tiết kiệm được chi phí,
khơng bị thừa hay lãng phí cho các dịch vụ mà khơng cần bổ sung. Đấy chính là lý do
nên chia các dịch vụ từ kiến trúc nguyên khối sang thành các dịch vụ nhỏ (microservice),
phù hợp cho việc nâng số service lúc nhu cầu tăng cao mà vẫn tiết kiệm được chi phí,
vẫn đáp ứng được yêu cầu người dùng.
Trong luận văn này sẽ sử dụng một bản thử nghiệm để mơ tả đáp ứng của service
khi có lượng request từ phía người dùng tăng lên. Khi tiếp nhận lượng request lớn từ
phía người dùng, sẽ mất bao nhiêu thời gian khi chỉ sử dụng một service để xử lý và khi
có nhiều service cùng tham gia thì thời gian đáp ứng là bao nhiêu. Tất cả số liệu được
đánh giá chỉ mang tính tương đối vì trong thực tế còn rất nhiều yếu tố ảnh hưởng đến
việc gửi nhận request từ phía người dùng và bài tốn để áp dụng chỉ mang tính chất tham
khảo để có thể đánh giá một phần liên quan tới tính mở rộng microservice.

7


Trong các chương sau sẽ mô tả về Microservice, các kiến trúc microservice hiện
nay đang được sử dụng triển khai cũng như mơ tả chi tiết bài tốn được áp dụng để thử
nghiệm về khả năng đáp ứng của các microservice.
3. Bố cục luận văn
Sau đây là bố cục luận văn:
Chương 1: Giới thiệu chung
Chương 2: Các đặc tính của microservice
Chương 3: Thiết kế hệ thống mơ tả bài tốn
Chương 4: Thử nghiệm và đánh giá
Kết luận: Đưa ra được những kết quả đạt được trong luận văn và định hướng phát triển
tiếp cho bài toán.

Phụ lục tài liệu tham khảo

8


CHƯƠNG 1: GIỚI THIỆU CHUNG VỀ KIẾN TRÚC HỆ THỐNG
Vấn đề áp dụng các ứng dụng của phần mềm vào quản lý doanh nghiệp và xử lý
nghiệp vụ hiện nay khơng phải là điều gì mới mẻ. Tuy nhiên với sự phát triển không
ngừng của công nghê, việc áp dụng phần mềm vào quản lý và xử lý các vấn đề nghiệp
vụ cũng khơng cịn đơn giản như trước.
Bắt đầu từ những trang web, phần mềm quản lý ngày nào, hiện này các doanh
nghiệp cịn có thể xây dựng cho mình một hệ sinh thái đa nền tảng, kết nối nhiều thiết
bị giúp doanh nghiệp quản lý được mọi lúc, mọi nơi. Tân dụng được tối đa nguồn lực
hiện có.
Các hệ thống ERPs, CRMs hay nhiều phần mềm khác chứa hàng trăm tính năng
đều được gói gọn trong một ứng dụng của doanh nghiệp. Việc mỗi doanh nghiệp xây
dựng một hệ sinh thái riêng cho mình cũng dẫn đến hệ thống thiết kế trở nên phức tạp
hơn. Các công nghệ mới không ngừng phát triển cũng dẫn đến hệ quả các doanh nghiệp
phải liên tục update nâng cấp hệ thống của chính mình. Các cơng việc bảo trì nâng cấp
cũng sẽ gặp nhiều khó khăn hơn trước, cấu trúc thiết kế ngun khối (monolithic) khơng
thể đáp ứng được nữa.
Chính vì thế mà kiến trúc Microservice ngày càng được các nhà phát triển chú ý
hơn trong những năm trở lại đây với nhiều ưu điểm khắc phục được các vấn đề cịn tồn
tại trong các ứng dụng có kích thước lớn như có thể được phát triển hay bảo trì độc lập
mà khơng ảnh hưởng đến tồn bọ phần mềm, có thể tăng nâng số lượng một chức năng
nào đó lên nếu nhu cầu sử dụng tăng cao hoặc hạ xuống nếu không cần thiết. Các đặc
điểm này trong kiến trúc Mcroservice được kỳ vọng sẽ đẩy nhanh chu kỳ phát triển của
dịch vụ Web hay phát triển các hệ thống phần mềm khác, giúp cơng việc bảo trì nâng
cấp hệ thống trở nên đơn giản hơn.
1.1. Kiến trúc một khối (Monolithic)

1.1.1. Khái niệm
Monolithic là một kiến trúc thiết kế ứng dụng nguyên khối tất cả trong một. Tất
cả các thành phần của chương trình được kết nối với nhau, phụ thuộc lẫn nhau và cùng
hoạt động trên cùng một nền tảng được xác định từ lúc bắt đầu phát triển. Mỗi ứng dụng
nguyên khối là độc lập, tất cả trong một khối từ lúc phát triển tới lúc hoàn thiện sản
phẩm để đem vào sử dụng.

9


Hình 1: Kiến trúc nguyên khối monolithic
Đây cũng là mẫu thiết kế được dùng nhiều nhất trong giới lập trình hiện nay bởi tính
đơn giản khi phát triển và khi triển khai. Mặc dù mỗi ứng dụng sẽ được triển khai theo
những cách khác nhau, nhưng nhìn chung thì khi ứng dụng được lập trình theo kiến trúc
một khối, kết quả thường đạt được như sau:
• Nó có thể hỗ trợ nhiều loại client như browser hay các app native trên cả desktop
và di động.
• Có thể cho bên thứ ba sử dụng được một số API.
• Nó có thể tích hợp với các ứng dụng khác thơng qua REST/SOAP web service
hoặc các message queue.
• Nó có thể xử lý các request dạng HTTP, thực hiện logic nghiệp vụ, truy cập cơ
sở dữ liệu và có thể trao đổi dữ liệu với các hệ thống khác.
• Nó có thể chạy trên các container như Tomcat, JBoss,..
• Nó có thể mở rộng theo chiều ngang (horizontal scalability) bằng cách load
balancers hoặc mở rộng theo chiều dọc (vertical scalability) bằng cách tăng sức
mạnh của phần cứng.
1.1.2. Ưu nhược điểm của kiến trúc Monolithic
Kiến trúc Monolithic là một trong những kiến trúc ta vẫn sử dụng rất nhiều và có
nhiều ưu điểm mà chúng ta có thể thấy được đó là:
•


Dễ dàng phát triển vì các các cơng nghệ thống nhất sử dụng ngay từ đầu của dự
án hoặc ứng dụng.

•

Dễ kiểm thử do tồn bộ dự án được gói gọn trong một gói duy nhất nên có thể
test tồn bộ dự án hoặc ứng dụng từ đầu đến cuối.
10


•

Triển khai đơn giản và nhanh chóng vì hầu như tất cả project đều thuộc một gói.

•

Phát triển ban đầu thường nhanh do có sự thống nhất về cơng nghệ phát triển từ
ban đầu và thống nhất nên các thành viên có thể dễ dàng phối hợp với nhau, các
thành viên cũng khơng cần có q nhiều kĩ năng hay hiểu biết về công nghệ đang
sử dụng nên dự án có thể nhanh chóng được hồn thành để chuyển sang giai đoạn
khác.

Nhưng ngồi những ưu điểm thì kiến trúc một khối vẫn ln cịn tồn tại những
nhược điểm:
•

Các thành phần trong dự án liên kết chặt chẽ với nhau nên khi thay đổi một thành
phần cũng bị ảnh hưởng đến các thành phần khác khiến tất cả đều cần chỉnh sửa


•

•

•

•

•

•

•

•

lại.
Theo thời gian thì dự án sẽ dần trở nên phức tạp và lớn dần. Các tính năng mới
sẽ mất nhiều thời gian hơn để phát triển và tái cấu trúc các tính năng hiện có sẽ
nhiều khó khăn hơn.
Các mơ-đun trong dự án có liên quan chặt chẽ với nhau nên nếu một cái có vấn
đề thì sẽ gây ảnh hưởng đến tồn bộ hệ thống.
Khó khăn khi áp dụng cơng nghệ mới vì tồn bộ ứng dụng sẽ phải thay đổi theo
do nhiều ứng dụng một khối thường phụ thuộc một công nghệ cũ đã được phát
triển từ lâu.
Các service quan trọng trong ứng dụng hoặc dự án không thể co giãn hoặc mở
rộng riêng dẫn đến lãng phí tài ngun vì tồn bộ ứng dụng phải mở rộng và co
giãn theo cũng như việc.
Các ứng dụng một khối lớn sẽ có thời gian khởi động lâu và tốn tài nguyên CPU
cũng như bộ nhớ.

Khó khăn trong việc bảo trì. Khi hệ thống cần thay đổi một thành phần nào đó
nhưng nhiều chức năng mà các thành phần bên trong có liên hệ chặt chẽ với nhau
khiến cho người mới sẽ khó biết phải bắt đầu từ đâu để thực hiện.
Quá trình phát triển cũng như quá trình triển khai ứng dụng sẽ tốn thời gian khi
có bất kì sự thay đổi nhỏ nào.
Tính ổn định khơng cao. Bất kì một lỗi nào có thể khiến tồn bộ ứng dụng bị
crash.

Như vậy chúng ta có thể thấy Monolithic có xu hướng phù hợp với những dự án
có quy mơ nhỏ hoặc các ứng dụng khơng có q nhiều chức năng.
1.2. Kiến trúc hướng dịch vụ (SOA)
Kiến trúc hướng dịch vụ (Service Oriented Architecture) là phương pháp thiết kế
và tích hợp các ứng dụng, chức năng, hệ thống theo dạng module trong đó mỗi module
11


đóng vai trị là một service có tính kết nối lỏng lẻo (loose coupling) có khả năng truy
cập thơng qua mơi trường mạng và quy trình nghiệp vụ với nhau để đáp ứng nhu cầu
nghiệp vụ của phần mềm. Kiến trúc hướng dịch vụ đã giải quyết các vấn đề tồn tại của
các hệ thống hiện nay như là sự phức tạp, không linh hoạt hay thiếu sự ổn định khi hoạt
động. Các dịch vụ của hệ thống thường giao tiếp với nhau thông qua các API hoặc các
giao tiếp phổ biến, chúng cũng thường cung cấp các API cho các hệ thống bên ngoài
truy cập vào một phần nào đó để tương tác như việc khai thác đọc thơng tin.
Những nguyên tắc khi xây dựng một hệ thống SOA là các dịch vụ phải được triển
khai và hoạt động một độc lập, không phụ thuộc vào dịch vụ khác. Những điều trên
khiến cho kiến trúc dịch vụ hướng đối tượng trở nên bền vững, có tính liên kết các thành
phần với nhau cũng như khả năng mở rộng phát triển dễ dàng cho các chức năng lẫn cả
ứng dụng hiện tại và sau này. Kiến trúc hướng dịch vụ có các tính chất như tính kết nối
lỏng lẻo (Loose coupling). Mỗi một thành phần trong hệ thống thường là độc lập với
nhau và nếu có liên kết thì được mô tả ràng buộc một cách rõ ràng, độ liên kết giữa các

thành phần đó quyết định tính kết dính của hệ thống và điều đó ảnh hưởng trực tiếp tới
khả năng chỉnh sửa của hệ thống hiện tại và sau này. Kiến trúc hướng dịch vụ có tính sử
dụng lại các dịch vụ. Bởi vì các dịch vụ thường đại diện cho một chức năng chung nào
đó nên có thể dễ dàng tái sử dụng lại cho các hệ thống tương tự hoặc xóa bỏ bớt các
thành phần trung lặp khơng dư thừa để tận dụng cho tính năng đó cho các hệ thống khác.
Các ứng dụng này được phát triển thông qua môi trường mạng và thường trả về kết quả
ở một dạng chung khiến các hệ thống trên nhiều nền tảng có thể giao tiếp thơng qua các
API hoặc giao tiếp cơ bản một cách dễ dàng. Một trong những tính chất cơ bản khác hệ
thống hướng dịch vụ đó là độ tin cậy của các ứng dụng khi bị gặp lỗi nhưng vẫn không
gây ảnh hưởng đến chức năng khác của hệ thống và có khả năng tự phục hồi sau đó.
Từ đó ta thấy được những lợi ích mà kiến trúc hướng dịch vụ đem lại đó là nó giúp
cho doanh nghiệp có thể tận dụng lại những tài ngun sẵn có, giảm chi phí phát triển
hay cho phần kiến trúc và tích hợp, giảm chi phí cho việc phải mua phần mềm mới. SOA
mang đến khả năng tổng hợp lại các ứng dụng và tạo ra một lớp ứng dụng mới bằng
cách kết hợp các thành phần đã có sẵn. Nhờ tính khới nối lỏng lẻo (loose coupling) giúp
tăng tính linh hoạt và khả năng triển khai và cài đặt dễ dàng hơn. Cũng chính nhờ tính
chất đó mà có thể mở rộng thêm nhiều instance của service đó để đáp ứng các yêu cầu
đồng thời giúp tăng khả năng phục vụ của các service.
1.3. Kiến trúc dịch vụ siêu nhỏ (Microservice)
Microservice đề cập đến quá trình phát triển độc lập, tương đối nhỏ theo hướng chia
hệ thống ra thành các service. Mỗi service này đều có một logic riêng, một trách nhiệm
riêng và có thể được triển khai riêng biệt. Khái niệm mircoservice đồng thời đề cập đến
12


xu hướng tách biệt kiến trúc ra thành các service có một mối ràng buộc lỏng lẻo với
nhau.
So sánh với monolithic và SOA (service-oriented architecture), những điểm khác
biệt của mô hình microservice là khả năng thành phần hóa, các chức năng có mối quan
hệ lỏng lẻo với nhau, có khả năng quản lý riêng biệt và có thể phân thành các cấp, được

phản ánh cụ thể qua những đặc điểm sau:
• Tập hợp một nhóm nhỏ các service: mức độ chi tiết của một service là nhỏ và mỗi
service này sẽ chịu một trách nhiệm cụ thể và chỉ tập trung vào nhiệm vụ đó. Ví dụ
như storage service sẽ chịu riêng trách nhiệm về lưu trữ một thành phần nào đó.
• Việc phát triển và mở rơng một service là hồn tồn độc lập. Điều này mang lại tính
linh hoạt cho hệ thống. Q trình thêm mới tính năng hoặc triển khai một phiên bản
mới cho ứng dụng sẽ dễ dàng và nhanh chóng. Khơng cịn bị tình trạng ảnh hưởng
ràng buộc với nhau như ở mơ hình monolithic.
• Giảm được các mối lo ngại về công nghệ sử dụng. Mỗi một Microservice có thể thể
chọn một cơng nghệ phù hợp với vấn đề của doanh nghiệp. Các service thường giao
tiếp với nhau thông qua API, gprc… hoặc các giao thức mở khác, do vậy mỗi service
có thể dùng một ngơn ngữ riêng biệt.
• Đối với đội ngũ vận hành và phát triển, microservice đem lại tính độc lập và tự quản
lý cho team. Một team sẽ có trách nhiệm tồn bộ với vịng đời của một hay nhiều
service. Họ có thể tự ra quyết định và phát triển độc lập cho phần mà nhóm đó đang
quản lý.
Chúng ta có thể thấy rõ tồn bộ ý tưởng của mơ hình microservice rất giống cách
mà chúng ta chia nhỏ thơng tin và kiến thức. Bằng việc tách rời, chia nhỏ và quản lí
chúng ta có thể giảm tải sự phức tạp của hệ thống, làm cho việc quản lí trở nên nhanh
chóng và dễ dàng, phản ánh sự thay đổi chính xác.
1.3.1. Khái niệm
Kiến trúc Microservice, hay đơn giản là Microservice, là một phương pháp đặc
biệt để triển khai hệ thống phần mềm, đã nổi lên mạnh mẽ trong những năm gần đây.
Nhờ khả năng mở rộng của nó mà kiến trúc này được xem là lý tưởng khi bạn phải hỗ
trợ một loạt các nền tảng như Web, các thiết bị di động, IOT (Internet of Things), các
thiết bị đeo tay hay là về các thiết bị mà bạn sẽ cần hỗ trợ trong tương lai sau này.
Kiến trúc Microservice là một mơ hình dịch vụ mới dùng để tạo một dịch vụ Web
thành một tập hợp các dịch vụ nhỏ (micro) giao tiếp với nhau và nó đang trở nên ngày
càng phổ biến vì nó có thể tăng tốc các hoạt động phát triển, triển khai và vận hành phần
mềm một cách linh hoạt. Nền tảng các kiến trúc Microservices là xây dựng một ứng

13


dụng mà ứng dụng này là tổng hợp của nhiều services nhỏ và độc lập có thể chạy riêng
biệt, phát triển và triển khai độc lập. Ý tưởng quan trọng chính là nhìn vào các tính năng
trong một ứng dụng monolithic, ta có thể nhận biết, xác định các yêu cầu và khả năng
cần thiết để đáp ứng một nghiệp vụ. Sau đó từng chức năng nghiệp vụ này sẽ được xây
dựng thành những service nhỏ, độc lập. Những services này có thể sử dụng các nền tảng
cơng nghệ khác nhau và phục vụ một mục đích cụ thể và có giới hạn.
Microservice là một kỹ thuật phát triển phần mềm, một biến thể của kiểu kiến
trúc hướng dịch vụ (SOA) cấu trúc của một ứng dụng là tập hợp các dịch vụ được được
chia nhỏ và giao tiếp với thơng qua các cơ chế thơng thường là API.

Hình 2: So sánh giữa kiến trúc một khối và kiến trúc microservice

[13]

1.3.2. Các thành phần cơ bản của Microservice
Một kiến trúc microservice điển hình nhất thì sẽ bao gồm các thành phần cơ bản
như hình sau:

14


Hình 3: Kiến trúc cơ bản của microservice [10]
-

Client (người dùng): Đây là thành phần cơ bản nhất của mọi kiến trúc, đó là phía

-


người sử dụng dịch vụ hoặc quản lý hệ thống.
Identity Providers (Cũng cấp định danh): Các yêu cầu được gửi từ phía clients sẽ
được chuyển tới nhà cung cấp định danh máy khách để sau đó các yêu cầu đó sẽ
được chuyển tới API Gateway. Sau đó các service đã được kết nói tới API
Gateway sẽ lần lượt nhận được các yêu cầu tương ứng đó.

-

-

-

-

-

API Gateway: Ta có thể hiểu là API Gateway là một điểm cho phép chuyển tiếp
các yêu cầu được gửi từ phía người dùng tới các microservice tương ứng. Tùy
theo thiết kế thì các microservice có thể trực tiếp trao đổi với nhau về thông tin
kết quả hoặc trao đổi thông qua API Gateway.
Databases (Cơ sở dữ liệu): Mỗi một microservice sẽ có một cơ sở dữ liệu riêng
đối với mỗi một chức năng hay nghiệp vụ tương ứng và được tương tác cập nhật
thông qua các API tương ứng với các microservice đó.
Static Content: Khi gửi u cầu thơng qua API Gateway để gửi yêu cầu thực hiện
tới các microservice thì ta sẽ nhận được về kết quả sau khi xử lý xong. Các nội
dung đó có thể được triển khai và lưu trữ trực tiếp các dịch vụ đám mây và được
gửi đến khách hàng thông qua các CDN.
Managerment: Thành phần managerment này có nhiệm vụ cân bằng các
microservice đang hoạt động trên các nút hoặc instance và xác định lỗi khi hoạt

động.
Service Registry và Service Discovery (Truy tìm dịch vụ):
Service Registry giúp xác định một microservice khi bắt đầu chạy với một địa
chỉ được đăng ký và hủy đăng kí khi được tắt đi.

15


Service Discovery dùng để xác định các microservice đang hoạt động để có thể
tương tác với mircoservice đó bằng cách đi tìm địa chỉ của chúng đã đăng ký khi
bắt đầu hoạt động.
Các thành phần cơ bản của một kiến trúc microservice có nhiều ưu điểm mà ta
có thể nhận thấy được như:
-

Ta có thể thoải mái sử dụng các công nghệ cho phù hợp với từng chức năng theo
từng microservice mà khơng bị gị bó giới hạn một vài công nghệ như kiểu kiến

-

trúc nguyên khối.
Mỗi một microservice thường chỉ tập trung vào duy nhất một chức năng nghiệp

-

vụ được xác định từ ban đầu.
Với kiểu kiến trúc của microservice ta có thể dễ dàng phát triển, nâng cấp tính

-


năng và triển khai một cách độc lập từng cái một.
Vì được phát triển độc lập nên có thể đảm bảo tính bảo mật an tồn cho từng

-

microservice.
Các microservice của hệ thống có thể được phát triển song song và triển khai
cùng lúc giúp rút ngắn thời gian phát triển để nhanh chóng đi vào hoạt động.

Nhưng ngồi ra kiến trúc microservice cũng tồn tại những hạn chế khi triển khai:
-

-

Vì mỗi một microservice có thể phát triển riêng độc lập nên sẽ phát sinh ra nhiều
vấn đề cần quan tâm hơn.
Vì mỗi một microservice là độc lập nên khi hoạt động mà các microservice cần
tương tác với nhau thì sẽ tốn thời gian hơn để trao đổi và xử lý trước khi đưa ra
kết quả cuối cùng so với hệ thống nguyên khối các chức năng trên cùng một nơi
triển khai nên tốc độ xử lý sẽ cao hơn.
Vì có thể triển khai độc lập được nên việc cấu hình khi triển khai các microservice
khác nhau khó hơn cũng là một vấn đề cần xem xét đến.
Điều tiếp theo là khó khăn hơn trong việc kiểm tra tính an tồn khi thực hiện các
cơng việc tại các microservice cũng như khó khăn khi theo dõi dữ liệu trên từng
microservice khi chúng hoạt động.

1.3.3. Các kiến trúc Microservice
Sau đây là một số mẫu kiến trúc microservice phổ biến thường được sử dụng nhất
hiện nay.
-


Mơ hình tổng hợp (The Aggregator Pattern):
Là mơ hình đơn giản nhất được sử dụng với Microservice. Khi gửi một yêu cầu tới,
bộ tổng hợp sẽ đi gọi tới các dịch vụ có tính tương quan liên quan tới yêu cầu được
gửi tới, sau khi tổng hợp đủ thơng tin liên quan tới u cầu đó thì được bộ tổng hợp
16


(Aggregator) tổng hợp gom nhóm lại kết quả cuối cùng và gửi trả lại phía người
dùng.
Client

Load balancing

Service A

Cache

Database

Aggregator

Service A

Cache

Database

Service A


Cache

Database

Hình 4: Mơ hình tổng hợp (Aggregator Pattern) [1]
-

Mơ hình Proxy (The Proxy Pattern):
Mơ hình Proxy là một mẫu biến thể của mơ hình tổng hợp (The Aggregator Pattern)
nhưng khơng có sự tổng hợp nào diễn ra trên cùng một máy mà nhờ vào bộ smart
proxy để chuyển hướng các yêu cầu tới các dịch vụ nhỏ được đặt ở các máy khác
nhau sau đó phản hồi về và được tổng hợp lại kết quả cuối cùng và gửi trả đủ thơng
tin theo u cầu từ phía người.

Client

Load balancing

Service A

Cache

Database

Proxy

Service A

Cache


Database

Service A

Cache

Database

Hình 5: Mơ hình Proxy (Proxy Pattern) [1]
17


-

Mơ hình đường ống (The Pipeline Pattern):
Khi một u cầu được gửi đi thì sẽ cần một loạt các bước cần hồn chỉnh. Trong
trường hợp như hình dưới thì số lượng dịch vụ được gọi nhiều nhiều nhưng chỉ trong
1 lần gửi yêu cầu của người sử dụng. Sử dụng dạng đường ống các dịch vụ cho phép
thực hiện nhiều chức năng chỉ trong một lần yêu cầu, các chức năng thực hiện nhiệm
vụ của mình theo thứ tự từng cái một cho đến khi kết thúc. Nhưng các dịch vụ yêu
cầu sự đồng bộ cho tới khi thực hiện xong nên khách hàng sẽ phải chờ đợi đến bước
cuối cùng khi dịch vụ cuối cùng trong chuỗi đường ống kết thúc.

Client

Load balancing

Service A

Service B


Service C

Cache

Cache

Cache

Database

Database

Database

Hình 6: Mơ hình đường ống (Pipeline Pattern) [1]
1.3.4. Ưu nhược điểm của kiến trúc Microservice
Microservice sinh ra để khắc phục các hạn chế của kiến trúc một khối Monolithic.
•

Các thành phần có kết nối lỏng lẻo dẫn đến dễ hoạt động độc lập, dễ dàng kiểm
thử và khởi động nhanh.

•

•

•

•


Vịng đời phát triển nhanh hơn. Tính năng mới được phát triển nhanh hơn và tính
năng cũ được cấu trúc lại dễ hơn.
Các service có thể triển khai độc lập nên ứng dụng dễ đọc khi phát triển, dễ tạo
các phiên bản vá lỗi hơn nếu có trục trặc hoặc nâng cấp.
Những vấn đề liên quan đến bộ nhớ quá tải một trong các service thì khơng gây
ảnh hưởng đến tồn bộ ứng dụng.
Việc áp dụng các công nghệ mới dễ hơn. Các thành phần có thể được nâng cấp
độc lập với nhau.

18


•

Các mơ hình mở rộng phức tạp và hiệu quả hơn có thể được thiết lập. Các service
quan trọng có thể co giãn một cách hiệu quả hơn. Các thành phần riêng sẽ khởi
động độc lập nhanh hơn và cải thiện thời gian khởi động hoạt động của cả hệ
thống.

•

Có thể sử dụng các ngôn ngữ khác nhau để phát triển các service khác nhau của

•

cùng một ứng dụng một cách dễ dàng.
Có khả năng nâng số lượng service đó lên hoặc xuống tùy nhu cầu để đáp ứng

•


yêu cầu sử dụng một cách dễ dàng.
Các nhóm phát triển tham gia sẽ ít phụ thuộc lẫn nhau vì các service trong kiến
trúc thường là độc lập.
Kiến trúc Microservices giúp đơn giản hóa hệ thống, chia nhỏ hệ thống ra làm

nhiều service nhỏ lẽ dể dàng quản lý và triển khai từng phần so với kiến trúc nguyên
khối. Phân tách rõ ràng giữa các service nhỏ. Cho phép việc mỗi service được phát triển
độc lập. Cũng như cho phép lập trình viên có thể tự do chọn lựa technology stack cho
mỗi service mình phát triển. mỗi service có thể được triển khai một cách độc lập. Nó
cũng cho phép mỗi service có thể được co giãn và mở rộng một cách độc lập với nhau.
Việc co giãn có thể được thực hiện dễ dàng bằng cách tăng số instance cho mỗi service
rồi phân tải bằng load balancer.
Tuy kiến trúc Microservices đang là một xu hướng, nhưng nó cũng có nhược điểm
của nó. Microservice khuyến khích được sử dụng để chia nhỏ các service thành các chức
năng riêng của ứng dụng, nhưng khi chia nhỏ quá sẽ dần dẫn đến nhiều thứ vụn vặt, khó
kiểm sốt. Hơn nữa chính từ đặc tính phân tán khiến cho các lập trình viên phải lựa chọn
cách thức giao tiếp phù hợp khi xử lí request giữa các service.
•

•

•

Hệ thống chia các chức năng thành các service nhỏ, khi mà hệ thống quá nhiều
chức năng sẽ khó kiểm sốt hơn.
Mỗi service sẽ có thể có cơ sở dữ liệu riêng, cách thức hoạt động riêng nên tính
đồng nhất khơng được đảm bảo, đơi khi dẫn đến sự phức tạp hơn.
Nếu các service sử dụng các chức năng của service khác một cách xếp chồng như
bậc thang, nếu một service bị lỗi thì sẽ gây ảnh hưởng đến nhiều service khác sẽ

ảnh hưởng đến cả chức năng đó của hệ thống.

• Phức tạp hơn về mặt tổng thể vì các thành phần có sử dụng các cơng nghệ khác
nhau nên buộc đội phát triển phải tập trung đầu tư thời gian để theo kịp cơng
nghệ.
• Triển khai tồn bộ ứng dụng phức tạp hơn vì có nhiều container và nền tảng ảo
hóa liên quan.

19


• Ứng dụng được mở rộng co giãn hiệu quả hơn nhưng thiết lập nâng cấp sẽ phức
tạp hơn vì nó sẽ u cầu nâng cao nhiều tính năng như truy tìm dịch vụ (service
discovery), định tuyến DNS,…
• Kết hợp các cơng nghệ phức tạp và khó để học hơn.
• Các cơng nghệ phức tạp và khó để thực hiện hơn so với phát triển theo mơ hình
ngun khối như cũ khiến thời gian phát triển ban đầu thường là chậm hơn nên
kéo theo các bước sau cũng bị chờ đợi theo.
• Yêu cầu cơ sở hạ tầng phức tạp. Thông thường sẽ yêu cầu hoạt động trên một
hoặc nhiều container (Docker) và nhiều máy JVM để chạy.
Từ những ưu nhược điểm trên ta đã có thể thấy được những thứ được và khó khăn
khi sử dụng theo mơ hình kiến trúc Microservice. Phải xem xét kĩ về hệ thống hoặc ứng
dụng để phát triển trước khi đưa ra quyết định cuối cùng. Chúng ta thường sử dụng kiến
trúc microservice khi:
• Ứng dụng có phạm vi lớn và bạn xác định các tính năng sẽ được phát triển rất
mạnh theo thời gian. Ví dụ: cửa hàng thương mại điện tử trực tuyến, dịch vụ
truyền thông xã hội, dịch vụ truyền phát video với số lượng người dùng lơn, dịch
vụ cung cấp API,…
• Kích thước đội phát triển lớn, có đủ thành viên để phát triển các thành phần hoặc
chức năng riêng lẻ một cách hiệu quả.

• Mặt bằng kỹ năng của đội phát triển tốt và các thành viên tự tin về các mẫu thiết
kế microservice nâng cao.
• Bạn sẵn sàng chi trả nhiều hơn cho cơ sở hạ tầng, giám sát,… để nâng cao chất
lượng sản phẩm.
1.3.5. Các nguyên tắc khi phát triển Microservice
Kiến trúc microservice là kiến trúc khác với kiến trúc một khối truyền thống, để
phát triển hệ thống theo kiểu kiến trúc microservice ta có 6 nguyên tắc sau khi thực hiện:
-

Nguyên tắc 1: Khả năng tái sử dụng (Reuse)
Tương tự như mơ hình hướng dịch vụ, mỗi một thành phần dịch vụ được
thiết kế ra nhằm đảm nhiệm một quy trình nghiệp vụ nào đó của doanh nghiệp
nhưng có tính nghiệp vụ chung để có thể tái sử dụng cho mộ hệ thống hay ứng
dụng tương tự. Mỗi một microservice cũng như vậy và khi được thiết kế cần xác
định được phạm vi dựa theo tính năng của service đó được thiết kế từ ban đầu.
Để khi đó có thể dễ dàng tận dụng triển khai kèm theo tính độc lập khiến cho việc

-

tái sử dụng lại chức năng đó dễ dàng hơn.
Nguyên tắc 2: Ràng buộc lỏng lẻo (Loose coupling)
20


Sự phụ thuộc giữa các service và người sử dụng được giảm bớt do việc
microservice được áp dụng nguyên tắc ràng buộc lỏng lẻo. Bằng cách tiêu chuẩn
hóa hay định hướng sử dụng theo chuẩn API đề xuất ra từ đầu, người dùng sẽ
không bị ảnh hưởng trong việc triển khai dịch vụ đó. Điều này cho phép chuyển
đổi hoặc triển khai, sửa đổi các dịch vụ của hệ thống hay cả phần dịch vụ ngay
phía sau giao diện sử dụng mà cũng không ảnh hưởng chung đến hoạt động hiện

tại của hệ thống.
Thiết kế với ràng buộc lỏng lẻo cũng là một trong những nguyên tắc khi
phát triển microserivce quyết định tính khả năng mở rộng của các microservice
trong hệ thống. Vì mỗi một microservice là độc lập, sở hữu một cơ sở dữ liệu
riêng kết hợp với khả năng ràng buộc lỏng lẻo từ khâu thiết kế giúp cho việc mở

-

rộng trở nên dễ dàng hơn bằng cách tăng giảm số lượng microservice loại đang
cần tuỳ ý mà các thành phần khác khơng bị ảnh hưởng vì ràng buộc nào.
Nguyên tắc 3: Khả năng tự chủ (Autonomy)
Khả năng tự chủ hay tự kiểm sốt là một đặc tính khi phát triển của
Microservice. Mỗi một microservice là độc lập nên có thể được triển khai trên
mơi trường hoạt động riêng với cơ sở dữ liệu riêng biệt. Điều này giúp tăng cường
hiệu suất và độ tin cậy của dịch vụ và mang đến cho người dùng sự đảm bảo về
chất lượng của dịch vụ đem lại. Chính vì có tính autonomy mà khơng bị phụ
thuộc hay rằng buộc vào các yêu tố khác của hệ thống nên tính này cũng góp
phần và tính sẵn sàng (avaibility) cũng như tính co giãn (scalabilty) chung của

-

-

các chức năng được triển khai của hệ thống.
Nguyên tắc 4: Khả năng chịu lỗi (Fault tolerance)
Mỗi một microservice khi được thiết kế sẽ có một cam kết về khả năng
chịu lỗi giữa dịch vụ của bên ứng dụng cung cấp với người sử dụng hệ thống.
Các microservice là độc lập với nhau nên khi có service bị lỗi thì chúng sẽ được
ngắt kết nối tới các microservice đang hoạt động khác. Trong hệ thống sẽ có
thành phần đảm nhận nhiệm vụ tìm và ngắt các dịch vụ bị lỗi ra khỏi hệ thống

chung đang chạy và điều hướng các yêu cầu sang các dịch vụ khác tương ứng
đang hoạt động bình thường.
Nguyên tắc 5: Khả năng kết hợp (Composability)
Một trong các nguyên tắc khi thiết kế một microservice là phải xác định
một chức năng hay tính năng của service đó. Khi thiết kế ra thì microservice đó
có khả năng kết hợp cùng với các microservice khác đã thiết kế hoặc định hướng
có thể sử dụng kèm với các microservice sẽ thiết kế trong tương lai để khi tập
hợp chúng ta có thể phát triển và tạo nên được một ứng dụng mới mà không cần
phải đi thiết kệ lại từng thành phần nhỏ đó thêm lần nữa.
21


-

Nguyên tắc 6: Khả năng dễ dàng tìm kiếm khám phá (Discoverability)
Các microservice được thiết kế dựa trên nguyên tắc thiết kế của kiến trúc
hướng dịch vụ. Nghĩa là mỗi một microservice sẽ tương ứng với một chức năng
hay tính năng nào đó phục vụ cho mục đích nghiệp vụ kinh doanh nào đó. Từ đó
dịch vụ có thể dễ dàng được các nhà phát triển, tìm kiếm, sử dụng và triển khai
cho các hệ thống cho các khách hàng mà khơng gặp tình trạng khó khăn nào.
Qua sau ngun tắc cơ bản trên ta có thể thấy microservice thừa hường khá nhiều

đặc tính khi thiết kế của kiến trúc hướng dịch vụ mà có nhiều ưu điểm vượt trội hơn.
Tuy nhiên ngoài các quy tắc thiết kế trên được nêu ra thì cũng cịn nhiều điều cần quan
tâm khi thiết kế và triển khai các microservice. Ta có thể dễ dàng triển khai nhanh nhiều
microservice với các chức năng được yêu cầu nhưng nếu không quản lý đúng từ khâu
thiết kế có thể sẽ dẫn đến việc gây cho hệ thống sẽ bị rối và loạn về sau nếu ứng dụng
ngày càng lớn và nhiều chức năng.

22



CHƯƠNG 2: CÁC ĐẶC TÍNH MICROSERVICE
2.1. Các đặc tính của Microservice
Microservice bao gồm rất nhiều khái niệm mà rất khó để xác định chính xác. Tuy
nhiên Microservice bao gồm mộ số đặc điểm chung có thể coi là một trong những đặc
tính đặc điểm chung nhất đại diện cho Microservice mà ta có thể liệt kê ra đó là:
-

Tính ổn định (Stability)

-

Tính sẵn sàng (Availability)

-

Tính co giãn (Scalablity)
Tính mở rộng (Elasticity)

-

Tính độc lập (Independent)

-

Tính đa chiều (Polyglot)

2.2. Tính ổn định (Stability)
Các service chứa các chức năng của hệ thống thường phải đảm bảo về tính ổn định,

vì nếu chỉ một thành phần bên trong có vấn đề có thể sẽ gây ảnh hưởng đến toàn bộ phần
mềm hoặc hệ thống. Vậy nên tính ổn định của các service trong các hệ thống phần mềm
ln là tiêu chí hàng đầu cần phải xem xét.
Với các chức năng trong hệ thống được chia thành các Microservice riêng biệt thì
điều này vẫn được đảm bảo như service trong hệ thống nguyên khối (Monolith). Vì các
Microservice là độc lập với nhau nên khi có 1 Microservice gặp vấn đề thì hệ thống vẫn
khơng gặp vấn đề gì và chức năng đang gặp vấn đề đó có thể được thay thế bằng một
Microservice khác khởi chạy sau đó với chức năng tương tự để đảm bảo nghiệp vụ của
phần mềm vẫn hoạt động một cách bình thường. Nếu tất cả các service đang bận hoặc
một số service bị lỗi chưa thể kịp đáp ứng lại u cầu từ phía người dùng thì u cầu đó
sẽ được giữ trong một khoảng thời gian để sau khi có service rảnh có thể đáp ứng hoặc
service mới được khởi động chạy tiếp tục xử lý và trả về kết quả như được yêu cầu từ
phía người dùng.

2.3. Tính sẵn sàng (Availability)
Các chức năng được xây dựng trong hệ thống luôn phải sẵn sàng để sử dụng theo
yêu cầu của người dung bất kể thời điểm nào. Khi hệ thống hoặc một trong các thành
phần trong hệ thống phần mềm gặp vấn đề thì các cơng việc dựa trên hệ thống cũng
buộc phải dừng lại. Điều đó chính là điểm yếu của một hệ thống nguyên khối, khi một
thành phần có vấn đề thì phải dừng cả hệ thống để chỉnh sửa và sau đó khởi động lại
tồn bộ. Một trong những đặc điểm của Microservice đó là tính sẵn sàng, khi cần sử
dụng chỉ cần chạy Microservice với chức năng mong muốn đó là có thể đáp ứng ngay
yêu cầu của người dùng trong thời gian ngắn. Với phần chức năng nào gặp vấn đề thì
23


chỉ cần tách Microservice bị lỗi đó ra và chạy khởi động Microservice đó trên một
instance khác tương tự để người dùng có thể tiếp tục sử dụng hệ thống với chức năng
đó mà cả hệ thống khơng bị ảnh hưởng gì.


Error
Replace

Hình 7: Tính sẵn sàng của Microservice
Như hình trên ta thấy, nếu hệ thống vẫn được phát triển theo kiến trúc nguyên khối
thì khi một chức năng bên trong gặp vấn đề thì cả hệ thống sẽ bị gián đoạn theo. Cịn
trong kiến trúc Microservice thì khơng bị gặp vấn đề đó. Nếu một chức năng của ứng
dụng mà gặp vấn đề thì cả ứng dụng vẫn hoạt động bình thường, đội phát triển phụ trách
Microservice đó sẽ có nhiệm vụ khỏi chạy lại chính service đó để vẫn đảm bảo tính năng
của ứng dụng hệ thống, cịn phần bị lỗi có thể dễ dàng ngắt bỏ khỏi hệ thống để kiểm
tra bảo trì mà cả hệ thống khơng bị gián đoạn, đó cũng là độc lập của Microservice sẽ
được nhắc đến sau.
2.4. Tính co giãn (Scalablity)
Một trong những tính chất đặc trưng của Microservice đó là tính co giãn. Khi một
số chức năng trong hệ thống được yêu cầu gọi sử dụng nhiều trong một thời điểm nhất
định thì hệ thống đơi khi khơng kịp đáp ứng lại chức năng mà người người dùng gọi sử
dụng chức năng đó. Khi đó để đáp ứng được số lượng cơng việc chức năng đó cần thực
hiện ta chỉ cần tăng số lượng Miroservice của chức năng đó lên để đáp ứng lại số lượng
u cầu đó. Vì mỗi một Microservice là độc lập với nhau nên việc tăng số lượng đó lên
là khơng ảnh hưởng gì đến hệ thống chung mà vẫn đáp ứng đủ yêu cầu của người dùng
gửi đến. Ta có thể giảm số lượng microservice xuống nếu nhu cầu giảm xuống để tiết
kiệm tài nguyên. Kiến trúc hệ thống có thể được co giãn theo 3 trục của khối co giãn
(Scale Cube).
24