ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

PHẠM THỊ VÂN
PHẠM THỊ VÂN

PHÁT TRIỂN
TRIỂN PHẦN
PHẦN MỀM
MỀM DỰA
DỰA TRÊN
TRÊN
PHÁT
MICROSERVICES
MICROSERVICES

Ngành: Công nghệ Thông tin
Chuyên ngành:Kỹ thuật phần mềm
Mã số: 60480103

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS.TRƯƠNG ANH HOÀNG

1

Hà Nội - 2015

2

LỜI CAM ĐOAN
Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm của riêng cá
nhân tôi, không sao chép lại của người khác. Trong toàn bộ nội dung của luận
văn, những điều đã trình bày là của cá nhân tôi hoặc là được tôi tổng hợp từ
nhiều nguồn tài liệu. Tất cả các nguồn tài liệu tham khảo có xuất xứ rõ ràng và
được trích dẫn hợp pháp.
Tôi xin chịu toàn bộ trách nhiệm và chịu mọi hình thức kỷ luật theo quy định
cho lời cam đoan của tôi.
Hà Nội, tháng 10 năm 2015

Phạm Thị Vân


3

LỜI CẢM ƠN
Tôi xin chân thành cảm ơn sự hướng dẫn và chỉ bảo tận tình của PGS.TS.
Trương Anh Hoàng – người đã luôn kiên nhẫn hướng dẫn, quan tâm, động viên,
thông cảm, tạo điều kiện thuận lợi cho tôi rất nhiều trong quá trình thực hiện
luận văn. Các định hướng và sự hiểu biết về khoa học của thầy chính là tiền đề
để tôi hoàn thành được luận văn này. Đồng thời, tôi cũng xin được gửi lời cảm
ơn đến các thầy cô giáo trong khoa Công nghệ thông tin trường Đại học Công
nghệ – Đại học Quốc Gia Hà Nội đã giảng dạy và truyền đạt những kiến thức,
kinh nghiệm quý báu cho tôi trong suốt khóa học.
Tôi cũng xin được cảm ơn các tác giả của các công trình nghiên cứu, tài liệu,
bài báo đã được tôi sử dụng, trích dẫn trong luận văn vì đã cung cấp nguồn tư

liệu quý báu và các kiến thức liên quan để tôi thực hiện luận văn.
Đặc biệt, tôi xin được cảm ơn gia đình, bạn bè và các anh chị em đồng
nghiệp – những người đã luôn động viên, hỗ trợ về mặt tinh thần và giúp đỡ, tạo
điều kiện để tôi hoàn thành luận văn đúng kế hoạch.
Hà Nội, ngày 30 tháng 10 năm 2015
Phạm Thị Vân


4

MỤC LỤC


5

DANH MỤC CÁC TỪ VIẾT TẮT
Từ viết tắt

Từ viết đầy đủ

Diễn giải

HTML

Hyper Text Markup Language

Ngôn ngữ đánh dấu văn bản

API


Application Program Interface

Giao diện lập trình ứng dụng

JavaScript Object Notation

Một cú pháp của javascript
dùng để lưu trữ và trao đổi
thông tin văn bản

SOML

Story Of My Life

Tên ứng dụng cho phép người
dùng chia sẻ các câu chuyện về
cuộc sống của mình bằng các
hình ảnh

XML

eXtensible Markup Language

Ngôn ngữ đánh dấu mở rộng

SOAP

Simple Object Access Protocol

Giao thức trao đổi thông tin


RoR

Ruby on Rails

Một framework để xây dựng
các ứng dụng trên ngôn ngữ
Ruby

IPC

Inter-Process Communication

Liên lạc liên tiến trình

HTTP

HyperText Transfer Protocol

Giao thức truyền tải siêu văn
bản

URL

Uniform Resource Locator

Địa chỉ web hay liên kết mạng

JSON,
JSONb



6

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ


7

MỞ ĐẦU
Dịch vụ (service) ra đời và ngày càng phát triển đã giúp các nhà xây dựng và
phát triển phần mềm tạo ra các hệ thống có khả năng thích ứng cao với nhiều
môi trường khác nhau, tăng khả năng tái sử dụng. Các hệ thống được phát triển
nhanh chóng và giảm được sự phức tạp, hạ giá thành khi xây dựng và triển khai.
Tuy nhiên việc không quan tâm đến kích thước của các dịch vụ trong hệ thống
đang đặt ra bài toán khó cho các nhà xây dựng và phát triển phần mềm là làm
sao giảm chi phí khi xây dựng hệ thống với các dịch vụ, làm sao tránh ảnh
hưởng đến cả hệ thống khi muốn thay đổi một số chức năng của hệ thống …
Phạm vi của dịch vụ càng lớn hệ thống càng trở lên phức tạp, khó phát triển,
kiểm thử và bảo trì. Chính những điều này đang làm cho việc xây dựng và phát
triển hệ thống phần mềm dựa trên dịch vụ đang vượt khỏi khả năng kiểm soát
của các kiểu kiến trúc phần mềm hiện có và cần phải có một kiểu kiến trúc mới
để giải quyết vấn đề này.
Kiến trúc microservices là một kiểu kiến trúc phần mềm mới và đang rất phát
triển hiện nay. Trong đó các dịch vụ được chia nhỏ để thực hiện một chức năng
duy nhất của hệ thống. Việc chia nhỏ các dịch vụ trong kiến trúc microservices
giúp cho hệ thống đơn giản hơn, dễ phát triển hơn, giảm chi phí xây dựng, tăng
khả năng thích ứng công nghệ. Kiến trúc microservices được coi là lời giải ưu
việt cho bài toán xây dựng và phát triển hệ thống dựa trên dịch vụ hiện nay. Nó
đã và đang được nghiên cứu và ứng dụng rộng rãi bởi các công ty lớn như

Netflix, Ebay, Amazon, Twitter, Paypal, Gilt, Soundcloud, …Đặc biệt là hiện
nay khi các sản phẩm phần mềm đóng gói đang dần được thay thế bởi các phần
mềm dịch vụ thì kiến trúc microservices sẽ là đề tài ngày càng được quan tâm.
Xuất phát từ những ý nghĩa thực tiễn như vậy, tôi đã thực hiện đề tài luận văn
“Phát triển phần mềm dựa trên Microservices” để tìm hiểu và áp dụng kiến trúc
microservices trong việc xây dựng và phát triển một ứng dụng cụ thể - SOML
(Story Of My Life) một dạng mạng xã hội cho phép người dùng chia sẻ các câu
chuyện trong cuộc sống của họ thông qua các bức ảnh. Dựa trên việc áp dụng
kiến trúc microservices trong thực tế từ đó đưa ra các phân tích, đánh giá và rút
ra các ưu nhược điểm của kiến trúc microservices. Luận văn sẽ được tổ chức
như sau:
Chương 1: Giới thiệu về kiến trúc microservices, nền tảng, định nghĩa, đặc
điểm, các lợi ích và mẫu thiết kế của kiến trúc microservices.
Chương 2: Trình bày các bước xây dựng hệ thống dựa trên kiến trúc
microservices như xác định, triển khai và kiểm thử các microservice cho hệ


8

thống. Từ đó áp dụng vào thiết kế, xây dựng và triển khai ứng dụng mạng xã hội
SOML.
Chương 3: Đánh giá kiến trúc microservices, đưa ra các ưu nhược điểm và
cách khắc phục các nhược điểm của kiến trúc microservices.


9

Chương 1. Tổng quan về kiến trúc microservices
Mở đầu chương 1 trình bày các khái niệm nền tảng của kiến trúc
microservices: dịch vụ, kiến trúc monolithic và định nghĩa kiến trúc

microservices. Phần tiếp theo trình bày các mẫu thiết kế của kiến trúc
microservices. Phần cuối chương trình bày các lợi ích của kiến trúc
microservices cũng như thực trạng sử dụng kiến trúc microservices hiện nay.
1.1. Dịch vụ
Dịch vụ trong phần mềm là một thành phần ứng dụng có thể thực hiện một
hoặc nhiều chức năng trong hệ thống mà không cần giao diện cho người dùng
(1). Các ứng dụng chạy trên các môi trường khác nhau đều có thể sử dụng dịch
vụ để thực hiện một hoặc một vài chức năng trong hệ thống của mình.
Dịch vụ phải có khả năng tái sử dụng, thích ứng với các môi trường khác
nhau và có thể tự động phát hiện trên toàn hệ thống, đám mây, … Mỗi dịch vụ
sẽ thực hiện xử lý các yêu cầu từ phía máy trạm và gửi lại các câu trả lời theo
một chuẩn đã quy ước, đồng thời các dịch vụ cũng có thể kết nối đến nhau để
cùng thực hiện một vài chức năng của hệ thống hoặc để tổ hợp thành một dịch
vụ khác. Một dịch vụ bao gồm ba thành phần là giao diện (interface), các ràng
buộc (contract) và cài đặt (implementation) (Hình 1.1)

Hình 1.1. Các thành phần của dịch vụ
Giao diện sẽ định nghĩa các phương thức để nhà cung cấp dịch vụ (service
provider) thực hiện các yêu cầu của người dùng dịch vụ (service consumer). Các
ràng buộc sẽ quy định các chuẩn cho phép các nhà cung cấp dịch vụ và người
dùng dịch vụ giao tiếp với nhau. Thành phần cài đặt sẽ thực hiện các chức năng
của dịch vụ.


10

1.2. Kiến trúc monolithic
Trong phần mềm, kiến trúc monolithic là một kiểu kiến trúc cho phép xây
dựng hệ thống thành một khối duy nhất, trong đó bao gồm ba thành phần: giao
diện người dùng, xử lý nghiệp vụ logic và phần truy cập dữ liệu (2) (Hình 1.2).


Hình 1.2. Các thành phần của kiến trúc Monolithic
• Giao diện người dùng: thông qua các thẻ HTML và javascript để giao
tiếp giữa người dùng và hệ thống.
• Nghiệp vụ logic: thực hiện các nghiệp vụ logic để thực hiện các yêu
cầu HTTP đồng thời tổng hợp các thông tin từ cơ sở dữ liệu dưới dạng
HTML và javascript để trả về giao diện người dùng.
• Dữ liệu truy cập: thực hiện các thao tác để chỉnh sửa, cập nhật cơ sở
dữ liệu.
Một hệ thống được xây dựng trên kiến trúc monolithic là một hệ thống hoàn
toàn khép kín, độc lập với các hệ thống khác và nó chỉ được xây dựng trên một
nền tảng duy nhất, do đó hệ thống được xây dựng trên monolithic rất dễ xây
dựng, dễ quản lý. Cũng chính vì vậy mà các hệ thống xây dựng trên kiến trúc
monolithic có một nhược điểm rất lớn là nếu có bất kỳ thay đổi nào dù là rất nhỏ
trong một trong ba thành phần của hệ thống cũng khiến đội ngũ phát triển phải
tạo ra một phiên bản mới cho cả hệ thống. Ví dụ người dùng muốn thay đổi màu
sắc của một nút ngoài giao diện người dùng thì cả hệ thống sẽ phải được điều


11

chỉnh, tái kiểm thử, tái triển khai trên một phiên bản mới. Điều này khiến cho
việc xây dựng và phát triển hệ thống trên monolithic là rất tốn kém và không
linh hoạt. Đặc biệt là với các hệ thống lớn việc xây dựng phát triển hệ thống
bằng kiểu kiến trúc monolithic sẽ trở lên rất phức tạp. Chi phí, thời gian dành
cho việc xây dựng, phát triển, sửa lỗi và kiểm thử mỗi chức năng sẽ tăng lên
theo độ lớn của hệ thống.
Mặc dù kiến trúc monolithic còn tồn tại nhiều nhược điểm nhưng nhờ các ưu
điểm độc lập, dễ xây dựng và quản lý monolithic đã được sử dụng để xây dựng
và phát triển thành các kiểu kiến phúc phần mềm khác rất phổ biến hiện nay như

kiến trúc hướng dịch vụ. Microservices cũng là một kiểu kiến trúc được xây
dựng và phát triển từ kiến trúc monolithic, mỗi dịch vụ trong kiến trúc
microservices đều kế thừa các đặc điểm độc lập của kiến trúc monolithic.
1.3. Kiến trúc microservices
Tư tưởng chia để trị của kiến trúc microservices thực ra đã được đề xuất từ
khá lâu trước đây nhưng phải đến tháng 03/2014 (3) Martin Fowler - tác giả của
mô hình phát triển ứng dụng Agile và James Lewis đã có một bài giải thích chi
tiết và thú vị trên trang web cá nhân về kiến trúc microservices. Sau đó tháng
07/2014 (4) Stefan Borjse – Giám đốc, đồng sáng lập công ty bán thiết bị Wi-fi
Karma đã viết trên blog cá nhân của mình về quá trình xây dựng cửa hàng trực
tuyến bán sản phẩm của Karma bằng cách chia nhỏ các ứng dụng thành các phần
nhỏ hơn để thực hiện, nhưng ông và các nhân viên của mình đã gặp khó khăn
trong khâu kiểm thử, vì việc kiểm thử các dịch vụ nhỏ thì tương đối dễ nhưng
khi ghép chúng vào một hệ thống thì lại là một bài toán khó.
Tháng 11/2014 (5) Toby Clemson – một nhà phát triển của ThoughtWorks đã
có một bài diễn thuyết cách tiếp cận đa lớp để thử lỗi trong các hệ thống xây
dựng trên kiến trúc microservices. Tại đây Toby đã đề nghị thử lỗi cho từng
microservice một cách độc lập để khắc phục các khó khăn trong khâu kiểm thử
của hệ thống xây dựng trên microservices mà Stefan và các đồng nghiệp của ông
đã gặp phải. Tất nhiên Toby cũng khuyến cáo việc tất cả các microservice chạy
tốt thì không có nghĩa cả hệ thống sẽ chạy tốt. Vì vậy Toby cũng đề xuất một
loạt các phương pháp về cách tích hợp các thành phần, tương tác, thử lỗi đầu
cuối để các nhà phát triển phần mềm khắc phục được các khó khăn trong quá
trình xây dựng phần mềm dựa trên kiến trúc microservices.
Kiến trúc microservices là một kiểu kiến trúc phần mềm dành cho các hệ
thống được xây dựng dựa trên các dịch vụ, trong đó các dịch vụ này được chia
thành các thành phần nhỏ và hoàn toàn độc lập với nhau, mỗi thành phần nhỏ


12


này gọi là một microservice. Mỗi microservice chỉ tập trung vào giải quyết một
chức năng duy nhất trong hệ thống và giao tiếp với nhau thông qua các API (6).
Ví dụ một ứng dụng được xây dựng trên kiến trúc microservices được thể hiện
trong Hình 1.3. Ứng dụng gồm ba microservie độc lập và giao tiếp với nhau để
thực hiện các chức năng của ứng dụng và mỗi microservice đều có một cơ sở dữ
liệu riêng và các microservice này giao tiếp với nhau thông qua các API.

Hình 1.3.Ví dụ kiến trúc microservices
Mô hình kiến trúc của microservices bao gồm ba thành phần chính: các hạ
tầng phát triển (development), các hạ tầng hoạt động (operational) và kho dữ
liệu (datastore). Ngoài ra còn có một số thành phần hỗ trợ khác như các công cụ
được trang bị (tooling), các công cụ dùng để cấu hình (configuration), định
tuyến (routing) và truy tìm phân phối (observability). Các thành phần hỗ trợ này
có thể có hoặc không.


13

Hình 1.4. Mô hình kiến trúc của microservices (7)
• Hạ tầng phát triển (development) là các nền tảng được lựa chọn để xây
dựng hệ thống như ngôn ngữ lập trình và ứng dụng đóng gói được sử
dụng trong hệ thống.
• Hạ tầng hoạt động (operations) bao gồm các thành phần cơ sở hạ tầng
để triển khai hệ thống như máy chủ, …
• Datastore quản lý các công nghệ mà hệ thống sử dụng để lưu trữ cơ sở
dữ liệu.
• Các thành phần hỗ trợ: sự trang bị (tooling), cấu hình (configuration),
khám phá (discovery), định tuyến (routing) và truy tìm, phân phối
(observability).

Mỗi microservice trong kiến trúc microservices đều có những đặc điểm
giống với các dịch vụ trong các hệ thống khác. Điều khác biệt lớn nhất là phạm
vi của microservice, nó được giới hạn trong một chỉ tiêu nhất định mà trong định
nghĩa được gọi là “nhỏ”. “Nhỏ” ở đây không phải được tính bởi số lượng dòng
code được sử dụng trong mỗi microservice, mà nhỏ ở đây chính là phạm vi để
thực hiện mỗi chức năng bất kỳ trong hệ thống - mỗi microservice trong kiến
trúc microservices chỉ giải quyết một chức năng duy nhất của hệ thống.
Các microservice giao tiếp với nhau thông qua các API. Mỗi API dùng để kết
nối các microservice sẽ có hai kiểu kết nối như sau:


14

• Đồng bộ: microservice A sử dụng API kết nối đến microservice B bằng
cách gửi thông báo và chờ microservice B phản hồi.
• Bất đồng bộ: microservice A gửi thông báo đến microservice B sau đó
tiếp tục chạy và sẽ xử lý phản hồi của B sau khi có câu trả lời.
Mỗi microservice trong kiến trúc microservices sẽ gọi đến các microservice
khác trên API bằng ba cách gọi sau:
• REST (Representational State Transfer): các thông báo được gửi qua
HTTP để truy vấn, thao tác dữ liệu. Kiểu dữ liệu sau truy vấn sẽ được
trả về dạng XML, JSON, JSONb
• RPC (Remote Procedure Call): cách gọi này giống với mô hình ClientServer trong đó microservice gửi yêu cầu kết nối sẽ đảm nhiệm vai trò
của Client và microservice nhận kết nối sẽ là Server.
• SOAP (Simple Object Access Protocol): các microservice truyền thông
điệp cho nhau dưới dạng XML.
Đối với các microservice dành cho người dùng đầu cuối sẽ không được kết
nối trực tiếp vào các microservice khác mà chúng sẽ giao tiếp với nhau thông
qua một cổng API. Cổng API này có nhiệm vụ phân tải, lưu trữ tạm thời và kiểm
tra quyền truy cập của người dùng đầu cuối.

Mỗi microservice trong kiến trúc microservices có thể có một cơ sở dữ liệu
riêng và chúng có thể có cách lưu trữ dữ liệu khác nhau. Đây là một điểm mới
trong kiến trúc microservices, khác với cách lưu trữ dữ liệu tập trung của các
kiến trúc khác.
1.4. Mẫu thiết kế trong microservices
Microservices là kiểu kiến trúc được hình thành từ các dịch vụ nên khi sử
dụng kiểu kiến trúc này ta phải lựa chọn phương pháp để các máy trạm có thể
kết nối với các microservice và cơ chế để các microservice phát hiện và giao
tiếp với nhau trên mạng. Ứng với mỗi kiểu kết nối sẽ có một hoặc nhiều mẫu
thiết kế riêng cho nó. Các máy trạm kết nối đến các microservice thì kiến trúc
microservices sẽ sử dụng mẫu thiết kế cổng API, để phát hiện dịch vụ thì có thể
sử dụng một trong hai mẫu thiết kế phát hiện phía máy trạm (Client-side
discovery) và phát hiện phía máy chủ (Server-side discovery). Để đăng ký dịch
vụ thì kiến trúc microservices cho phép các microservice đăng ký dịch vụ với
hai mẫu thiết kế tự đăng ký (self-registration) và đăng ký qua bên thứ ba (thirdparty registration).
Cổng API


15

Trên thực tế các máy trạm có thể kết nối trực tiếp đến các microservice thông
qua một số giao thức nhưng sử dụng phương pháp này sẽ gây nguy hiểm cho
tường lửa trong hệ thống. Vì vậy người ta sẽ tránh sử dụng các phương pháp kết
nối trực tiếp này mà sử dụng một máy chủ trung gian để thực hiện việc đó, máy
chủ trung gian này được gọi là cổng API. Cổng API này có chức năng và vai trò
giống với mẫu thiết kế Facade1 trong kiến trúc hướng đối tượng, nó giúp hệ
thống ẩn đi kiến trúc nội bộ của mình với các hệ thống khác và cung cấp các
API cho mỗi máy trạm khác nhau. Thông qua cổng API các yêu cầu được gửi đi
từ máy trạm sẽ được định tuyến, chuyển đổi giao thức để tìm được microservice
thích hợp thực hiện yêu cầu đó và sau đó sẽ tổng hợp các kết quả lại trả về các

máy trạm.
Ví dụ trong Hình 1.5 mô tả một ứng dụng quản lý sản phẩm có hai
microservice là Products service và Cart service. Cổng API đóng vai trò kết nối
máy trạm đến các microservice của hệ thống.

Hình 1.5. Cổng API trong ứng dụng quản lý sản phẩm
Khi các máy trạm muốn truy xuất thông tin của một sản phẩm, nó sẽ gửi yêu
cầu đến cổng API và cổng API sẽ định tuyến các yêu cầu này để chuyển chúng
đến Products service xử lý. Sau khi Products service xử lý xong, các câu trả lời
sẽ được cổng API tổng hợp lại và trả về các máy trạm qua đường
dẫn/products/product_id=xxx.
Việc sử dụng cổng API trong kiến trúc microservices giúp các hệ thống có
thể tăng độ bảo mật vì nó giúp hệ thống giấu đi kiến trúc bên trong của mình,
các yêu cầu truy xuất từ các máy trạm thay vì phải truy vấn đến các
microservice cụ thể thì nó chỉ cần gửi yêu cầu đến cổng API. Điều này sẽ giúp
giảm số lượng trao đổi giữa máy trạm và các microservie và tối ưu hoá mã
nguồn phía máy trạm. Nhưng cũng chính vì các yêu cầu của máy trạm phải đi
qua cổng API mới truy xuất được đến các microservice nên có thể nó sẽ trở
1 />

16

thành nút thắt cổ chai trong hệ thống.
Phát hiện dịch vụ
Các microservice trong kiến trúc microservices có thể giao tiếp trực tiếp với
nhau hoặc thông qua cổng API, để thực hiện được việc này thì cổng API và các
microservice cần biết chính xác vị trí của các microservice trong hệ thống. Tuy
nhiên mỗi microservice được gán một vị trí động và vị trí bản sao của chúng
cũng sẽ được thay đổi liên tục để đáp ứng khả năng tự điều chỉnh và nâng cấp,
cho nên cổng API hay bất cứ microservice trong hệ thống khi muốn kết nối đến

một microservice khác cũng cần có một cơ chế để phát hiện dịch vụ. Có hai cơ
chế để phát hiện dịch vụ trong kiến trúc microservices đó là phát hiện phía máy
trạm (client-side discovery) và phát hiện phía máy chủ (server-side discovery).
Cả hai cơ chế này đều thông qua service registry - một cơ sở dữ liệu chứa các
thể hiện (instances) và vị trí của các microservice trong hệ thống để phát hiện
dịch vụ. Mỗi service registry sẽ có một API dùng để quản lý việc đăng ký của
các microservice trong hệ thống và một API truy vấn để thực hiện các truy vấn
đến các microservice đã được đăng ký trong hệ thống.
• Phát hiện dịch vụ phía máy trạm (client-side discovery): việc phát
hiện dịch vụ được thực hiện từ phía máy trạm, mỗi microservice đều
có một cơ sở dữ liệu để lưu đăng ký dịch vụ (registry client) của mình
và các registry client sẽ được kết nối với cơ sở dữ liệu service registry.
Máy trạm muốn biết vị trí của micoservice nào thì chỉ việc gửi yêu cầu
truy vấn đến service registry sau đó service registry sẽ trả lại máy trạm
địa chỉ của microservice mà nó muốn kết nối để hai microservice này
kết nối với nhau.

Hình 1.6. Cơ chếphát hiện phía máy trạm (client-side discovery)
Hình 1.6 thể hiện hoạt động của cơ chế phát hiện dịch vụ phía máy
trạm, mỗi microservice trong hệ thống đều có một registry client dùng
để lưu vị trí của nó và các registry client này đều có kết nối đến service
registry. Khi microservice 1 muốn thực hiện kết nối đến microservice 2


17

nó sẽ gửi một yêu cầu biết vị trí của microservice 2 đến service
registry. Sau đó service registry sẽ trả về địa chỉ của microservice 2
cho microservice 1.
• Phát hiện dịch vụ phía máy chủ (server-side discovery) cho phép

phát hiện các dịch vụ bằng cách máy trạm gửi các yêu cầu kết nối đến
các microservise thông qua cân bằng tải - load balancer. Cân bằng tải
này sẽ truy vấn đến service registry và định tuyến các yêu cầu này đến
các microservice thích hợp.

Hình 1.7. Cơ chế phát hiện dịch vụ phía máychủ (server-side discovery)
Hình 1.7 mô tả cơ chế phát hiện dịch vụ phía máy chủ, trong đó
microservice 1 muốn kết nối đến microservice 2 trong hệ thống nó sẽ
gửi một yêu cầu kết nối đến load balancer sau đó load balancer sẽ truy
vấn đến service registry để lấy vị trí của microservices 2 và định tuyến
yêu cầu này đến microservice 2 để thực hiện.
Đăng ký dịch vụ
Để các microservie trong kiến trúc microservices có thể kết nối với nhau thì
mỗi microservice cần phải được đăng ký dịch vụ. Có hai cách để thực hiện việc
đăng ký dịch vụ:
• Tự đăng ký (self-registration) mỗi thể hiện (instance) của mỗi
microservice có khả năng tự đăng ký và huỷ đăng ký microservice đó
với sesrvice registry bằng cách gửi một yêu cầu (register hoặc
unregister) có chứa thông tin về tên microservice và địa chỉ của nó
(Hình 1.8)


18

Hình 1.8.Cơ chế tự đăng ký dịch vụ(self-registration)
Trong Hình 1.8, khi microservice 1 muốn đăng ký với service registry
nó sẽ gửi đến service registry một thông báo register("microservice1",
"10.0.0.1:3000") và ngược lại khi microservice 1 gửi đến service
registry thông báo unregister("microservice1", "10.0.0.1:3000") thì
microservise 1 sẽ bị huỷ đăng ký ra khỏi service registry.

• Đăng ký qua bên thứ ba (third-party registration) các thể hiện của
microservice không cần tự đăng ký với service registry mà sẽ có một
thành phần khác thực hiện việc này, thành phần đó được gọi là
registrar. Registrar theo dõi các thay đổi của các microservice trong hệ
thống bằng cách bỏ phiếu trong môi trường phát triển (polling) hoặc
đăng ký vào các sự kiện (subscribing). Khi registrar phát hiện ra có
một microservice mới tham gia vào hệ thống nó sẽ đăng ký
microservice đó với service registry bằng cách gửi thông báo register
có chứa tên microservice và địa chỉ của microservice đó đến service
registry và thông báo unregister trong trường hợp huỷ đăng ký.

Hình 1.9.Cơ chế đăng ký dịch vụ qua bên thứ ba (third-party registration)
Hình 1.9 mô tả cơ chế hoạt động của registrar trong kiến trúc microservices,
registrar liên tục kiểm tra hệ thống thông qua việc bằng cách bỏ phiếu trong môi
trường phát triển hoặc đăng ký vào các sự kiện khi registrar phát hiện
microservice 1 chưa được đăng ký với service registry nó sẽ gửi đến service
registry một thông báo register("microservice1", "10.0.0.1:3000") và ngược lại
khi registrar gửi đến service registry thông báo unregister("microservice1",
"10.0.0.1:3000") thì microservise 1 sẽ bị huỷ đăng ký ra khỏi service registry.
1.5. Lợi ích của microservices
Dễ hiểu, dễ quản lý hệ thống
Mỗi microservice trong kiến trúc microservices chỉ thực hiện một chức năng
duy nhất của hệ thống nên nó đòi hỏi ít mã code, dễ hiểu và dễ quản lý và đặc


19

biệt nó sẽ ít có nguy cơ thay đổi.
Đáp ứng nhiều công nghệ khác nhau
Các microservice trong kiến trúc microservices hoàn toàn độc lập với nhau

nên có thể xây dựng mỗi microservice trên một nền tảng khác nhau mà không
ảnh hưởng đến hệ thống, do đó có thể lựa chọn công nghệ phù hợp nhất cho mỗi
microservice giúp tăng hiệu quả và chất lượng cho hệ thống. Đặc biệt các
microservice trong microservices có thể được đẩy lên các máy chủ khác nhau,
điều này giúp hệ thống hoạt động linh hoạt hơn rất nhiều đồng thời cũng cho
thấy được sự khác biệt rõ ràng của microservice so với các mô đun.
Dễ dàng mở rộng quy mô
Các microservice trong hệ thống là độc lập với nhau nên khi muốn mở rộng
hệ thống ta chỉ việc chỉnh sửa các microservice cần mở rộng và cập nhật phần
cứng (nếu cần) cho các microservice này mà không ảnh hưởng đến hệ thống.
Các microservice khác vẫn chạy trên các nền tảng phần cứng nhỏ hơn. Điều này
cho phép tiết kiệm chi phí, tận dụng mọi tài nguyên hiện có khi mở rộng quy mô
cho hệ thống.
Tiết kiệm chi phí khi xây dựng và vận hành
Các microservice có quy mô rất nhỏ giúp cho các nhà phát triển phần mềm
dễ dàng xây dựng với chi phi thấp. Khả năng tái sử dụng và ít thay đổi của mỗi
microservice giúp giảm chi phí cho quá trình xây dựng và vận hành phần mềm.
Tóm lại với kiến trúc microservices, chúng ta có thể cập nhật công nghệ,
chỉnh sửa hệ thống một cách nhanh chóng mà không làm ảnh hưởng đến hệ
thống đây chính là lời giải tốt nhất cho các khó khăn khi áp dụng các công nghệ
mới vào xây dựng phát triển phần mềm mà có thể tránh được các rủi ro do nó
gây ra. Việc áp dụng microservices có thể giảm được chi phí, tăng độ thích nghi
và đơn giản hóa hệ thống cho các nhà phát triển phần mềm.
1.6. Thực trạng ứng dụng kiến trúc microservices hiện nay
Kiến trúc microservices đang là một trong những chủ đề hấp dẫn nhất trong
lĩnh vực công nghệ phần mềm hiện nay. Tuy nó còn khá mới nhưng kiến trúc
microservices đã được nhiều các công ty lớn đang áp dụng cho việc xây dựng hệ
thống, điển hình như Netflix, Ebay, Amazon, Twitter, Paypal, Gilt, Soundcloud
…
Nền tảng ban đầu được lựa chọn để các nhà phát triển tại Amazone xây dựng

hệ thống là kiến trúc monolithic trên ngôn ngữ C++ nhưng cùng với sự phát
triển ngày một phình to ra của hệ thống, Amazone quyết định đổi sang sử dụng


20

Java và Scala, nhưng điều đó cũng không cải thiện được nhiều. Cuối cùng
Amazone sử dụng microservices cho hệ thống của họ. Theo thống kê mới nhất
từ Amazone thì hiện nay đang có 100-150 microservice đang được sử dụng
trong hệ thống của họ (8).
Twitter là một mạng xã hội lớn có số lượng người dùng đứng thứ hai trên thế
giới2, ban đầu Twitter được Jack Dorsey và các đồng nghiệp của mình lựa chọn
monolithic và Rails để xây dựng và phát triển hệ thống. Cũng giống như
Amazone, khi số lượng người dùng Twitter tăng quá nhanh, Twitter chuyển qua
sử dụng JS/Rails/Scala, nhưng càng ngày càng xuất hiện nhiều vấn đề trong hệ
thống của Twitter. Việc số lượng người dùng tăng nhanh, công nghệ đòi hỏi cần
được nâng cấp, thay đổi, Twitter cần một công nghệ mới để giải quyết các khó
khăn của họ và kiến trúc microservices đã được mạng xã hội lớn thứ hai trên thế
giới này lựa chọn. Hiện tại Twitter vẫn đang trong quá trình phát triển hệ thống
dựa trên kiến trúc microservices.
Netflix có lẽ là công ty sớm nhất sử dụng kiến trúc microservices cho hệ
thống của mình (2011). Hàng năm có hàng triệu người dùng truy cập vào hệ
thống của Netflix để xem các video, truyền hình trực tuyến của họ. Vì vậy hệ
thống của Netflix phải đảm bảo xử lý hàng triệu truy vấn xem, tạo video mỗi
ngày và kiến trúc monolithic hiện tại của Netflix đã không còn phù hợp nữa.
Reed Hastings và các kỹ sư tại Netflix đã có một quyết định đột phá là phải tái
cấu trúc lại kiến trúc của họ. Kế hoạch của họ là phải tạo ra các dịch vụ riêng
biệt để xử lý, thu thập và cung cấp các dữ liệu cho các truy vấn của người dùng
để thời gian đáp ứng cho người dùng là nhanh nhất. Ngoài ra khi chia nhỏ thành
các dịch vụ như vậy thì các chức năng của hệ thống sẽ dễ dàng được phát triển,

kiểm thử, gỡ lỗi và triển khai. Tính đến nay Netflix đã có hơn 600 microservice
chạy trong hệ thống microservices của họ (9).
Từ những ví dụ về phát triển microservices tại các công ty hàng đầu về công
nghệ ở trên chúng ta có thể thấy kiến trúc microservices đang là kiểu kiến trúc
mà các nhà phát triển phần mềm đang hướng tới. Hiện nay kiến trúc
microservices cũng đang là kiểu kiến trúc dành được nhiều sự chú ý và quan tâm
của các nhà nghiên cứu và phát triển phần mềm, nó cũng đang được dự đoán là
kiểu kiến trúc dành cho tương lai khi mà các sản phẩm phầm mềm hướng dịch
vụ đang ngày càng phổ biến.
Ở chương 1 tôi đã trình bày các kiến thức cơ bản về kiến trúc microservices,
các đặc điểm, mẫu thiết kế và lợi ích nó mang lại cho ngành phát triển phần
2 />

21

mềm, cũng như tình hình áp dụng microservices hiện nay trong việc xây dựng
và phát triển phần mềm. Trong chương tiếp theo tôi sẽ trình bày quá trình xây
dựng một hệ thống trên microservices và áp dụng vào xây dựng ứng dụng
SOML.


22

Chương 1. Xây dựng ứng dụng SOML trên microservices
Chương 2 sẽ trình bày các bước để thiết kế và xây dựng ứng dụng mạng xã
hội - SOML trên kiến trúc microservices. Phần đầu chương giới thiệu về ứng
dụng SOML. Các phần tiếp theo của chương trình bày chi tiết các bước để xây
dựng ứng dụng này dựa trên kiến trúc microservices cũng như việc triển khai,
kiểm thử ứng dụng.
1.7. Giới thiệu về SOML

1.7.1. SOML
Mạng xã hội (các website, ứng dụng có thể kết nối các thành viên có cùng sở
thích, cùng nơi sinh sống, học tập, làm việc… lại với nhau thông qua mạng
Internet) đang dần trở thành xu thế của hiện nay, hàng ngày có hàng trăm triệu
người dùng trên thế giới truy cập vào các mạng xã hội. Hiện nay có rất nhiều các
loại mạng xã hội khác nhau như Facebook, Twitter, Google plus, My space,
SnapChat, ... Theo thống kê mới nhất tính đến tháng 8 năm 2015 thì Facebook là
mạng xã hội lớn nhất thế giới với trên một tỉ tài khoản của người dùng được sử
dụng hàng tháng, tiếp theo là Twitter có trên 360 triệu người dùng3.
Bên cạnh các mạng xã hội đa chức năng thì các mạng xã hội chuyên biệt
cũng rất phát triển như Instagram – một mạng xã hội chuyên biệt dành cho
người dùng đăng ảnh và cung cấp các hiệu ứng để người dùng chỉnh sửa ảnh của
họ. SOML cũng là một mạng xã hội với ý tưởng như vậy, SOML cho phép
người dùng chia sẻ các câu chuyện trong cuộc sống thông qua các bức ảnh và
kết nối những câu chuyện của người dùng lại với nhau. SOML là một mạng xã
hội nên nó phải đáp ứng được lượng truy cập lớn từ nhiều người dùng cùng một
lúc trên mọi thiết bị như máy tính, điện thoại, ... và nó cũng phải có khả năng
thích nghi với mọi sự thay đổi của công nghệ. Đặc biệt việc xây dựng một mạng
xã hội sẽ cần sự tham gia của nhiều người vì thế hệ thống phải có kiến trúc dễ
hiểu, đáp ứng khả năng có thể chia nhỏ dành cho nhiều người cùng phát triển và
không ảnh hưởng đến nhau và nó phải dễ bảo trì trong quá trình hoạt động. Việc
bảo trì bất cứ chức năng nào trong hệ thống phải độc lập và không ảnh hưởng
đến hoạt động của cả hệ thống. Chính vì những yêu cầu này tôi quyết định chọn
microservices làm kiến trúc để xây dựng ứng dụng SOML.
1.7.2. Các chức năng của SOML
Ý tưởng hoạt động của SOML rất đơn giản, mỗi người dùng khi có tài khoản
trên SOML sẽ có quyền tạo nhiều story cho riêng họ và mỗi story sẽ có rất nhiều
3 />

23


photo.

Hình 2.1.Mô hình hoạt động của SOML
Hình 2.1 mô tả mô hình hoạt động của SOML, người dùng sau khi đăng nhập
có thể tạo một hoặc nhiều Story và mỗi Story này có thể có một hoặc nhiều
Photo. Khi người dùng tạo Story xong, Story của họ sẽ có trạng thái là private,
người dùng có thể đăng Photo cho Story đó và chuyển trạng thái của nó sang
public để người dúng khác có thể nhìn thấy và bình luận về Story đó.
Ứng dụng SOML có bốn chức năng chính: quản lý người dùng, quản lý
Photo, quản lý Story và quản lý Comment được thể hiện như trong Hình 2.2.


24

Hình 2.2.Sơ đồ ca sử dụng tổng thể củaSOML
• Quản lý người dùng: cho phép người dùng tạo, sửa, xoá thông tin của
họ để đăng nhập vào SOML (Hình 2.3).
o Đăng ký: người dùng điền thông tin gồm tên, email và mật khẩu
để đăng ký vào hệ thống. Người dùng cũng có thể đăng ký vào
SOML thông qua tài khoản trên mạng xã hội Facebook và
Twitter. Mọi thông tin sau khi người dùng đăng ký sẽ được lưu
vào cơ sở dữ liệu. Để tránh việc người dùng sử dụng địa chỉ
email của người khác để đăng ký vào SOML thì tất cả các tài
khoản sau khi đăng ký đều phải xác nhận lại bằng email mà
người dùng đã dùng để đăng ký. Việc đăng ký chỉ thành công
sau khi người dùng xác nhận việc đăng ký của họ qua email.
o Đăng nhập: người dùng có tài khoản trong SOML sẽ đăng nhập
vào SOML bằng cách điền thông tin email và mật khẩu đã đăng
ký hoặc tài khoản Facebook, Twitter.

o Xoá tài khoản: người dùng có thể ngừng hoạt động tài khoản


25

của mình trên SOML.

Hình 2.3.Sơ đồ ca sử dụng của quản lý người dùng
• Quản lý Story cho phép người dùng tạo, sửa, xóa các Story trong
SOML (Hình 2.4)

Hình 2.4.Sơ đồ ca sử dụng của quản lý Story
o Tạo Story: người dùng sau khi đăng nhập vào SOML có thể tạo
một hoặc nhiều Story cho mình. Mỗi Story được tạo sẽ được
lưu trữ vào cơ sở dữ liệu Stories với các thông tin: tên Story,
mô tả Story, người dùng tạo Story, mảng lưu trữ các id của các
bức ảnh trong Story, ảnh đại diện cho Story và trạng thái của
Story (publish / private).
o Sửa Story: người dùng phải đăng nhập để sửa Story của mình.
Sau khi người dùng xác nhận sửa xong thì mọi thông tin mới
của Story đó sẽ được lưu vào cơ sở dữ liệu.