Kiến trúc microservices và hệ thống quản lý đấu giá quảng cáo trực tuyến

Mục đích nghiên cứu của luận văn Để phục vụ cho người dùng tiếp cận với hình thức quảng cáo trực tuyến, tăng trải nghiệm người dùng, hệ thống sẽ được xây dựng sử dụng kiến trúc microser

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

-

NGUYỄN VŨ QUYỀN

KIẾN TRÚC MICROSERVICES VÀ HỆ THỐNG QUẢN LÝ ĐẤU GIÁ QUẢNG CÁO TRỰC TUYẾN

Chuyên ngành: Kỹ thuật phần mềm

LUẬN VĂN THẠC SĨ KỸ THUẬT

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

-

NGUYỄN VŨ QUYỀN

KIẾN TRÚC MICROSERVICES VÀ HỆ THỐNG QUẢN LÝ ĐẤU GIÁ QUẢNG CÁO TRỰC TUYẾN

Chuyên ngành: Kỹ thuật phần mềm

LUẬN VĂN THẠC SĨ KỸ THUẬT

NGƯỜI HƯỚNG DẪN KHOA HỌC:

TS Nguyễn Thị Thu Trang

LỜI CẢM ƠN Lời đầu tiên, em xin chân thành cảm ơn TS Nguyễn Thị Thu Trang, Bộ môn Công nghệ phần mềm, Trường Đại học Bách Khoa Hà Nội, đã nhiệt tình hướng dẫn, truyền đạt những kiến thức cần thiết và định hướng cho em trong quá trình thực hiện đề tài để có thể hoàn thành bài luận văn tốt nghiệp này

Em cũng chân thành cảm ơn thầy, cô Viện Công nghệ Thông tin và Truyền thông - Trường Đại học Bách Khoa Hà Nội đã truyền đạt kiến thức, định hướng trong quá trình học tại trường

Dù đã cố gắng nhưng luận văn chắc chắn không tránh khỏi nhiều thiếu sót, em rất mong nhận được ý kiến đóng góp của các thầy cô

Em xin chân thành cảm ơn!

LỜI CAM ĐOAN

Tôi - Nguyễn Vũ Quyền - cam kết luận văn 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 TS Nguyễn Thị Thu Trang

Các kết quả nêu trong luận văn 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 20 tháng 10 năm 2019

Học viên

Nguyễn Vũ Quyền

MỤC LỤC

ĐẶT VẤN ĐỀ 8

Lý do chọn đề tài 8

Mục đích nghiên cứu của luận văn 9

Tóm tắt luận điểm cơ bản và đóng góp mới của tác giả 9

Phương pháp nghiên cứu 10

CHƯƠNG 1 KHẢO SÁT VÀ PHÂN TÍCH YÊU CẦU HỆ THỐNG ĐẤU GIÁ TRỰC TUYẾN 11

1.1 Khảo sát hiện trạng 11

1.2 Tổng quan hệ thống 13

1.2.1 Biểu đồ use case tổng quan 15

1.2.2 Biểu đồ use case phân rã 16

CHƯƠNG 2 KIẾN TRÚC MICROSERVICES VÀ CÁC CÔNG NGHỆ SỬ DỤNG 22

2.1 Kiến trúc microservices 22

2.1.1 Microservices là gì 22

2.1.2 Đặc điểm của Microservices 23

2.1.3 Microservices giao tiếp với nhau như thế nào 24

2.1.4 Ưu và nhược điểm của Microservices 24

2.2 CQRS Pattern 26

2.2.1 Command Pattern 26

2.2.2 Command Bus 27

2.2.3 CQRS Pattern là gì? 29

2.3 API gateway 31

2.4 Các công nghệ sử dụng 33

2.4.1 Ngôn ngữ lập trình Golang 33

2.4.2 Hệ thống thông điệp NATS 36

2.4.4 gRPC (gRPC Remote Procedure Calls) 39

2.4.5 Hệ quản trị cơ sở dữ liệu Postgresql 42

CHƯƠNG 3 THIẾT KẾ VÀ XÂY DỰNG ỨNG DỤNG ĐẤU GIÁ TRỰC TUYẾN VỚI KIẾN TRÚC MICROSERVICES 44

3.1 Kiến trúc Microservices cho hệ thống đấu giá trực tuyến 44

3.2 Thiết kế chi tiết 47

3.2.1 Dịch vụ đấu giá 49

3.2.2 Dịch vụ quản lý đấu giá 51

3.2.3 Dịch vụ lịch sử đấu giá 55

3.3 Xây dựng ứng dụng 58

3.4 Kết quả đạt được 63

CHƯƠNG 4 THỬ NGHIỆM VÀ ĐÁNH GIÁ HỆ THỐNG ĐẤU GIÁ 64

4.1 Thử nghiệm hệ thống đấu giá 64

4.1.1 Kịch bản thử nghiệm 65

4.1.2 Kiểm thử hệ thống 66

4.2 Đánh giá hệ thống 71

4.3 Phương hướng cải tiến 71

KẾT LUẬN 72

DANH MỤC CÁC TÀI LIỆU THAM KHẢO 73

DANH MỤC TỪ VIẾT TẮT VÀ THUẬT NGỮ

Từ viết tắt, thuật ngữ Từ viết đầy đủ

TCP/IP Transmission Control Protocol / Internet Protocol

CAP Consistency, Availability, Partition tolerance

MỤC LỤC HÌNH ẢNH

Hình 1 Biểu đồ use case tổng quan 15

Hình 2 Biểu đồ phân rã use case đấu giá 16

Hình 3 Biểu đồ phân rã use case quản lý đấu giá 18

Hình 4 Biểu đồ phân rã use case lịch sử đấu giá 20

Hình 5 Kiến trúc microservices 22

Hình 6 Mô hình giao tiếp giữa các Microservice 24

Hình 7 Mô hình command bus 29

Hình 8 Mô hình CQRS 30

Hình 9 Mô hình API gateway 32

Hình 10 Mô hình hoạt động của NATS 38

Hình 11 Giao tiếp giữa các máy chủ sử dụng gRPC 40

Hình 12 Kiến trúc microservice cho hệ thống đấu giá trực tuyến 44

Hình 13 Kiến trúc microservices theo mẫu CQRS 45

Hình 14 Tăng quy mô cho dịch vụ đấu giá 46

Hình 15 Biểu đồ thực thể hệ thống đấu giá 47

Hình 16 Luồng nghiệp vụ đấu giá công khai 48

Hình 17 Luồng dịch vụ đấu giá 49

Hình 18 Luồng dịch vụ quản lý đấu giá 51

Hình 19 Luồng dịch vụ truy vấn lịch sử đấu giá 55

Hình 20 Cấu trúc hệ thống 58

Hình 21 Cấu trúc phát triển dịch vụ 59

Hình 22 Khởi tạo kết nối trong tệp main.go 60

Hình 23 Khai báo chức năng trong handler interface 60

Hình 24 Đăng kí api với tệp proto 61

Hình 25 Khai báo chức năng trong service interface 61

Hình 26 Định nghĩa thực thể và khai báo chức năng trong storage interface 62

Hình 27 Luồng xử lý của hệ thống 62

Hình 28 Khởi tạo dịch vụ lịch sử đấu giá 64

Hình 29 Khởi tạo dịch vụ đấu giá 64

Hình 30 Khởi tạo dịch vụ admin 64

Hình 31 Admin tạo danh sách phiên đấu giá 66

Hình 32 Màn hình tạo phiên đấu giá 67

Hình 33 Danh sách các phiên đấu giá 68

Hình 36 Màn hình thông báo giá không hợp lệ 69 Hình 37 Thông báo đấu giá thành công 70 Hình 38 Màn hình lịch sử đấu giá sau khi người dùng đấu giá 70

ĐẶT VẤN ĐỀ

Lý do chọn đề tài

Trong thời đại bùng nổ công nghệ thông tin như hiện nay, nhu cầu nắm bắt các tin tức, mua sắm trực tuyến của người dân ngày càng tăng cao Ngoài các hệ thống như các trang thương mại điện tử, trang báo điện tử thông thường, còn có một kênh thông tin nữa cần được khai thác quảng cáo, đó chính là hệ thống báo nói của VBee

Do việc đọc báo trở nên tốn thời gian hơn khi trong một ngày có quá nhiều bài báo được viết nói về các sự kiện trong nước cũng như trên thế giới, người dùng nếu muốn cập nhật kịp thời sẽ không thể rời mắt khỏi màn hình Không những thế, đọc báo điện tử trong thời gian dài có thể gây ra các bệnh về mắt như mỏi mắt, nhược thị, cận thị… Báo nói ra đời nhằm khắc phục những nhược điểm trên mà đồng thời phục vụ đầy đủ những lợi ích mà báo điện tử đem lại Người dùng có thể vừa lái xe, vừa nghe tin tức trên báo điện tử những chuyên mục mình quan tâm: các bạn trẻ có thể cập nhật tin tức sự kiện về các ngôi sao, thần tượng của mình, các xu hướng thời trang, doanh nhân liên tục được cập nhật các tin tức tài chính như cổ phiếu, chứng khoán, người già không cần nhờ con cháu đọc hộ bài báo nào đó khi đã mệt… và còn nhiều trường hợp khác nữa Từ tập người dùng lớn như vậy, nếu ta có thể tận dụng để thương mại hóa bằng cách cho phép các doanh nghiệp, cá nhân đấu giá quảng cáo Dựa vào thói quen cũng như sở thích của người dùng, ta cũng có thể lọc

và đưa ra quảng cáo tới đúng tập khách hàng tiềm năng

Để xây dựng hệ thống đấu giá trực tuyến phục vụ cho hàng triệu người dùng, kiến trúc monolithic truyền thống khó có thể đáp ứng được yêu cầu Với kiến trúc monolithic, phải đảm bảo toàn bộ hệ thống luôn cùng hoạt động, khi một thành phần cần bảo trì hay sửa chữa, cả hệ thống sẽ phải xây dựng và triển khai lại Một

mô hình khác là kiến trúc hướng dịch vụ (SOA - Service Oriented Architecture) cho phép tích hợp các ứng dụ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 SOA nhanh và linh hoạt cho các quy trình nghiệp vụ Các thay đổi về quy trình hoặc ứng dụng sẽ được chuyển đến một thành phần cụ thể mà

được xác nhận trước khi nó được gửi đến dịch vụ Nếu bạn đang sử dụng nhiều dịch

vụ thì nó sẽ làm quá tải hệ thống của bạn với tính toán thêm Kiến trúc microservices ra đời nhằm mục đích khắc phục những nhược điểm trên

Mục đích nghiên cứu của luận văn

Để phục vụ cho người dùng tiếp cận với hình thức quảng cáo trực tuyến, tăng trải nghiệm người dùng, hệ thống sẽ được xây dựng sử dụng kiến trúc microservices Bằng cách tách nhỏ hệ thống ra thành những dịch vụ nhỏ hơn, phục vụ cho mục đích riêng biệt giúp việc tăng quy mô trở nên dễ dàng hơn Về định hướng phát triển, ứng dụng kiến trúc microservices để phát triển toàn bộ hệ thống về cùng một công nghệ để đảm báo tính nhất quán Cung cấp API tới người dùng, phân loại người sử dụng dựa trên các API Gateways

Tóm tắt luận điểm cơ bản và đóng góp mới của tác giả

Các luận điểm cơ bản:

 Tìm hiểu nghiệp vụ đấu giá trực tuyến, cách thức thực hiện

 Thêm hình thức quảng cáo tới người dùng và tăng số lượng tập khách hàng

 Tạo công cụ giúp doanh nghiệp và cá nhân có thể cạnh tranh tiện lợi, công bằng và minh bạch

 Hướng đến một hệ thống thông tin ứng dụng mang tính tổng quát và tinh gọn trong quá trình triển khai

 Ứng dụng MSA tạo ra các ứng dụng trực tuyến mạnh mẽ và có khả năng linh hoạt để mở rộng, dễ xây dựng, triển khai và bảo trì mã nguồn dễ dàng

 Áp dụng các công nghệ mới nhất để phục vụ cho quá trình phát triển sản phẩm, giúp tối ưu hiệu năng

Đóng góp mới của luận văn như sau:

 Luận văn xây dựng dịch vụ ứng dụng hệ thống đấu giá trực tuyến theo mô hình MSA

 Luận văn xây dựng dịch vụ đấu giá theo CQRS pattern để tối ưu hiệu suất, dịch vụ này có thể ứng dụng vào các hệ thống quản lý khác bên ngoài hệ thống quản lý đấu giá quảng cáo trực tuyến

Phương pháp nghiên cứu

Về lý thuyết: thu thập thông tin thông qua đọc các bài báo, tài liệu điện tử, việc tham khảo các tài liệu để có cái nhìn tổng thể, từ đó tổng hợp lại những mối quan hệ giữa các thông tin từ lý thuyết đã thu thập được nhằm mục đích tìm chọn những khái niệm cơ bản làm cơ sở cho đề tài sau đó đưa ra các đối tượng và những thuộc tính của đối tượng nghiên cứu và thiết kế cấu trúc phù hợp với mô hình bài toán ban đầu

Phương pháp mô hình hóa giúp phản ánh những mặt xung quanh đối tượng, mô hình hóa đối tượng nghiên cứu dưới dạng trực quan, xây dựng mô hình các đối tượng nghiên cứu các thông tin về gồm cấu trúc, thuộc tính, chức năng, luồng dữ liệu

Nghiên cứu theo định hướng theo mục đích ứng dụng quản lý dịch vụ đấu giá trực tuyến

CHƯƠNG 1 KHẢO SÁT VÀ PHÂN TÍCH YÊU CẦU HỆ THỐNG

ĐẤU GIÁ TRỰC TUYẾN 1.1 Khảo sát hiện trạng

Hệ thống đấu giá trực tuyến là mô hình mà người dùng tham gia đấu thầu sản phẩm

và dịch vụ Phiên đấu giá này được thực hiện dễ dàng hơn bằng cách sử dụng phần mềm trực tuyến giúp điều chỉnh các quy trình có liên quan Có khá nhiều phương thức hay loại đấu giá khác nhau, và một trong những phương thức phổ biến nhất đó chính là hệ thống đấu giá công khai Hệ thống này đã được thiết kế để có khả năng

mở rộng cao và có khả năng hỗ trợ số lượng lớn các nhà thầu trong một cuộc đấu giá Vì vậy, nó phải luôn luôn ở trong tình trạng sẵn sàng và minh bạch

Hiện nay có khá nhiều hệ thống đấu giá lớn đã và đang rất thành công có thể kể đến như eBay, eBid, Bonanza… Chúng đều có giao diện rất bắt mắt và thu hút người sử dụng Các chức năng có thể kể tới đó là:

 Đăng kí, đăng nhập

 Xem danh sách các món hàng đang được đấu giá

 Tìm kiếm món hàng theo tên, theo danh mục, theo mức giá

 Tham gia đấu giá món hàng

 Đăng kí trở thành người bán hàng

 Đăng bán món hàng

Dựa vào những hệ thống đã thành công kể trên và kết hợp với hệ thống báo nói trực tuyến, hệ thống quản lý đấu giá quảng cáo trực tuyến ra đời nhằm mục đích tận dụng khai thác thêm tập người dùng từ báo nói Báo nói đã và đang phát triển ngày một phổ biến hơn Những ưu điểm khi chuyển sử dụng báo nói thay vì báo viết là rất nhiều Có thể kể đến như giảm tác hại khi nhìn màn hình trong thời gian dài đối với mắt, khi không cần phải tập trung nhìn màn hình, người dùng có thể làm việc khác trong khi vẫn có thể nghe tin tức ưa thích của mình Báo chí từ chỗ chỉ có độc giả, ta đã có thêm thính giả Khi nhu cầu sử dụng báo nói tăng cao, hệ thống có một

hệ thống báo nói Cá nhân và doanh nghiệp có thể đăng ký đấu giá các khung giờ để phát quảng cáo trên báo nói

Hiện nay, hệ thống đấu giá quảng cáo trực tuyến không có nhiều, tại Việt Nam Appota cũng đang phát triển ứng dụng đấu giá trực tuyến thời gian thực hỗ trợ quảng cáo trên Google Ads Hệ thống Admicro chuyên quảng cáo trực tuyến trên các báo lớn như dantri, afamily, kenh14, cafebiz… nhưng hệ thống đấu giá quảng cáo trực tuyến cũng chưa phát triển tới tay người dùng mà vẫn phải thông qua đội

hỗ trợ đặt quảng cáo Thêm vào đó, hệ thống vẫn phát triển theo mô hình một khối nên tốc độ không đáp ứng được nếu đưa tới cho người sử dụng… Tính mở rộng không cao hạn chế lượng người dùng tương tác và trải nghiệm đối với hệ thống, quy trình đăng kí phức tạp, không thân thiện với người dùng, tốn phí dịch vụ Dịch vụ đấu giá trực tuyến ra đời nhằm khắc phục những nhược điểm này Áp dụng kiến trúc microservices, nếu số lượng người dùng tăng đột biến trong một khoảng thời gian, ta có thể dễ dàng mở rộng, tránh trường hợp thời gian đáp ứng chậm hoặc thậm chí bị sập hệ thống

Luận văn sẽ tập trung vào đề xuất xây dựng Dịch vụ đấu giá trực tuyến Phạm vi sẽ

giới hạn trong nghiệp vụ đấu giá theo hệ thống đấu giá Anh Theo Wikipedia quá trình đấu giá của hệ thống đấu giá Anh sẽ diễn ra như sau:

 Một tài sản được bán thông qua đề nghị mở dự thầu hoặc bắt đầu bằng giá được đặt bởi người bán

 Sau đó, nhà đấu giá chấp nhận giá thầu ngày càng cao từ sàn, bao gồm những người mua quan tâm đến mặt hàng Nhà đấu giá thường xác định mức tăng tối thiểu của giá thầu, thường tăng giá khi giá thầu tăng cao

 Người trả giá cao nhất tại bất kỳ thời điểm nào được coi là có giá thầu đứng, chỉ có thể được thay thế bằng giá thầu cao hơn từ người mua cạnh tranh

 Nếu không có nhà thầu cạnh tranh nào thách thức giá thầu đứng trong khung thời gian nhất định, thì người đưa ra giá thầu đứng sẽ trở thành người chiến

 Nếu không có nhà thầu chấp nhận giá khởi điểm, nhà đấu giá sẽ bắt đầu hạ giá khởi điểm dần dần, các nhà thầu được phép trả giá thấp hơn giá khởi điểm, hoặc mặt hàng sẽ không được bán, theo mong muốn của người bán hoặc giao thức của nhà đấu giá

Quá trình này có tính chất cạnh tranh công bằng và có xác suất cao món hàng sẽ được bán Từ nghiệp vụ nói trên, em sẽ tiến hành xây dựng hệ thống quản lý đấu giá trực tuyến mà mặt hàng ở đây là quảng cáo trên báo nói Nói về quảng cáo trên báo nói, mặt hàng này không khác nhiều so với các mặt hàng thông thường, sự khác biệt

rõ nhất đó là đây là mặt hàng phi vật thể, không thể cất giữ cũng như bảo tồn Giá trị của quảng cáo được quyết định bởi khung giờ phát quảng cáo Sau khi thính giả nghe một số lượng bài báo nhất định sẽ phát một đoạn quảng cáo ngắn chèn vào khi chuyển bài báo, có thể bắt buộc (giống với sportify) trong khung giờ được đấu giá Dựa vào thống kê, ta có thể biết khung giờ nào người dùng sử dụng báo nói nhiều nhất, từ đó đưa ra được mức giá sàn hợp lý cho các khung giờ để đấu giá Quản trị thậm chí có thể công khai số liệu này để người dùng nắm được và tự tìm hiểu xem quảng cáo của mình sẽ cần nhắm tới đối tượng người dùng ra sao

Đối tượng áp dụng là cá nhân và doanh nghiệp muốn mở rộng tập khách hàng, quảng bá thông tin tới người sử dụng báo nói

1.2 Tổng quan hệ thống

Quảng cáo trực tuyến cũng giống như các hình thức quảng cáo khác, đều nhắm tới cung cấp thông tin, đẩy nhanh tiến độ giao dịch giữa người mua và người bán Quảng cáo trực tuyến còn có ưu điểm là nó giúp người tiêu dùng có thể tương tác, lấy thống tin chi tiết của sản phẩm cũng như xem nhiều mẫu mã khác bằng cách nhấn vào chi tiết quảng cáo Thậm chí, người dùng còn có thể mua sản phẩm trực tiếp trên website Thêm vào đó, quảng cáo trực tuyến còn tạo cơ hội cho các nhà quảng cáo sản phẩm nhắm chính xác vào tập người dùng tiềm năng

Trong phạm vi luận văn, em sẽ thực hiện luồng nghiệp vụ đơn giản nhất đó là đấu giá công khai Hệ thống sẽ có các đối tượng như sau:

 Quản trị viên

 Người duyệt

 Người dùng (ở đây là khách hàng và doanh nghiệp)

Quản trị viên có chức năng tạo mới, cập nhật, phát hành hoặc đóng phiên đấu giá Mỗi khi phát hành một phiên đấu giá, người dùng có thể biết được thông qua danh sách phiên đấu giá được cập nhật Người dùng từ danh sách nói trên, nếu có khung giờ phù hợp với nhu cầu thì sẽ tham gia đấu giá Lịch sử đấu giá cũng sẽ được cập nhật liên tục tới hệ thống và chuyển đến cho người dùng Một khách hàng sẽ có thể được đấu giá liên tục cho tới khi phiên kết thúc Phiên đấu giá kết thúc khi đến thời gian quy định (do quản trị viên đặt ra) hoặc quản trị viên chủ động đóng phiên giao dịch

Các chức năng cần xây dựng trong hệ thống bao gồm:

 Quản lý khung giờ

 Quản lý phiên đấu giá khung giờ

 Xem danh sách khung giờ

 Đấu giá khung giờ trong phiên đấu giá

1.2.1 Biểu đồ use case tổng quan

Luồng hoạt động của hệ thống từ quản trị viên tạo ra các khung giờ đăng quảng cáo Tiếp theo đó, tạo phiên đấu giá cho khung giờ vừa tạo Người duyệt sẽ là người quyết định phiên đấu giá có được phép public tới người dùng hay không Nếu hợp

lệ, người đó sẽ thay đổi trạng thái phiên sang đã duyệt để đưa tới người dùng Từ danh sách các phiên đã duyệt và có thể tham gia đấu giá, người dùng sẽ quyết định tham gia phiên đấu giá nào và bắt đầu đấu giá cho tới khi phiên kết thúc

Hình 1 Biểu đồ use case tổng quan

Các tác nhân tham gia bao gồm:

 Người dùng: có thể xem và tham gia đấu giá

 Quản trị viên: có nhiệm vụ quản lý phiên đấu giá

 Người duyệt: có quyền thực hiện use case CRUD phiên đấu giá, ngoài ra còn

có quyền thực hiện use case “publish đấu giá” nên có quan hệ extend

1.2.2 Biểu đồ use case phân rã

Biểu đồ use case đấu giá

Biểu đồ hình 2 thể hiện use case người dùng sử dụng hệ thống đấu giá Hệ thống cho phép người dùng có thể xem danh sách các phiên đấu giá Từ danh sách này, có thể xem chi tiết quá trình đấu giá đã và đang diễn ra Người dùng có thể tham gia đấu giá nếu phiên vẫn chưa kết thúc bằng cách nhập giá mình muốn (giá này phải thỏa mãn điều kiện lớn hơn giá lớn nhất của phiên tại thời điểm đó) Chức năng quan trọng nhất ở đây là chức năng đấu giá, cần đảm bảo giá người dùng đưa ra là hợp lệ và thông báo về cho người dùng nếu chưa đúng Tác nhân duy nhất là người dùng, quản trị viên không được phép sử dụng chức năng này

Hình 2 Biểu đồ phân rã use case đấu giá

Kịch bản Use case Danh sách phiên đấu giá

Mã use case UC001 Tên use case Danh sách phiên đấu giá

Tác nhân Người dùng

Tiền điều kiện Người dùng đã đăng nhập

Luồng sự kiện

chính

(Thành công)

STT Thực hiện bởi Hành động

1 Tác nhân Chọn xem danh sách phiên đấu giá

2 Hệ thống Hiện danh sách phiên đấu giá

3 Tác nhân Điền thông tin lọc phiên đấu giá

4 Hệ thống Kiểm tra thông tin được điền vào form

5 Hệ thống Hiện danh sách phiên đấu giá đã lọc

6 Tác nhân Chọn phiên đấu giá

7 Hệ thống Hiện chi tiết phiên đấu giá

Kịch bản Use case đấu giá

Mã use case UC002 Tên use case Đấu giá

1 Tác nhân Chọn nút đấu giá trong chi tiết đấu giá

2 Hệ thống Hiển thị form điền thông tin đấu giá

3 Tác nhân Điền thông tin đấu giá và nhấn lưu

4 Hệ thống Kiểm tra quyền người đăng nhập

5 Hệ thống Kiểm tra thông tin được điền vào form

6 Hệ thống Lưu thông tin giá đấu và cập nhật giá

trong chi tiết đấu giá

7 Hệ thống Quay về màn hình chi tiết đấu giá Luồng sự kiện

thay thế STT Thực hiện bởi Hành động 4a Hệ thống Nếu không phải tác nhân người dùng, hệ

thống sẽ từ chối thực thi và trả về thông báo lỗi

5a Hệ thống Nếu giá điền thấp hơn giá cao nhất trong

phiên đấu giá, hệ thống trả về thông báo lỗi

6a Hệ thống Nếu lưu giá không thành công, trả về

thông báo lỗi Hậu điều kiện Giá đấu được lưu vào cơ sở dữ liệu và thông báo về cho người

dùng

Biểu đồ use case quản lý đấu giá

Quản lý đấu giá cho phép quản trị viên có thể thêm mới, cập nhật và duyệt khung giờ Khung giờ này sẽ được đem ra đấu giá tại các phiên Để làm được như vậy, quản trị viên cần có chức năng tạo, cập nhật phiên đấu giá Chức năng mở phiên đấu giá cho phép phiên đấu giá được phép xuất hiện trong danh sách có thể tham gia đấu giá phía người dùng

Hình 3 Biểu đồ phân rã use case quản lý đấu giá

Phần tiếp theo em sẽ mô tả kịch bản use case Để tránh lan man, em sẽ không đặc tả hai use case CRUD khung giờ và CRUD phiên đấu giá, mà sẽ chỉ đặc tả use case

mở phiên đấu giá

Kịch bản Use case Mở phiên đấu giá

Mã use case UC003 Tên use case Mở phiên đấu giá

Tác nhân Người duyệt

Tiền điều kiện Người duyệt đã đăng nhập

4 Hệ thống Kiểm tra quyền người đăng nhập

5 Hệ thống Lưu hệ thống trạng thái phiên đấu giá đã

6a Hệ thống Nếu hệ thống lưu thất bại, hiển thị thông

báo lỗi

Hậu điều kiện Trạng thái phiên đấu giá được đổi thành đã mở

Biểu đồ use case xem lịch sử đấu giá

Dịch vụ lịch sử đấu giá chứa thông tin tất cả các phiên đấu giá, chi tiết phiên đấu giá bao gồm thông tin người tham gia và giá họ đưa ra Lịch sử đấu giá cá nhân và lịch

sử phiên đấu giá có quan hệ mật thiết với nhau và là quan hệ n-n Hình 4 mô tả mối quan hệ giữa các chức năng trong dịch vụ đối với các tác nhân của hệ thống

Hình 4 Biểu đồ phân rã use case lịch sử đấu giá

Kịch bản Use case Xem lịch sử đấu giá cá nhân

Mã use case UC004 Tên use case Xem lịch sử đấu giá cá nhân

Tác nhân Người dùng

Tiền điều kiện Người dùng đã đăng nhập, là người có tham gia các phiên đấu

giá trong danh sách lịch sử Luồng sự kiện

chính

(Thành công)

STT Thực hiện bởi Hành động

1 Tác nhân Chọn xem lịch sử đấu giá cá nhân

2 Hệ thống Hiện danh sách đấu giá cá nhân

3 Tác nhân Điền thông tin lọc phiên đấu giá

4 Hệ thống Kiểm tra thông tin được điền vào form

5 Hệ thống Hiện danh sách phiên đấu giá đã lọc

Kịch bản Use case Xem lịch sử phiên đấu giá

Mã use case UC005 Tên use case Xem lịch sử phiên đấu giá

Tác nhân Quản trị viên

Tiền điều kiện Quản trị viên đã đăng nhập

Luồng sự kiện

chính

(Thành công)

STT Thực hiện bởi Hành động

1 Tác nhân Chọn xem lịch sử phiên đấu giá

2 Hệ thống Hiện danh sách phiên đấu giá

3 Tác nhân Điền thông tin lọc phiên đấu giá

4 Hệ thống Kiểm tra thông tin được điền vào form

5 Hệ thống Hiện danh sách phiên đấu giá đã lọc

CHƯƠNG 2 KIẾN TRÚC MICROSERVICES VÀ CÁC CÔNG NGHỆ

SỬ DỤNG 2.1 Kiến trúc microservices

2.1.1 Microservices là gì

Đây là loại kiến trúc đang dần trở nên phổ biến trong những năm gần đây nhờ khả năng mô-đun hóa và khả năng mở rộng Kiến trúc microservice có thể cung cấp hầu hết các tính năng của một ứng dụng một khối Ngoài ra, nó cung cấp nhiều tính năng và linh hoạt hơn, do đó nó là sự lựa chọn ưu việt cho ứng dụng phức tạp Không giống như kiến trúc một khối, khá khó để khái quát hóa kiến trúc microservices vì nó có thể thay đổi nhiều tùy thuộc vào trường hợp sử dụng và triển khai

Kiến trúc này được trực quan hóa như hình 5 bên dưới

Hình 5 Kiến trúc microservices

Theo như trang microservices.io, microservice được định nghĩa như sau:

Microservice hay còn được gọi là kiến trúc Microservice là một kiến trúc, cấu trúc một ứng dụng như một tập hợp các dịch vụ [10]

Kiến trúc Microservices cho phép phân phối nhanh chóng, thường xuyên và đáng tin cậy cho các ứng dụng lớn và phức tạp

2.1.2 Đặc điểm của Microservices

Theo như tài liệu tham khảo [13], Microservices có các đặc điểm sau:

 Decoupling - Các dịch vụ trong một hệ thống phần lớn được tách rời Vì

vậy, toàn bộ ứng dụng có thể dễ dàng được xây dựng, thay đổi và thu nhỏ

 Componentization - Microservices được coi là các thành phần độc lập có

thể dễ dàng thay thế và nâng cấp

 Business Capabilities - mỗi một thành phần trong kiến trúc microservice rất

đơn giản và tập trung vào một nhiệm vụ duy nhất

 Autonomy - các lập trình viên hay các nhóm có thể làm việc độc lập với

nhau trong quá trình phát triển

 Continuous Delivery - Cho phép phát hành phần mềm thường xuyên, liên

tục

 Responsibility

 Decentralized Governance - không có mẫu chuẩn hóa hoặc bất kỳ mẫu

công nghệ nào Được tự do lựa chọn các công cụ hữu ích tốt nhất để có thể giải quyết vấn đề

 Agility - microservice hỗ trợ phát triển theo mô hình Agile

2.1.3 Microservices giao tiếp với nhau như thế nào

Trong quá khứ vấn đề giao tiếp giữa các microservices với nhau đã từng là điều đáng lo ngại Khi chúng giao tiếp với nhau mất quá nhiều thời gian và làm ảnh hưởng tới hiệu năng của hệ thống Tuy nhiên vấn đề nào thì cũng có cách giải quyết, các microservices thường giao tiếp với nhau và sử dụng qua phương thức gRPC Các dữ liệu nhị phân được gửi đến các thực thể với tốc độ cực cao, tuy nhiên không phải là nó ko có những vấn đề Hình dưới đây là mô hình giao tiếp thường được sử dụng trong kiến trúc này

Hình 6 Mô hình giao tiếp giữa các Microservice

2.1.4 Ưu và nhược điểm của Microservices

các dịch vụ nhỏ, việc khó có thể làm nếu xây dựng ứng dụng bằng kiến trúc một khối Trên hết với mỗi dịch vụ nhỏ, chúng ta sẽ có thời gian phát triển nhanh hơn,

dễ nắm bắt cũng như bảo trì hơn

Thứ hai, kiến trúc này cho phép việc mỗi dịch vụ được phát triển độc lập bởi những đội phát triển khác nhau Cũng như cho phép nhà phát triển có thể tự do chọn lựa nền tảng công nghệ cho mỗi dịch vụ mình phát triển Dĩ nhiên tự do lựa chọn nhưng không phải là tạo ra một mớ hỗn độn về công nghệ, điều này thì chẳng có một dự án hay sản phẩm nào mong muốn cả Tuy nhiên, sự tự do này có nghĩa là các nhà phát triển không còn phải bắt buộc phải sử dụng các công nghệ lỗi thời có thể đã tồn tại vào lúc bắt đầu dự án Khi viết một dịch vụ mới, họ có tùy chọn của việc sử dụng công nghệ bắt kịp với xu thế Hơn nữa, vì dịch vụ là tương đối nhỏ, việc viết lại một dịch vụ cũ dựa trên nền tảng công nghệ mới hơn là hoàn toàn khả thi

Thứ ba, kiến trúc Microservices cho phép mỗi dịch vụ có thể được triển khai một cách độc lập Cùng với đó thì việc triển khai hệ thống theo kiểu triển khai liên tục là hoàn toàn có thể

Cuối cùng, kiến trúc Microservices cho phép mỗi dịch vụ có thể thực hiện việc tăng quy mô một cách độc lập Bạn có thể tăng quy mô dễ dàng bằng cách tăng số thực thể phục vụ cho mỗi dịch vụ lên và phân tải bằng cân bằng tải (load balancer) Ngoài ra chúng ta cũng có thể tối ưu chi phí vận hành dịch vụ bằng cách triển khai mỗi dịch vụ lên máy chủ có nguồn tài nguyên thích hợp

chậm, lỗi khi thông điệp không gửi được hoặc thông điệp gửi đến nhiều đích đến vào các thời điểm khác nhau

Thứ ba, phải đảm bảo giao dịch phân tán (distributed transaction) cập nhật dữ liệu đúng đắn (all or none) vào nhiều dịch vụ nhỏ khác nhau khó hơn rất nhiều, đôi khi là không thể so với đảm bảo giao dịch cập nhật vào nhiều bảng trong một cơ sở

dữ liệu trung tâm Theo nguyên tắc CAP (CAP theorem) thì giao dịch phân tán sẽ không thể thỏa mãn cả 3 điều kiện: consistency (dữ liệu ở điểm khác nhau trong mạng phải giống nhau), availability (yêu cầu gửi đi phải có phúc đáp), partition tolerance (hệ thống vẫn hoạt động được ngay cả khi mạng bị lỗi) Những công nghệ

cơ sở dữ liệu phi quan hệ (NoSQL) hay môi giới thông điệp (message broker) tốt nhất hiện nay cũng chưa vượt qua nguyên tắc CAP

Thứ tư, kiểm thử một dịch vụ trong kiến trúc microservices đôi khi yêu cầu phải chạy cả các dịch vụ nhỏ khác mà nó phụ thuộc Do đó khi phân rã ứng dụng một khối thành microservices cần luôn kiểm tra mức độ ràng buộc giữa các dịch vụ Nếu các dịch vụ nhỏ thiết kế phục thuộc vào nhau theo chuỗi A gọi B, B gọi C, C gọi D Nếu một mắt xích có giao tiếp API thay đổi, liệu các mắt xích khác có phải thay đổi theo không? Nếu có thì việc bảo trì, kiểm thử sẽ phức tạp tương tự ứng dụng một khối

2.2 CQRS Pattern

2.2.1 Command Pattern

Tham khảo bài viết From CQS to CQRS [20], ý tưởng chính của Command

Pattern là chuyển chúng ta từ data-centric application (ứng dụng tập trung về dữ liệu) sang process-centric application (ứng dụng tập trung vào quy trình)

Trong thực tế, điều này có nghĩa là thay vì có người dùng thực hiện hành động

“CreateUser”, theo sau là một hành động “ActivateUser” và một hành động

“SendUserCreatedEmail”, chúng ta sẽ yêu cầu người dùng thực hiện lệnh

“RegisterUser”, ứng dụng sẽ xử lý bao gồm cả ba hành động như một quy trình

Tuy nhiên, chúng ta nên nhớ rằng điều này không có nghĩa là không thể có command “CreateUser” đơn giản Các trường hợp sử dụng CRUD có thể cùng tồn tại với các trường hợp sử dụng có ý đồ đại diện cho một quy trình nghiệp vụ phức tạp, nhưng điều quan trọng là không nhầm lẫn chúng

Giống như tên gọi của nó, trong pattern này chúng ta sẽ phân chia việc thực hiện

các commands khác nhau Hãy xem Wikipedia nói gì về pattern này:

Command pattern là một behavioral design pattern trong đó một đối tượng được

sử dụng để đại diện và đóng gói tất cả các thông tin cần thiết để gọi một method Thông tin này bao gồm tên method, các đối tượng của method đó và các giá trị cho các tham số của method

Ví dụ, tất cả các Command sẽ có cùng một phương thức execute() để tại một thời điểm nào đó, bất cứ Command nào cũng có thể được kích hoạt mà không cần biết

nó là Command gì Điều này sẽ cho phép các Command được xếp hàng đợi và được thực thi khi có thể, có thể đồng bộ (sync) hoặc bất đồng bộ (async)

Hơn nữa, chúng ta có thể hiện thực hóa theo dạng nhiều command không cần phải được xử lý ngay lập tức, chúng có thể được xếp hàng đợi và thực hiện bất đồng bộ Điều này có một số lợi thế làm cho hệ thống mạnh mẽ hơn:

 Phản hồi cho người dùng được gửi lại nhanh hơn bởi vì chúng ta không xử lý command ngay lập tức

 Nếu vì lỗi hệ thống, giống như một lỗi hoặc CSDL đang ngoại tuyến, một command không thành công, người dùng thậm chí không nhận ra nó Command này chỉ đơn giản có thể được thực thi khi vấn đề được giải quyết Ngoài ra, việc sử dụng command bus còn mang lại một số lợi điểm như chúng ta có thể áp dụng thêm lập trinh hướng khía cạnh (Aspect-oriented programming - AOP)

có thể bao thêm các logic chung trước và / hoặc sau khi xử lý được thực hiện Ví dụ, chúng ta có thể kiểm tra dữ liệu command trước khi chuyển nó tới xử lý, bọc các xử

lý trong transaction logic (commit, rollback) khi làm việc với CSDL transaction, hoặc chúng ta có thể làm cho command bus hỗ trợ việc truy vấn, phân luồng các logic phức tạp và thực thi bất đồng bộ

Cách thông thường mà command bus đạt được là sử dụng mẫu Decorator bao xung quanh command bus (một đối tượng Decorator có thể bao quanh cho một đối tượng Decorator khác)

Hình 7 Mô hình command bus

Điều này cho phép chúng ta tạo ra các Decorators riêng của chúng ta và để cấu hình cho command bus (có thể bên thứ ba) được tạo ra bởi bất kỳ Decorator nào, bất kể thứ tự nào, thêm chức năng tùy chỉnh của chúng ta vào command bus Nếu chúng ta cần quản lý command theo hàng đợi, chúng ta thêm một Decorator để quản lý hàng đợi (queue) của các command Nếu không sử dụng các transaction CSDL thì chúng

ta không cần transaction management Decorator làm gì

2.2.3 CQRS Pattern là gì?

Đây là một pattern được viết tắt bởi Command Query Responsibility Segregation,

dịch nôm na là phân tách vai trò Command (tượng trưng cho việc ghi dữ liệu) và Query (tượng trưng cho việc đọc dữ liệu) CQRS được mô tả lần đầu bởi tác giả Greg Young

Bằng cách kết hợp các khái niệm về CQS, Command, Query và Command Bus,

Về cơ bản, chúng ta có thể nói rằng CQRS là hiện thực hóa (implementation) của nguyên tắc CQS (Command Query Separation principle) trong kiến trúc phần mềm CQRS có thể được thực hiện theo những cách khác nhau và lên đến các cấp độ khác nhau, có thể chỉ có phía Command, hoặc có thể không sử dụng một Command Bus Hình bên dưới là một sơ đồ đại diện cho cách hiện thực của một CQRS đầy đủ:

Hình 8 Mô hình CQRS

Commands

Một Command được bắn ra là cách duy nhất để thay đổi trạng thái của hệ thống Nói cách khác, Commands chịu trách nhiệm cho toàn bộ thay đổi của hệ thống Nếu không có một command nào, điều đó có nghĩa trạng thái của hệ thống sẽ duy trì không đổi Command sẽ không trả về bất kì giá trị nào

Tên của nó luôn sử dụng thì chỉ định, như TerminateBusiness hoặc SendForgottenPasswordEmail Điều rất quan trọng là không nên sử dụng những tên

chung chung như create, change, delete… mà nên thực sự tập trung vào các use

cases

Queries

Query có nhiệm vụ đọc trạng thái của hệ thống, lọc, tổng hợp và biến đổi dữ liệu để cung cấp nó ở định dạng hữu ích nhất Nó có thể được thực thi nhiều lần và sẽ không ảnh hưởng đến trạng thái của hệ thống

Sử dụng các kho dữ liệu khác nhau trong ứng dụng cho các phần command và query dường như là một ý tưởng rất thú vị Như Udi Dahan giải thích rất rõ trong

bài viết của mình “Clarified CQRS”, ta có thể tạo cơ sở dữ liệu hướng giao diện

người dùng, nó sẽ phản ánh những gì ta cần hiển thị cho người dùng của mình, chúng ta sẽ đạt được cả về hiệu suất và tốc độ

Phân tách các kho dữ liệu (một để sửa đổi dữ liệu và một để đọc) không ngụ ý việc

sử dụng cơ sở dữ liệu quan hệ cho cả hai ví dụ Do đó, sẽ tốt hơn nếu sử dụng cơ sở

dữ liệu có thể đọc các truy vấn nhanh chóng

Nếu chúng ta tách các nguồn dữ liệu của mình, làm thế nào chúng ta vẫn có thể làm cho chúng được đồng bộ hóa? Thật vậy, đọc kho dữ liệu không có nhiệm vụ phải biết rằng một command đã được gửi Đây là nơi các sự kiện diễn ra

Events

Event là một thông báo về một sự kiện đã xảy ra Giống như một command, một event phải tôn trọng một quy tắc liên quan đến tên Thật vậy, tên của một event luôn cần phải ở thì quá khứ, bởi vì chúng ta cần thông báo cho các bên khác nghe về sự kiện của chúng ta rằng một command đã được hoàn thành Chẳng hạn, UserRegistered là tên sự kiện hợp lệ Sự kiện được xử lý bởi một hoặc nhiều consumers Những consumers đó chịu trách nhiệm giữ mọi thứ được đồng bộ hóa trong kho truy vấn

2.3 API gateway

Cổng API (API Gateway) có thể coi là một cổng trung gian, nó là cổng vào duy

phía máy khách, chỉnh sửa, xác thực và điều hướng chúng đến các API cụ thể trên các dịch vụ

Hình 9 Mô hình API gateway

Thay vì cung cấp API kiểu một kích cỡ phù hợp cho tất cả, cổng API có thể hiển thị API khác nhau cho mỗi khách hàng Ví dụ: cổng API Netflix chạy mã bộ điều hợp dành riêng cho khách hàng, cung cấp cho mỗi khách hàng một API phù hợp nhất với yêu cầu của nó

Trong hình trên, có ba loại khách hàng: ứng dụng web, ứng dụng di động và ứng dụng bên thứ 3 bên ngoài Có ba cổng API khác nhau Mỗi loại cung cấp một API cho khách hàng của mình

Ngoài nhiệm vụ chính là yêu cầu ủy quyền (proxy request) thì một hệ thống cổng API thường sẽ đảm nhận luôn vài vai trò khác như bảo mật API, giám sát, phân tích

Sử dụng cổng API có các lợi ích sau:

 Cách ly khách hàng khỏi cách ứng dụng được phân vùng thành microservices

 Cách ly khách hàng khỏi vấn đề xác định vị trí của các dịch vụ

 Cung cấp API tối ưu cho từng khách hàng

 Giảm số lượng yêu cầu / một chuyến đi khứ hồi (roundtrips) Ví dụ: cổng API cho phép khách hàng truy xuất dữ liệu từ nhiều dịch vụ với một chuyến

đi khứ hồi Ít yêu cầu hơn cũng có nghĩa là ít chi phí hơn và cải thiện trải nghiệm người dùng Cổng API rất cần thiết cho các ứng dụng di động

 Đơn giản hóa máy khách bằng cách di chuyển logic để gọi nhiều dịch vụ từ máy khách đến cổng API

 Dịch từ một giao thức API thân thiện với web công cộng của tiêu chuẩn thành một bất kỳ giao thức nào được sử dụng trong nội bộ

Cổng API cũng có một số nhược điểm:

 Độ phức tạp tăng lên - cổng API là một phần khác phải được phát triển, triển khai và quản lý

 Thời gian phản hồi tăng lên do bước nhảy mạng bổ sung thông qua cổng API

- tuy nhiên, đối với hầu hết các ứng dụng, chi phí cho một vòng tròn thêm là không đáng kể

thức ngôn ngữ Golang là http://golang.org/ Ngôn ngữ Golang có một hình thái và ngữ nghĩa lập trình riêng giúp nó đảm bảo hiệu suất làm việc mà vẫn mang lại những điều thú vị khi viết mã code Golang cũng cung cấp một bộ thư viện chuẩn khá toàn diện Thư viện chuẩn cung cấp tất cả các gói lập trình viên cốt lõi cần để xây dựng các chương trình, phần mềm hay cả ứng dụng web và ứng dụng quản trị mạng Golang cũng là một ngôn ngữ lập trình đồng bộ, được biên dịch có cú pháp khá cơ bản chủ yếu thuộc về họ ngôn ngữ C

Ngôn ngữ lập trình Golang thực chất là một dự án mã nguồn mở được phát hành dựa trên chứng chỉ BSD nhằm mục đích nâng cao hiệu suất làm việc dành cho các lập trình viên Golang có cú pháp khá ngắn gọn, sạch sẽ và hiệu quả Go được biên dịch nhanh chóng sang mã máy nhưng vẫn có sự tiện lợi trong việc quản lý bộ nhớ cũng như hoạt động run-time Có thể nói Golang là một ngôn ngữ lập trình được biên dịch tĩnh rất nhanh, cảm thấy giống như một ngôn ngữ kịch bản được biên dịch động [15]

Đặc điểm của Golang

Golang là ngôn ngữ biên dịch, và giống như nhiều ngôn ngữ lập trình khác, nó sử

dụng khá nhiều dòng lệnh Go đồng thời là tên của ngôn ngữ lập trình và tên của bộ công cụ được sử dụng để xây dựng và tương tác với các chương trình được viết bởi

Go – Golang

Khác với Python hay Javascript, ta cần khai báo kiểu dữ liệu cho các giá trị biến (variables) trong Golang Trình biên dịch biết thông tin kiểu dữ liệu trước giúp đảm bảo rằng chương trình đang làm việc với các giá trị một cách an toàn Điều này giúp giảm thiểu các lỗi và lỗi bộ nhớ tiềm ẩn, đồng thời cung cấp cho trình biên dịch cơ hội tạo ra nhiều mã thực hiện hơn Đồng thời Golang cũng cung cấp struct cho phép bạn tạo các kiểu của riêng mình bằng cách kết hợp một hoặc nhiều loại, bao gồm cả các kiểu được xây dựng sẵn và do người dùng định nghĩa Structs là cách duy nhất

để tạo các kiểu dữ liệu do người dùng định tự nghĩa trong Golang Khi tạo các kiểu

các kiểu cho phép bạn tạo các kiểu dữ liệu lớn hơn bằng cách kết hợp các kiểu nhỏ hơn Triết lý thiết kế của Golang là tạo ra các thành phần lớn hơn bằng cách kết hợp các thành phần nhỏ và mô-đun hóa Nếu bạn là một lập trình viên thực dụng, bạn sẽ đánh giá cao triết lý thiết kế của Golang bởi việc kế thừa kiểu dữ liệu đôi khi đưa ra những thách thức thực tế liên quan đến khả năng bảo trì

Trong thập kỷ qua, phần cứng máy tính đã phát triển mạnh mẽ giúp gia tăng số lõi cũng như nâng cao đột phá sức mạnh của CPU Ngày nay, chúng ta sử dụng nhiều nền tảng đám mây để xây dựng và chạy các ứng dụng, vì vậy các máy chủ trên đám mây có nhiều sức mạnh và quyền lực hơn Mặc dù vậy, chúng ta vẫn chưa thể tận dụng được toàn bộ sức mạnh của chúng dựa trên hầu hết các ngôn ngữ và công cụ lập trình hiện có

Ngôn ngữ lập trình Golang ra đời cung cấp khả năng thực thi các chức năng độc lập với nhau Các cơ chế đồng thời của nó giúp dễ dàng viết các chương trình tận dụng tối các “lõi” trên CPU cũng như sức mạnh từ mạng máy tính Trong hệ thống kiểu mới của nó cho phép xây dựng chương trình linh hoạt và mô đun hóa Một function được tạo được quản lý như một goroutine (một luồng thực thi – thread – được quản

lý bởi Go - runtime), nó được coi là một đơn vị công việc độc lập, được lên lịch và sau đó được thực thi trên một bộ xử lý logic có sẵn Các Goroutine được tạo ra bằng cách gọi câu lệnh Go theo sau bởi hàm hoặc phương thức mà bạn muốn chạy như một hoạt động tự điều hành Bộ lập lịch thời gian chạy Go là một phần mềm phức tạp quản lý tất cả các goroutine được tạo và cần thời gian xử lý Trình lập lịch biểu nằm trên đầu của hệ điều hành, ràng buộc các luồng của hệ điều hành tới các bộ xử

lý logic mà khi đến lượt, nó sẽ tiến hành việc thực thi các goroutine Bộ lập lịch kiểm soát tất cả mọi thứ liên quan đến các goroutine đang chạy trên đó bộ vi xử lý logic tại bất kỳ thời điểm nào

Các lĩnh vực ứng dụng của Golang

Với đặc điểm của mình, Golang có thể ứng dụng trong nhiều lĩnh vực, như trong phát triển Web Backend, phát triển ứng dụng di động (với vai trò máy chủ), trong

Đối với phát triển máy chủ web, Golang mang lại nhiều lợi ích so với Python hay Java như:

 Golang thật sự đơn giản và dễ tiếp cận với cả các lập trình viên hay tester

 Sử dụng các thuật toán biên dịch nâng cao, với Golang, chúng ta sẽ không cần cài đặt các dependencies từ máy chủ bởi vì Go đã liên kết tất cả các mô-đun cũng như các thành phần liên quan (dependencies) thành một tệp nhị phân

 Golang sử dụng các goroutine riêng biệt giúp tiết kiệm bộ nhớ và nâng cao hiệu năng cho ứng dụng

Có thể nói, Golang đang phát triển rất nhanh, tốc độ ngày một tăng cao, tiếp cận dễ dàng, các phương thức bảo mật được cải thiện mạnh mẽ giúp nó ngày càng trở nên chiếm ưu thế hơn

2.4.2 Hệ thống thông điệp NATS

Tầm quan trọng của messaging

Phát triển và triển khai các ứng dụng và dịch vụ giao tiếp trong các hệ thống phân tán có thể phức tạp và khó khăn Tuy nhiên, có hai mẫu cơ bản, yêu cầu / phản hồi hoặc RPC cho các dịch vụ và luồng dữ liệu và sự kiện Một công nghệ hiện đại sẽ cung cấp các tính năng để làm cho điều này dễ dàng hơn, có thể mở rộng, an toàn, độc lập với vị trí và có thể quan sát được

Nhu cầu của điện toán phân tán ngày nay

Một hệ thống nhắn tin hiện đại cần hỗ trợ nhiều mẫu liên lạc, mặc định được bảo mật, hỗ trợ nhiều chất lượng dịch vụ và cung cấp nhiều dịch vụ bảo mật cho cơ sở

hạ tầng chia sẻ thực sự Một hệ thống hiện đại cần bao gồm:

 Bảo mật bằng thông tin liên lạc mặc định cho microservice, nền tảng và thiết

bị cạnh