Thiết kế và xây dựng microservice với khả năng đáp ứng thay đổi về quy mô

Thiết kế và xây dựng microservice với khả năng đáp ứng thay đổi về quy mô Thiết kế và xây dựng microservice với khả năng đáp ứng thay đổi về quy mô Thiết kế và xây dựng microservice với khả năng đáp ứng thay đổi về quy mô luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp

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

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 toà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

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 quá 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 hoà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

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 toán 30

3.2 Mô hình hệ thống 31

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

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

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

DANH MỤC HÌNH ẢNH

Hình 1: Kiến trúc nguyên 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

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 quãng 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

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 toá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

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 toá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 toá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

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ế nguyên 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 toà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

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 toàn bộ dự án được gói gọn trong một gói duy nhất nên có thể test toàn bộ dự án hoặc ứng dụng từ đầu đến cuối

• 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ó quá 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 hoàn thành để chuyển sang giai đoạn khác

Nhưng ngoài những ưu điểm thì kiến trúc một khối vẫn luôn 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 toàn bộ hệ thống

• Khó khăn khi áp dụng công nghệ mới vì toà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 nguyên vì toà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 toà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ó quá 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

đó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 nguyên 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

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à hoàn toàn độc lập Điều này mang lại tính linh hoạt cho hệ thống Quá 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 toà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õ toà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

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:

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 yê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

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 toà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 ngoà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 toà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 yêu cầu đó thì được bộ tổng hợp

(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

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 yêu cầu từ phía người

- Mô hình đường ống (The Pipeline Pattern):

Khi một yêu cầu được gửi đi thì sẽ cần một loạt các bước cần hoà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

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 toà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

• 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 soá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 soá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 toà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

• Ứ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ẽ yê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 nguyên 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)

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 soá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

- 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 nguyên 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

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à:

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 luôn 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 yêu cầu từ phía người dùng thì yê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 toà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ì

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

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 yê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)

Hình 8: Khối co giãn (Scale Cube) [9]

Với việc co giãn theo trục X là bổ sung thêm web application sau bộ phận chịu tải, tương đương với việc tăng số lượng hệ thống đáp ứng đó lên thêm Việc co giãn theo trục X là một cách để tăng khả năng chứa như việc tăng thêm database cho việc lưu trữ

đó tất cả các thông tin đó sẽ được tập hợp và gửi lại về cho phía người dùng

Việc co giãn theo trục Y như thế này vẫn đảm bảo tính độc lập của từng service

đó Các service đó sẽ được triển khai một cách độc lập và sẽ không ảnh hưởng đến các service khác trong cùng hệ thống hay ứng dụng đang hoạt động Khi cần chức năng nào

đó chỉ cần điều chỉnh số lượng microservice của chức năng đó lên hoặc xuống để đáp ứng yêu cầu công việc cần xử lý

Các Microservice đặc tính là độc lập, nghĩa là mỗi một microservice có thể được phát triển và triển khai một cách độc lập mà không bị phụ thuộc vào bất kì các yếu tố khác sẽ được nếu ở mục sau Chính điều đó giúp ta thấy được tính co giãn của microserivce và việc tăng giảm số lượng microservice sẽ giúp cho tiết kiệm tài nguyên

hệ thống như chỉ việc chỉ cần triển khai microservice cần thiết cũng như thời gian triển khai chỉ microservice đó mà không phải là cả hệ thống như kiến trúc một khối ngày trước Như ví dụ hình trên ta chỉ cần tăng số lượng order service lên trong một thời điểm