đồ án 1 xây dựng hệ thống với spring boot

Tóm tắt đồ án Thiết kế hệ thống với các định nghĩa các thành phần và cách tích hợp chúng, các giao diện lập trình ứng dụng APIs, và mô hình dữ liệu data model để xây dựng kiến trúc Micro

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN KHOA CÔNG NGHỆ PHẦN MỀM

ĐỒ ÁN MÔN HỌC

ĐỒ ÁN 1

XÂY DỰNG HỆ THỐNG VỚI SPRING BOOT

Giảng viên hướng dẫn : ThS Nguyễn Công Hoan Sinh viên thực hiện 1 : Nguyễn Văn Quốc Tuấn Mã sinh viên 1 : 21522758

Sinh viên thực hiện 2 : Trần Phước Long Mã sinh viên 2 : 21521103

Tp.HCM, tháng 12 năm 2023

LỜI CẢM ƠN

Chúng em xin gửi lời cảm ơn chân thành đến Thầy Ths.Nguyễn Công Hoan về sự hướng dẫn và hỗ trợ quý báu của Thầy trong quá trình thực hiện đồ án 1 của mình tại khoa Công nghệ Phần mềm Những kiến thức và kỹ năng mà chúng em đã học được từ Thầy không chỉ giúp chúng em hoàn thành đồ án mà còn mở rộng tầm nhìn và sâu rộng hiểu biết của chúng em về lĩnh vực này Sự hỗ trợ và sự chỉ dẫn chi tiết từ Thầy không chỉ là nguồn động viên lớn mà còn giúp chúng em vượt qua những thách thức nghiên cứu khoa học và phát triển bản thân mình Với điều kiện về thời gian cũng như lượng kiến thức về đề tài rất rộng mà kinh nghiệm còn hạn chế của một học viên, đồ án này không thể tránh được những thiếu sót Chúng em rất mong nhận được sự chỉ bảo, đóng góp ý kiến của thầy để chúng em có điều kiện bổ sung, nâng cao kiến thức của mình, phục vụ tốt hơn công tác thực tế sau này

Sinh viên thực hiện

Nguyễn Văn Quốc Tuấn - Trần Phước Long

NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN

2.2.6.Tính hồi phục – Fault Tolerance 10

a Các khái niệm về tính hồi phục 10

b Sao chép 11

c Lỗi Byzantine 11

Chương 3: BỘ CÂN BẰNG TẢI 14

3.1 Khái niệm bộ cân bằng tải 14

3.2 Phân loại bộ cân bằng tải 15

3.3 Các thuật toán 16

3.4 Triển khai bộ cân bằng tải 16

3.4.1.Bộ cân bằng tải phần cứng 16

3.4.2.Bộ cân bằng tải phần mềm 18

3.5 Các loại mẫu triển khai 18

Chương 4: CƠ SỞ DỮ LIỆU 20

4.1 Tổng quan về cơ sở dữ liệu 20

4.2 Các loại cơ sở dữ liệu 20

4.2.1.Cơ sở dữ liệu quan hệ 20

4.2.2.Cơ sở dữ liệu không quan hệ 21

a Cơ sở dữ liệu “key-value” 22

b Cơ sở dữ liệu “document” 23

c Cơ sở dữ liệu “Graph” 23

d Cơ sở dữ liệu cột “Columnar” 24

5.2.2.Xử lý lỗi người tham gia 29

5.2.3.Tính chặn (Blocking) trong giao thức 2PC 30

5.3 Xác nhận 3 pha “3-Phase Commit” 31

Chương 7: SERVICE DISCOVERY & API GATEWAY 48

7.1 Tổng quan về Service Discovery 48

7.2 Phân loại Service Discovery 48

7.2.1.Client side Service Discovery 48

7.2.2.Server side Service Discovery 49

7.3 Phân loại hình thức đăng ký 50

b Khóa phân phối 56

c Truyền tải nguyên tử 56

8.2 Thuật toán Raft 56

8.2.1.Khái quát về Raft 56

a Trạng thái nút (Node states) 57

b Nhiệm kỳ (terms) 57

8.2.2.Giao tiếp giữa các nút Raft 58

a Cơ chế giao tiếp 58

b Sự phân kỳ giữa các nút 60

c Giải quyết sự phân kỳ 61

8.3 Ưu và nhược điểm của Raft 62

Chương 9: DEPLOYMENT 63

9.1 Các vấn đề khi triển khai một hệ thống 63

9.2 Các mẫu triển khai 63

9.2.1.Multiple Service Instances per Host 63

9.2.2.Single Service Instance per Host 64

9.4 Kubernetes & Helm 68

9.4.1.Tổng quan về Kubernetes 68

9.4.2.Tổng quan về Helm 70

Chương 10: THIẾT KẾ VÀ XÂY DỰNG HỆ THỐNG SPRING BOOT 71

10.1 Tổng quan về Spring 71

10.1.1 Tổng quan về Spring Boot 71

10.1.2 Các tính năng chính của Spring Boot 71

10.1.3 Kiến trúc của Spring Boot 72

10.2 Spring Boot starter 73

10.3 Spring Data JPA 74

10.4 Spring Config Server 74

10.5 Spring Boot với Eureka 76

10.6 Sping Cloud Gateway 77

10.7 Spring Boot Cache 80

10.8 Spring Boot Actuator 81

10.9 Spring Boot Security, OAuth2, JWT 82

10.9.1 Spring Boot Security 82

10.9.2 OAuth2 83

10.9.3 JWT 84

10.10 Spring Cloud Resilience4j 85

10.11 Spring Boot với Feign 86

10.12 Spring Boot với docker 86

Chương 11: DEMO VÀ TỔNG KẾT 88

11.1 Demo 88

11.2 Tổng kết 88

11.3 Hướng dẫn cài đặt và chạy ứng dụng 94TÀI LIỆU THAM KHẢO 95

MỤC LỤC HÌNH ẢNH

Hình 2.1: Thiết kế hệ thống 3

Hình 2.2: Minh họa mở rộng theo chiều dọc và ngang 5

Hình 2.3: Bảng mức độ khả dụng 6

Hình 2.4: Công thức tính các thông số đo lường 7

Hình 2.5: Biểu đồ phụ thuộc giữa tính khả dụng và tính tin tưởng 8

Hình 2.6: Công thức tính toán thời gian trung bình để sữa chửa 9

Hình 2.7: Nguyên lý CAP 10

Hình 2.8: Kĩ thuật sao chép 11

Hình 2.9: Vấn đề các vị tướng Byzantine 12

Hình 2.10: Không có cách để biết được trong số các tướng khác ai là người phản bội 13

Hình 3.1: Cách bộ cân bằng tải hoạt động 14

Hình 3.2: Cách sử dụng khả thi cân bằng tải trong cấu trúc 3 lớp 15

Hình 3.3: Bộ cân bằng tải phần cứng 17

Hình 3.4: Bộ cân bằng tải phần mềm 18

Hình 4.1: Cơ sở dữ liệu quan hệ và không quan hệ 20

Hình 4.2: Các loại cơ sở dữ liệu không quan hệ 22

Hình 4.3: Dữ liệu được lưu trữ dưới dạng cặp khóa-giá trị trong DynamoDB, trong đó khóa chính bao gồm hai thuộc tính (Product ID và Type) 22

Hình 4.4: Một dạng file JSON chứa dữ liệu của người dùng 23

Hình 4.5: Một đồ thị bao gồm các nút và liên kết Đồ thị này ghi lại các thực thể và mối quan hệ giữa chúng 24

Hình 4.6: Cơ sở dữ liệu hàng và cột 25

Hình 5.1: Minh họa 2PC 27

Hình 5.2: Coordinator rollback transaction sau khi nhận thấy một server không chuẩn bị

Hình 5.7: Một saga bao gồm 4 local transaction nối tiếp nhau 34

Hình 5.8: Thực hiện Saga dựa trên phương pháp Choreography 35

Hình 5.9: Thực hiện Saga dựa trên phương pháp Orchestrator 36

Hình 5.10: Transaction log tailing 37

Hình 5.11: Polling publisher 38

Hình 5.12: Lưu trữ database thông thường so với kiến trúc Event sourcing 38

Hình 6.1: Cache ở nhiều vị trí trong hệ thống 40

Hình 6.7: Mô hình Write-around Cache 47

Hình 7.1: Ảnh minh họa Client side Service Discovery 49

Hình 7.2: Mô hình minh hoa về service discovery server side 50

Hình 7.3: Minh họa Self-registration 51

Hình 7.4: Minh họa Self-registration 52

Hình 7.5: Mô hình API Gateway 53

Hình 7.6: Mô hình tổng quát Client resilience 54

Hình 8.1: Minh họa Consensus 55

Hình 8.2: Trạng thái các nút trong Raft 57

Hình 8.3: Cấu trúc của Replicated log 59

Hình 8.4: Sự phân kỳ tạm thời của các node logs 60

Hình 9.1 Mô hình mẫu Multiple Service Instances per Host 64

Hình 9.2 Mô hình mẫu Single Service Instance per Virtual Machine 65

Hình 9.3 Mô hình mẫu Single Service Instance per Container 66

Hình 9.4 Kiến trúc Cluster Kubernetes 69

Hình 10.1: Kiến trúc Spring Boot 72

Hình 10.2: Dependency Spring Starter Data JPA 73

Hình 10.3: Các Dependency starter được thêm vào trong maven tab 74

Hình 10.4 : Dependency của Spring Data JPA 74

Hình 10.5: Dependency “spring-cloud-config-server” 75

Hình 10.6: Đặt @EnableConfigServer 76

Hình 10.7: Ví dụ minh họa về cấu hình file yml cho ConfigServer 76

Hình 10.8: Dependency “spring-cloud-starter-netflix-eureka-server” 77

Hình 10.9: Khai báo Eureka Server bằng chú thích @EnableEurekaServer 77

Hình 10.10: Kiến trúc của Spring Cloud Gateway 79

Hình 10.11: Dependency của Spring Cloud Gateway 80

Hình 10.12: Dependency để khai báo Sping Cache 81

Hình 10.13: Dependency “spring-boot-starter-actuator” 82

Hình 10.14: Dependency “spring-boot-starter-security” 83

Hình 10.15: Thêm annotation @EnableWebSecurity 83

Hình 10.16: Dependency “spring-boot-start-oauth2-client” 84

Hình 10.17: Thêm annotation @EnableOAuth2Client 84

Hình 10.18: Dependency “jjwt” 85

Hình 10.19: Dependency của Spring Cloud Resilience4j 86

Hình 10.20: Dependency của Spring Cloud OpenFeign 86

Hình 10.21: Dependency “spring-boot-starter-docker” 87

Hình 11.1: Tổng quan hệ thống 89

Hình 11.2: Activity diagram mô tả quá trình đặt đơn hàng 90

Hình 11.3: Activity diagram mô tả quá trình thanh toán 91

Hình 11.4: Zipkin Dashboard khi các service được khởi tạo 92

Hình 11.5: Zipkin Dashboard khi thực hiện tạo đơn hàng 92

Hình 11.6: Zipkin Dashboard khi thực hiện thanh toán 92

Hình 11.7: Theo dõi trạng thái thông qua Prometheus 93

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

Spring Boot là sự lựa chọn phù hợp để xây dựng các mô hình hệ thống vì độ phổ biến rộng rãi trong cộng đồng phát triển phần mềm Nền tảng mạnh mẽ và linh hoạt của Spring Boot giúp tối ưu hiệu suất, dễ dàng triển khai ứng dụng và cung cấp công cụ hỗ trợ đáng tin cậy Khả năng học hỏi liên tục từ cộng đồng và tiềm năng việc làm cao làm cho việc nghiên cứu và áp dụng Spring Boot mang lại lợi ích lớn, đặc biệt là khi cung cấp kiến thức và kỹ năng cần thiết cho ngành công nghiệp công nghệ thông tin ngày càng đòi hỏi

1.2 Mục tiêu và phạm vi nghiên cứu

Mục tiêu:

- Nắm rõ cấu trúc, kiến thức về các thành phần trong Spring Boot

- Xây dựng ứng dụng đơn giản áp dụng kiến trúc Microservice với Spring Boot Phạm vi:

- Tìm hiểu các thành phần trong Spring Boot

- Tìm hiểu và phân tích các thành phần của kiến trúc Microservice

1.3 Tóm tắt đồ án

Thiết kế hệ thống với các định nghĩa các thành phần và cách tích hợp chúng, các giao diện lập trình ứng dụng (APIs), và mô hình dữ liệu (data model) để xây dựng kiến trúc Microservice đáp ứng các yêu cầu về chức năng và phi chức năng

Xây dựng ứng dụng áp dụng kiến trúc Microservice có độ tin cậy (reliable), hiệu quả, và dễ bảo trì cùng với những đặc điểm khác

1.4 Bố cục báo cáo

Phần còn lại của báo cáo được trình bày theo bố cục sau:

Chương 2 – Thiết kế hệ thống Chương 3 – Bộ cân bằng tải Chương 4 – Cơ sở dữ liệu Chương 5 – Giao dịch phân tán

- Hệ thống đáng tin cậy là hệ thống có khả năng xử lý lỗi, sự cố và sai sót

- Hệ thống dễ bảo trì là hệ thống linh hoạt và dễ dàng mở rộng hoặc thu nhỏ Khả năng thêm tính năng mới cũng nằm trong phạm vi của tính dễ bảo trì

2.2 Các nguyên lý thiết kế hệ thống 2.2.1 Tính mở rộng – Scalability

4 Scalability là khả năng mở rộng của hệ thống quy trình hay mạng lưới với nhu cầu gia tăng về số lượng công việc tăng theo thời gian của mô hình kinh doanh

Mô hình kinh doanh có thể mở rộng quy mô vì nhiều lý do như: - Gia tăng khối lượng dữ liệu lưu trữ

- Gia tăng về số lượng yêu cầu và khối lượng công việc

Ví dụ: số lượng truy cập hay đặt hàng của một hệ thống thương mại điện tử Và yêu cầu của sự mở rộng phải đạt được nhu cầu này mà không làm giảm hiệu suất, nói chung Scalability là đáp ứng được sử mở rộng hay giảm theo kích thước của hệ thống theo thời gian

Có hai dạng scaling là mở rộng theo chiều ngang (vertical scaling) và mở rộng theo chiều dọc (horizontal scaling)

- Tính mở rộng theo chiều dọc (Vertical scaling/ Scaling Up): là cách mở rộng

server hiện tại bằng cách nâng cấp độ mạnh (power) bằng cách nâng cấp CPU, Ram, Storage, v.v… Vertical-scaling cho phép chúng ta mở rộng năng xuất của phần cứng và phần mềm, nhưng thường bị giới hạn bởi giới hạn về cấu hình vật lý hiện đại hay độ trễ khi “chẳng may” Server bị downtime để nâng cấp hay triển khai hệ thống Chi phí cho việc vertical scaling thường đắt đỏ

- Tính mở rộng theo chiều ngang (Horizontal Scalability/ Scaling Out): Horizontal

scalability là một phương pháp mở rộng hệ thống bằng cách tăng số lượng máy chủ hoặc nodes trong mạng Nó còn được gọi là "scaling out." Phương pháp này đối phó với việc gia tăng tải lên hệ thống bằng cách thêm nhiều máy chủ hoặc nodes khác nhau vào mạng Horizontal scalability tập trung vào việc mở rộng hệ thống mà không cần tăng cường cấu trúc của máy chủ hiện tại

5

Hình 2.2: Minh họa mở rộng theo chiều dọc và ngang

Song, horizontal scaling cũng phức tạp hóa mô hình kiến trúc của hệ thống do phải điều phối hoạt động của nhiều server riêng biệt và vận hành như một bộ máy duy nhất Kiến trúc này được biết đến với tên gọi Hệ thống phân tán (Distributed system) và là cơ sở cho ra đời một họ các mô hình kiến trúc sau này như Distributed monolith, Microservices, cùng với đó là rất nhiều vấn đề cực kỳ phức tạp và khó giải quyết khác

Khi nhắc đến scalability, hầu hết ta luôn muốn nói đến khả năng horizontal scaling của hệ thống

2.2.2 Tính khả dụng – Availability

Tính khả dụng là một chỉ số đo lường phần trăm thời gian mà một dịch vụ hoặc một hệ thống nào đó có thể truy cập được bởi khách hàng và hoạt động trong điều kiện bình thường Nó đo lường mức độ hoạt động và xử lý của hệ thống ở trạng thái bình thường trong suốt một khoảng thời gian nhất định Chẳng hạn, nếu một dịch vụ có khả dụng 100%, điều đó có nghĩa rằng dịch vụ đó luôn sẵn sàng hoạt động, xử lý và phản hồi các yêu cầu

Cách tính toán tính khả dụng

Trong toán học, tính khả dụng A được biểu thức dưới dạng tỉ lệ Tỉ lệ A càng cao càng tốt Chúng ta cũng có thể biểu thức điều này bằng một công thức:

6 Chúng ta đo lường mức độ khả dụng (availability) bằng cách sử dụng số lượng "9" Cụ thể, số lượng "9" thể hiện mức độ chính xác của khả dụng và cho biết bao nhiêu thời gian ngừng hoạt động được phép trong khoảng thời gian nhất định

Dưới đây là một bảng thể hiện mức độ khả dụng tương ứng với số lượng "9" và thời gian ngừng hoạt động được phép:

Hình 2.3: Bảng mức độ khả dụng

2.2.3 Tính tin cậy – Reliability

Độ tin cậy đề cập đến khả năng của dịch vụ hoặc hệ thống thực hiện các chức năng của nó trong một khoảng thời gian cụ thể mà không gặp sự cố hoặc gián đoạn Điều này có nghĩa rằng độ tin cậy đo lường xem dịch vụ hoạt động đáng tin cậy như thế nào dưới các điều kiện hoạt động khác nhau

Chúng ta thường sử dụng MTBF và MTTR như một thông số để đo lường độ tin cậy

7

Hình 2.4: Công thức tính các thông số đo lường

Một hệ thống có độ tin cậy cao khi có giá trị MTBF cao và MTTR thấp

Độ tin cậy và tính sẵn sàng là hai chỉ số quan trọng để đo lường sự tuân thủ của dịch vụ dựa trên Service Level Objectives - SLO

Đo lường tính khả dụng (availability) dựa vào thời gian mất mát, trong khi tần suất và tác động của các sự cố dùng để đo lường tính đáng tin cậy (reliability) Cả tính sẵn sàng và tính đáng tin cậy đều quan trọng vì chúng cho phép các bên liên quan đánh giá tình trạng và khả năng hoạt động của dịch vụ

Độ tin cậy (Reliability - R) và tính khả dụng (Availability - A) là hai khái niệm riêng biệt, nhưng chúng có mối quan hệ Trong toán học, tính sẵn sàng (A) là một hàm số của độ tin cậy (R) Điều này có nghĩa rằng giá trị của R có thể thay đổi độc lập và giá trị của A phụ thuộc vào R Do đó, có thể xảy ra tình huống mà:

- A thấp, R thấp - A thấp, R cao - A cao, R thấp

- A cao, R cao (mong muốn)

8

Hình 2.5: Biểu đồ phụ thuộc giữa tính khả dụng và tính tin tưởng

2.2.4 Tính bảo trì – Maintainability

Tính bảo trì (Maintainability), ký hiệu là M, là xác suất mà dịch vụ sẽ khôi phục lại các

chức năng của nó trong một khoảng thời gian cụ thể sau khi xảy ra lỗi M đo đo lường khả

năng của dịch vụ làm cho mình trở lại tình trạng hoạt động bình thường một cách thuận tiện và nhanh chóng

Khả năng bảo trì mang lại cho chúng ta cái nhìn về khả năng của hệ thống để trải qua quá trình sửa chữa và chỉnh sửa trong khi nó đang hoạt động

Ví dụ, giả sử một thành phần có giá trị bảo trì được xác định là 95% trong vòng nửa giờ Trong trường hợp này, xác suất khôi phục thành phần về trạng thái hoạt động hoàn toàn trong nửa giờ là 0,95

Chúng ta sử dụng mean time to repair (MTTR) như là chỉ số để đo lường M

- Total Number of Repairs: Tổng số lượng sửa chữa

Nói cách khác, MTTR là thời gian trung bình cần thiết để sửa chữa và khôi phục một thành phần bị lỗi Mục tiêu của chúng ta là có giá trị MTTR thấp nhất có thể

2.2.5 Tính nhất quán – Consistency

Tính nhất quán (Consistency) là một thuộc tính quan trọng trong hệ thống phân tán, đảm

bảo rằng tất cả các máy chủ (server) trong cụm (cluster) luôn duy trì cùng một trạng thái và dữ liệu vào một thời điểm cố định, bất kể client nào đã thực hiện cập nhật dữ liệu

Tính nhất quán cao có nghĩa là hệ thống phân tán sẽ đồng thuận đến một trạng thái duy nhất và cho phép client luôn đọc được dữ liệu mới nhất

Tính nhất quán của hệ thống phụ thuộc vào việc nó tuân theo định lý CAP – định lý nêu rằng một hệ thống phân tán (distributed system) không thể thỏa mãn cả ba yếu tố CAP:

- Consistency: Tính nhất quán, các máy chủ trong một hệ thống phải có dữ liệu đồng

nhất

- Availability: Khả năng sẵn sàng, hệ thống vẫn hoạt động được khi một số máy chủ

bị chết hoặc không sẵn sàng

- Partition Tolerance: Khả năng chịu đựng phân vùng, hệ thống vẫn hoạt động cho

dù kết nối giữa các máy chủ trong hệ thống bị đứt

Nói cách khác, khi mạng bị phân vùng (network partition), thì một hệ thống chỉ có thể đảm bảo được một trong hai tính chất - Consistency hoặc Availability Khi không có phân vùng mạng, thì hệ thống có thể đảm bảo cả hai tính chất

- Node fault: sự cố tại một server node

o Crash-stop: server sập và dừng hoàn toàn, không hồi phục o Crash-recovery: server sập và sau đó hồi phục trở lại

o Byzantine fault: server gặp sự cố và hoạt động không theo chương trình, xử lý một cách ngẫu nhiên, không đáng tin cậy Byzantine fault có thể do trục trặc trong các thiết bị điện tử chứ không nhất thiết phải do sự can thiệp của tác nhân

có ý đồ xấu

- Network fault: sự cố về đường truyền, kết nối mạng, chẳng hạn như message bị

mất hoặc delay, tắc nghẽn,

11 Fault tolerance: khả năng chống fault - hệ thống vẫn tiếp tục hoạt động khi có fault (số

lượng fault dưới một ngưỡng tối đa)

Single point of failure: khi fault ở một node dẫn tới failure trên toàn hệ thống Có các kĩ thuật về tình hồi phục:

b Sao chép

Một trong những kỹ thuật được sử dụng rộng rãi nhất trong việc đảm bảo tính hồi phục dựa trên sao chép Với kỹ thuật này, chúng ta có thể sao chép cả dịch vụ và dữ liệu Chúng ta có thể thay thế các node bị lỗi bằng những node sẵn sàng và kho lưu trữ dữ liệu bị lỗi bằng bản sao của nó Một dịch vụ lớn có thể thực hiện việc chuyển đổi mà không ảnh hưởng đến khách hàng cuối

Chúng ta tạo nhiều bản sao của dữ liệu trong lưu trữ riêng biệt Tất cả các bản sao cần được cập nhật thường xuyên để đảm bảo tính nhất quán khi có bất kỳ cập nhật nào xảy ra trong dữ liệu Việc cập nhật dữ liệu trong các bản sao là một công việc thách thức Khi một hệ thống cần độ tin cậy cao, chúng ta có thể cập nhật dữ liệu trong các bản sao một cách đồng bộ Tuy nhiên, điều này giảm tính sẵn sàng của hệ thống

Hình 2.8: Kĩ thuật sao chép

c Lỗi Byzantine

12

Lỗi Byzantine (Byzantine fault), hay còn gọi là Vấn đề các vị tướng Byzantine, là một

tình trạng của một hệ thống, đặc biệt là hệ thống phân tán, trong đó các thành phần có thể bị lỗi và không có thông tin chính xác về việc liệu thành phần đó có bị lỗi hay không Thuật ngữ này lấy tên từ một câu chuyện ngụ ngôn, "Vấn đề các vị tướng Byzantine", được phát triển để mô tả một tình huống trong đó, để tránh sự sụp đổ của hệ thống, các tác nhân của hệ thống phải đồng ý về một chiến lược phối hợp, nhưng một số tác nhân này là không đáng tin cậy

Hình 2.9: Vấn đề các vị tướng Byzantine

Một server trong một cluster có thể bị lỗi vì nhiều lý do, mà khiến cho server hoạt động không đúng theo chương trình, lệch khỏi chương trình, khiến cho mọi phản hồi từ server này trở nên không đáng tin cậy

Không có cách nhất định để phát hiện lỗi Byzantine, do các server bị lỗi hoàn toàn có thể phản hồi lại các yêu cầu một cách bình thường nhưng thực chất không thực hiện yêu cầu theo đúng chương trình Node bị lỗi còn có thể phản hồi thông tin khác nhau với mỗi thiết bị quan sát khác nhau Do đó, các cơ chế phát hiện lỗi (fault detection) thông thường không thể nhận biết được liệu một node có bị lỗi Byzantine hay không

13

Hình 2.10: Không có cách để biết được trong số các tướng khác ai là người phản bội

Tên gọi Byzantine xuất phát từ một sự so sánh rằng tình trạng này giống với một trận đánh mà các tướng quân đang quyết định có đánh chiếm thành Byzantine không Các tướng quân cần thống nhất một kế hoạch đánh hay rút lui, nhưng trong số các vị tướng có một số kẻ phản bội, chúng có thể biểu quyết đánh nhưng sau đó lại rút lui Trong một cluster có 3 node, nếu một node bị lỗi Byzantine, cả cluster sẽ không thể cung cấp dịch vụ do không thể đạt thống nhất về trạng thái và cũng không tìm ra được node bị lỗi

Lỗi Byzantine chỉ có thể giải được trong một cluster có số node bị lỗi ít hơn ⅓ tổng số node Lỗi Byzantine cũng có ảnh hưởng đến các thuật toán đồng thuận (Consensus)

14

Chương 3: BỘ CÂN BẰNG TẢI 3.1 Khái niệm bộ cân bằng tải

Bộ cân bằng tải “Load Balancer” là một thiết bị phân phối lưu lượng mạng hoặc ứng dụng trên nhiều máy chủ Load balancer được sử dụng để tăng khả năng xử lý và availability của ứng dụng

Chúng cải thiện hiệu suất tổng thể của ứng dụng bằng cách giảm gánh nặng cho máy chủ liên quan đến việc quản lý và duy trì phiên ứng dụng và mạng, cũng như thực hiện các tác vụ cụ thể của ứng dụng

Hình 3.1: Cách bộ cân bằng tải hoạt động

Bộ cân bằng tải là điểm tiếp xúc đầu tiên trong một trung tâm dữ liệu sau khi yêu cầu vượt qua tường lửa Một máy cân bằng tải có thể không cần thiết nếu dịch vụ chỉ phục vụ một vài trăm hoặc thậm chí vài nghìn yêu cầu mỗi giây Tuy nhiên, khi số lượng yêu cầu từ khách hàng tăng lên, máy cân bằng tải cung cấp những khả năng sau đây:

- Khả năng mở rộng: Khi lưu lượng truy cập tăng, load balancer có thể phân phối lưu lượng truy cập trên nhiều máy chủ, giúp dễ dàng mở rộng theo chiều ngang - Dự phòng: Load balancer có thể giúp đảm bảo tính sẵn sàng của ứng dụng bằng

cách chuyển hướng lưu lượng truy cập đến các máy chủ khác khi một máy chủ gặp sự cố

- Hiệu suất: Load balancer có thể giúp cải thiện hiệu suất của ứng dụng bằng cách phân phối lưu lượng truy cập đến các máy chủ ít bận rộn hơn

15 - Bảo mật: Bộ cân bằng tải có thể giúp bảo vệ ứng dụng khỏi các cuộc tấn công từ chối dịch vụ (DoS) và các cuộc tấn công khác bằng cách chặn lưu lượng truy cập độc hại

Bộ cân bằng tải thường đặt ở đâu ?

Thường thì, bộ cân bằng tải (LBs) đặt ở giữa client và server Yêu cầu từ client được chuyển qua server và phản hồi lại cho client thông qua bộ cân bằng tải Tuy nhiên, trong thực

tế đó không phải là điểm duy nhất mà bộ cân bằng tải được sử dụng

Hãy xem xét ba nhóm máy chủ phổ biến: máy chủ web, máy chủ ứng dụng và máy chủ

cơ sở dữ liệu Để phân chia tải lưu lượng truy cập giữa các máy chủ có sẵn, máy cân bằng tải

có thể được sử dụng giữa các phiên bản máy chủ của ba dịch vụ này theo cách sau:

- Đặt máy cân bằng tải giữa người dùng cuối của ứng dụng và máy chủ web/cổng ứng dụng

- Đặt máy cân bằng tải giữa máy chủ web và máy chủ ứng dụng chạy logic kinh doanh/ứng dụng

- Đặt máy cân bằng tải giữa máy chủ ứng dụng và máy chủ cơ sở dữ liệu

Hình 3.2: Cách sử dụng khả thi cân bằng tải trong cấu trúc 3 lớp

Trong thực tế, bộ cân bằng tải có thể được sử dụng giữa bất kỳ hai dịch vụ nào có nhiều biến thể (instances) trong thiết kế của một hệ thống

3.2 Phân loại bộ cân bằng tải

Tùy thuộc vào yêu cầu, cân bằng tải có thể được thực hiện ở tầng mạng/vận chuyển hoặc tầng ứng dụng của mô hình Open systems interconnection (OSI)

Layer 3/4 load balancer: Layer 3/4 load balancer hoạt động ở tầng mạng (network layer) và tầng vận chuyển (transport layer) của mô hình OSI và sử dụng thông tin về địa chỉ IP và

16 cổng TCP/UDP để đưa ra quyết định định tuyến Layer 3/4 load balancer thường không kiểm tra nội dung gói tin và chỉ chuyển tiếp các gói tin TCP/UDP đến các máy chủ backend

Layer 7 load balancer: Layer 7 load balancer hoạt động ở tầng ứng dụng (application layer) của mô hình OSI và sử dụng thông tin từ giao thức ứng dụng (chủ yếu là HTTP) để đưa ra quyết định định tuyến Layer 7 load balancer hoạt động như một proxy, duy trì hai kết nối TCP: một với client và một với server

3.3 Các thuật toán

Để điều hướng lưu lượng, load balancer có thể áp dụng một trong các thuật toán dưới đây để quyết định địa chỉ mà request sẽ được điều hướng tới:

- Round Robin: Phân phối lưu lượng truy cập đến các máy chủ theo lượt

- Weighted Round Robin: Tương tự như Round Robin, nhưng cho phép gán trọng số cho các máy chủ để ưu tiên một số máy chủ hơn

- Least Connections: Chuyển hướng lưu lượng truy cập đến các máy chủ có ít kết nối nhất

- Least response time: Chuyển hướng đến server với thời gian phản hồi ít thời gian nhất

- Weighted Least Connections: Tương tự như Least Connections, nhưng cho phép gán trọng số cho các máy chủ để ưu tiên một số máy chủ hơn

- IP Hash: Sử dụng địa chỉ IP nguồn và đích của lưu lượng truy cập để tính toán một giá trị băm và gán kết nối đến một máy chủ cụ thể dựa trên giá trị băm này

- URL hash: Thuật toán này hoạt động bằng cách lấy URL mà máy khách yêu cầu và biến đổi nó thành một giá trị số học (thường là một chuỗi hash) bằng cách băm URL Giá trị số học này được sử dụng để xác định máy chủ hoặc cụm máy chủ nào sẽ phục vụ yêu cầu từ máy khách

Ngoài ra còn có các thuật toán khác, như thuật toán “randomized” hoặc “weighted least connections”

3.4 Triển khai bộ cân bằng tải

3.4.1 Bộ cân bằng tải phần cứng

Bộ cân bằng tải phần cứng (hardware load balancer) là một thiết bị phần cứng vật lý được cài đặt trong trung tâm dữ liệu Nó được thiết kế để xử lý lưu lượng truy cập lớn và có hiệu suất cao

17 Tuy nhiên bộ cân bằng tải phần cứng có những hạn chế nhất định:

- Đòi hỏi kiến thức chuyên môn cao: Việc cấu hình của một bộ cân bằng tải phần cứng cần đòi hỏi một nguồn nhân lực lớn có kiến thức chuyên môn để cài đặt và cấu hình

- Vấn đề về tính khả dụng: Tính khả dụng có thể là một vấn đề với cân bằng tải phần cứng Khi xảy ra sự cố, chúng ta cần chuẩn bị thiết bị phần cứng để thay thế trong trường hợp gặp lỗi

- Chi phí vận hành và bảo trì cao: Các cân bằng tải phần cứng có thể có chi phí bảo trì và vận hành cao Ngoài ra, có thể phát sinh vấn đề về sự tương thích và tích hợp với các phần mềm và cơ sở hạ tầng khác

- Ràng buộc với nhà cung cấp: Cân bằng tải phần cứng thường kèm theo các ràng buộc của nhà cung cấp, đồng nghĩa với việc bạn có thể bị ràng buộc vào một nhà cung cấp cụ thể và khó lòng chuyển đổi sang giải pháp của nhà cung cấp khác Dưới những khía cạnh này, cân bằng tải phần cứng không phải lúc nào cũng là sự lựa chọn hàng đầu, ngay cả đối với các doanh nghiệp lớn có khả năng tài chính Sự linh hoạt kém, chi phí vận hành cao và các vấn đề về tương thích làm cho chúng ít phù hợp trong môi trường công nghiệp hiện đại, trong đó các giải pháp cân bằng tải dựa trên phần mềm và điện toán đám mây đã trở nên phổ biến hơn

18 - Coytepoint load balance0072

3.4.2 Bộ cân bằng tải phần mềm

Bộ cân bằng tải phần mềm: Là một ứng dụng phần mềm có thể được cài đặt trên máy chủ vật lý hoặc máy chủ ảo Nó có thể hoạt động như một ứng dụng độc lập hoặc được tích hợp vào hệ thống hiện có Bộ cân bằng tải phần mềm linh hoạt hơn và có chi phí thấp hơn so với Bộ cân bằng tải phần cứng

Dưới đây là một số điểm quan trọng về cân bằng tải phần mềm:

- Mở rộng tốt: Cân bằng tải dựa trên phần mềm có khả năng mở rộng tốt khi yêu cầu tăng lên Bạn có thể dễ dàng thêm máy chủ hoặc tài nguyên máy tính để xử lý khối lượng lớn yêu cầu mà không cần phải mua hoặc triển khai các thiết bị phần cứng đắt tiền

- Tính khả dụng được đảm bảo: Cân bằng tải dựa trên phần mềm thường đảm bảo tính khả dụng cao Điều này có nghĩa là bạn có thể thêm các máy chủ “shadow load balancers” trên phần cứng thông thường với chi phí bổ sung nhỏ Khi một cân bằng tải gặp lỗi hoặc gặp vấn đề, “shadow load balancers” có thể tiếp tục xử lý yêu cầu mà không gây gián đoạn dịch vụ

- Phân tích dự đoán: Cân bằng tải phần mềm có khả năng cung cấp phân tích dự đoán Điều này có nghĩa là nó có thể theo dõi và phân tích dữ liệu về lưu lượng hiện tại để dự đoán các mô hình giao thông (traffic pattern) tương lai Thông tin này giúp chuẩn bị cho các biến động trong tải và đảm bảo rằng hệ thống được cấu hình để xử lý chúng một cách hiệu quả

Hình 3.4: Bộ cân bằng tải phần mềm

3.5 Các loại mẫu triển khai

19 Bộ cân bằng tải phía máy chủ và Bộ cân bằng tải phía máy khách đều là các phương pháp phân phối lưu lượng truy cập trên nhiều máy chủ, nhưng chúng khác nhau về cách thức hoạt động:

- Bộ cân bằng tải phía máy chủ: Bộ cân bằng tải phía máy chủ được thực hiện bởi

một thiết bị hoặc ứng dụng được đặt trước các máy chủ Backend Bộ cân bằng tải sẽ nhận các yêu cầu từ khách hàng và sử dụng một thuật toán để chọn một máy chủ backend để xử lý yêu cầu Sau đó, bộ cân bằng tải sẽ chuyển tiếp yêu cầu đến máy chủ backend được chọn và trả về kết quả cho khách hàng

- Bộ cân bằng tải phía máy khách: Bộ cân bằng tải phía máy khách được thực hiện

bởi máy khách Máy khách sẽ nhận thông tin về các máy chủ backend từ một dịch vụ danh mục (registry service) và sử dụng một thuật toán để chọn một máy chủ backend để gửi yêu cầu Sau đó, máy khách sẽ gửi yêu cầu trực tiếp đến máy chủ backend được chọn và nhận kết quả trả về

20

Chương 4:

CƠ SỞ DỮ LIỆU

4.1 Tổng quan về cơ sở dữ liệu

Khái niệm cơ sở dữ liệu là một tập hợp dữ liệu được tổ chức một cách có hệ thống để quản lý và truy cập dễ dàng Cơ sở dữ liệu được tạo ra với mục tiêu giúp lưu trữ, truy xuất, sửa đổi và xóa dữ liệu một cách hiệu quả trong quá trình xử lý dữ liệu khác nhau

Hình 4.1: Cơ sở dữ liệu quan hệ và không quan hệ

Có hai loại cơ sở dữ liệu chính:

- Cơ sở dữ liệu quan hệ: Có một cấu trúc được xác định rõ ràng như các thuộc tính (các cột trong bảng)

- Cơ sở dữ liệu không quan hệ: Như cơ sở dữ liệu tài liệu (document databases), thường có cấu trúc dữ liệu được xác định bởi ứng dụng

4.2 Các loại cơ sở dữ liệu

4.2.1 Cơ sở dữ liệu quan hệ

Cơ sở dữ liệu quan hệ tuân theo một mô hình dữ liệu cụ thể trước khi lưu trữ dữ liệu Dữ liệu được lưu trữ trong cơ sở dữ liệu quan hệ đã được thiết lập trước về cấu trúc Đặc trưng của mô hình này là việc tổ chức dữ liệu thành một hoặc nhiều mối quan hệ (còn gọi là bảng), và mỗi bản ghi trong bảng này có một khóa chính (primary key) duy nhất

Cơ sở dữ liệu đảm bảo bốn thuộc tính ACID để có thể hiện sự toàn vẹn của cơ sở dữ liệu:

- Tính nguyên tử (Atomicity): Một giao dịch được coi là một đơn vị nguyên tử

Vì vậy, hoặc tất cả các câu lệnh trong một giao dịch sẽ thực thi thành công,

21 hoặc không có câu lệnh nào sẽ thực thi Nếu một câu lệnh thất bại trong một giao dịch, thì giao dịch nên bị hủy bỏ và quay trở lại trạng thái trước đó

- Tính nhất quán (Consistency): Tại bất kỳ thời điểm nào, cơ sở dữ liệu nên ở

trong một trạng thái nhất quán, và nó nên duy trì trạng thái nhất quán sau mỗi giao dịch Ví dụ, nếu nhiều người dùng muốn xem một bản ghi từ cơ sở dữ liệu, nó nên trả về kết quả tương tự mỗi lần

- Tính cách ly (Isolation): Trong trường hợp có nhiều giao dịch đang chạy

đồng thời, chúng không nên ảnh hưởng đến nhau Trạng thái cuối cùng của cơ sở dữ liệu nên giống như khi các giao dịch được thực thi theo tuần tự

- Tính bền vững (Durability): Hệ thống nên đảm bảo rằng các giao dịch đã

hoàn thành sẽ tồn tại vĩnh viễn trong cơ sở dữ liệu, ngay cả trong trường hợp sự cố hệ thống

Một số hệ quản trị cơ sở dữ liệu quan hệ:- MySQL

- Oracle Database - Microsoft SQL Server- IBM DB2

- Postgres - SQLite

4.2.2 Cơ sở dữ liệu không quan hệ

Cơ sở dữ liệu không quan hệ được thiết kế cho nhiều mô hình dữ liệu khác nhau để truy cập và quản lý dữ liệu Các cơ sở dữ liệu này được sử dụng trong các ứng dụng yêu cầu khối lượng lớn dữ liệu bán cấu trúc và phi cấu trúc, độ trễ thấp và mô hình dữ liệu linh hoạt

Tại sao sử dụng cơ sở dữ liệu không quan hệ: - Thiết kế đơn giản

- Dễ dàng mở rộng ngang - Tính khả dụng cao

- Hỗ trợ dữ liệu không có cấu trúc và bán cấu trúc - Chi phí thấp

22

Hình 4.2: Các loại cơ sở dữ liệu không quan hệ

a Cơ sở dữ liệu “key-value”

Cơ sở dữ liệu key-value sử dụng các phương pháp key-value giống như bảng băm để lưu trữ dữ liệu dưới dạng các cặp key-value (khóa-giá trị)

Trường hợp sử dụng: Cơ sở dữ liệu key-value hiệu quả cho các ứng dụng có tính phiên (session-oriented) Các ứng dụng phiên, chẳng hạn như ứng dụng web, lưu trữ dữ liệu của người dùng trong bộ nhớ chính hoặc trong cơ sở dữ liệu trong suốt một phiên làm việc

Hình 4.3: Dữ liệu được lưu trữ dưới dạng cặp khóa-giá trị trong DynamoDB, trong đó khóa chính bao gồm hai thuộc tính (Product ID và Type)

23

b Cơ sở dữ liệu “document”

Cơ sở dữ liệu tài liệu (document database) được thiết kế để lưu trữ và truy xuất tài liệu trong các định dạng như XML, JSON, BSON, và nhiều định dạng tài liệu khác

Trường hợp sử dụng: Cơ sở dữ liệu tài liệu thích hợp cho dữ liệu danh mục không có cấu

trúc, chẳng hạn như tệp JSON hoặc dữ liệu có cấu trúc phức tạp theo hình cấu trúc phân cấp

Hình 4.4: Một dạng file JSON chứa dữ liệu của người dùng

c Cơ sở dữ liệu “Graph”

Cơ sở dữ liệu đồ thị “Graph” sử dụng cấu trúc dữ liệu đồ thị để lưu trữ dữ liệu, trong đó các nút (nodes) đại diện cho các thực thể (entities), và các cạnh (edges) biểu thị mối quan hệ giữa các thực thể Tổ chức các nút dựa trên mối quan hệ tạo ra các mẫu thú vị giữa các nút

Trường hợp sử dụng: Cơ sở dữ liệu đồ thị cho phép biểu diễn dữ liệu theo các mối quan

hệ phức tạp, như mô hình hóa mạng xã hội, quan hệ tương tác giữa người dùng trên mạng, và nhiều ứng dụng khác Cơ sở dữ liệu đồ thị thường được sử dụng khi cần xem xét sự kết nối và mối quan hệ giữa các dữ liệu trong một hệ thống

Các hệ quản trị cơ sở dữ liệu đồ thị “Graph” phổ biến như Neo4J, OrientDB, and InfiniteGraph

24

Hình 4.5: Một đồ thị bao gồm các nút và liên kết Đồ thị này ghi lại các thực thể và mối quan hệ giữa chúng

d Cơ sở dữ liệu cột “Columnar”

Cơ sở dữ liệu cột (columnar databases) lưu trữ dữ liệu theo cột thay vì theo hàng như trong cơ sở dữ liệu truyền thống Điều này cho phép truy cập nhanh chóng và hiệu quả đến tất cả các mục trong cột cơ sở dữ liệu Một số cơ sở dữ liệu cột phổ biến bao gồm Cassandra, HBase, Hypertable và Amazon Redshift

Trường hợp sử dụng: Cơ sở dữ liệu cột hiệu quả khi cần thực hiện nhiều truy vấn tổng hợp và phân tích dữ liệu trên một lượng lớn dữ liệu Nó giảm đáng kể yêu cầu về đọc/ghi dữ liệu từ đĩa cứng (disk I/O) và lượng dữ liệu cần phải nạp từ đĩa Điều này làm cho cơ sở dữ liệu cột trở nên hữu ích cho các ứng dụng như kho dữ liệu dành cho dữ liệu phân tích, báo cáo, và thống kê

Cơ Sở Dữ Liệu Quan HệCơ Sở Dữ Liệu Phi Quan Hệ

Yêu cầu ACID (Atomicity, Consistency, Isolation, Durability)

Không yêu cầu ACID (Atomicity, Consistency, Isolation, Durability) Không thường cần tích hợp dữ liệu Không thường cần tích hợp dữ liệu Thích hợp cho dữ liệu có kích thước tương đối nhỏ

và có thể chứa trên một nút máy chủ (node)

Thích hợp cho việc lưu trữ dữ liệu lớn

Đảm bảo tính ACID trong một hệ thống:

- Tính nguyên tử - Atomacity: Các giao dịch được thực hiện đồng thời khi tất cả các node đều đã cam kết hoàn thành hoặc được hủy bỏ khi có một node hủy bỏ

- Tính nhất quán – Consistency: Tại bất kỳ thời điểm nào, mọi dữ liệu trên toàn bộ các node phải duy trì ở một trạng thái nhất quán, và nó cũng phải đảm bảo trạng thái nhất quán sau một giao dịch

- Tính cách ly – Isolation: Trong trường hợp có nhiều giao dịch đang chạy thì chúng không nên ảnh hưởng đến nhau

- Tính bền vững – Durability: Hệ thống nên đảm bảo rằng các giao dịch đã hoàn thành sẽ được lưu trữ trong hệ thống dữ liệu và không được mất đi kể cả khi hệ thống gặp sự cố

Đối với hệ thống phân tán, tính bền vững có thể đạt được khi chúng ta lưu trữ các bản sao dữ liệu để đảm bảo khi một thành phần sụp đổ thì thành phần thay thế có thể truy cập bản sao dữ liệu đó và tiếp tục nhiệm Còn đối với tính nhất quán, chúng ta có thể sử dụng các giải pháp như khóa ngoại, cascades, triggers, …

Nhưng ngược lại việc để hệ thống đảm bảo tính cách ly và nguyên tử là một thử thách và khó triển khai

5.2 Xác nhận 2 pha “2-Phase Commit” (2PC)

Trong một hệ thống phân tán với mạng không đáng tin cậy, việc chỉ gửi một thông điệp đến các nút liên quan không đủ để thực hiện một giao dịch phân tán

Nút khởi tạo giao dịch sẽ không biết liệu các nút khác đã cam kết thành công hay đã hủy bỏ do một số sự cố, để đưa ra quyết định cuối cùng về kết quả của giao dịch