đồ án 1 thiết kế hệ thống microservice với java

Chương 1: Tổng quan về thiết kế hệ thốngThiết kế hệ thống là quá trình đị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 mo

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

KHOA CÔNG NGHỆ PHẦN MỀM

BÁO CÁO ĐỒ ÁN CUỐI KỲ

Môn học: Đồ án 1 – SE121.O11.PMCL

ĐỀ TÀI:

THIẾT KẾ HỆ THỐNG MICROSERVICE VỚI JAVA

Giảng viên hướng dẫn: ThS Nguyễn Công Hoan

Sinh viên thực hiện: Đinh Quang Dương 21250751

TP HCM, 12/2023

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

KHOA CÔNG NGHỆ PHẦN MỀM

BÁO CÁO ĐỒ ÁN CUỐI KỲ

Môn học: Đồ án 1 – SE121.O11.PMCL

ĐỀ TÀI:

THIẾT KẾ HỆ THỐNG MICROSERVICE VỚI JAVA

Giảng viên hướng dẫn: ThS Nguyễn Công Hoan

Sinh viên thực hiện: Đinh Quang Dương 21250751

TP HCM, 12/2023

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

Người nhận xét

(Ký tên và ghi rõ họ tên)

LỜI MỞ ĐẦU

Java là một ngôn ngữ lập trình phổ biến và mạnh mẽ, được phát triển bởi Sun Microsystems và hiện nay thuộc sở hữu của Oracle Corporation Java được thiết kế để có tính độc lập nền tảng, có khả năng chạy trên nhiều hệ điều hành khác nhau Java cung cấp một môi trường thực thi ổn định và an toàn, với cú pháp dễ hiểu và hỗ trợ các tính năng lập trình phong phú

Microservice (hay còn gọi là kiến trúc microservice) là một mô hình kiến trúc phần mềm trong đó ứng dụng được chia thành các dịch vụ nhỏ và độc lập Mỗi dịch vụ tương ứng với một chức năng cụ thể và có khả năng hoạt động độc lập với nhau Các dịch vụ này giao tiếp với nhau thông qua các giao thức như HTTP/REST và thường có cơ sở dữ liệu riêng biệt Kiến trúc microservice giúp tách biệt các thành phần của ứng dụng, tăng tính mô-đun hóa, linh hoạt và khả năng mở rộng của hệ thống

Sự phổ biến của kiến trúc microservice đã tăng lên trong những năm gần đây Mô hình này được ưa chuộng bởi khả năng chia nhỏ ứng dụng thành các dịch vụ nhỏ hơn, giúp tăng khả năng phát triển độc lập và đồng thời giảm sự phụ thuộc giữa các thành phần Nó cung cấp một cách tiếp cận linh hoạt và hiệu quả để xây dựng và triển khai các ứng dụng phân tán, đáp ứng nhanh chóng các yêu cầu thay đổi và khả năng mở rộng Kiến trúc microservice cũng tạo điều kiện thuận lợi cho việc sử dụng công nghệ mới như điện toán đám mây và giao diện lập trình ứng dụng (API), hỗ trợ tích hợp và phát triển linh hoạt

Sự phổ biến của kiến trúc microservice cũng đi đôi với sự phát triển của các công cụ và framework hỗ trợ, bao gồm Spring Boot, Micronaut và Kubernetes Nhờ vào tính linh hoạt và khả năng mở rộng, kiến trúc microservice đã trở thành một lựa chọn phổ biến cho việc xây dựng các ứng dụng phức tạp và quy mô lớn, đáp ứng nhu cầu thay đổi và mở rộng trong môi trường kinh doanh hiện đại

Nắm bắt được nhu cầu này, em đã quyết định tìm hiểu ngôn ngữ lập trình Java và các nguyên tắc thiết kế hệ thống để xây dựng hệ thống microservice với Java Spring Boot.

LỜI CẢM ƠN

Đầu tiên, nhóm xin gửi lời cảm ơn chân thành đến tập thể quý Thầy Cô Trường Đại học Công nghệ thông tin – Đại học Quốc gia TP.HCM và quý Thầy Cô khoa Công nghệ phần mềm đã giúp cho em có những kiến thức cơ bản làm nền tảng để thực hiện đề tài này Đặc biệt, em xin gửi lời cảm ơn và lòng biết ơn sâu sắc nhất tới thầy Nguyễn Công Hoan Thầy đã trực tiếp hướng dẫn tận tình, sửa chữa và đóng góp nhiều ý kiến quý báu giúp em hoàn thành tốt báo cáo môn học của mình Trong thời gian một học kỳ thực hiện đề tài, em đã vận dụng những kiến thức nền tảng đã tích lũy đồng thời kết hợp với việc học hỏi và nghiên cứu những kiến thức mới Từ đó, em vận dụng tối đa những gì đã thu thập được để hoàn thành một báo cáo đồ án tốt nhất Tuy nhiên, trong quá trình thực hiện, em không tránh khỏi những thiếu sót Chính vì vậy, em rất mong nhận được những sự góp ý từ phía Thầy nhằm hoàn thiện những kiến thức mà em đã học tập và là hành trang kiến thức giúp em phát triển trong tương lai

Sau cùng, nhóm xin kính chúc Thầy thật dồi dào sức khỏe, niềm tin để tiếp tục thực hiện sứ mệnh cao đẹp của mình là truyền đạt kiến thức cho thế hệ mai sau

Xin chân thành cảm ơn các quý Thầy Cô!

Nhóm sinh viên thực hiện

MỤC LỤC

LỜI MỞ ĐẦU 1

LỜI CẢM ƠN 2

Chương 1: Tổng quan về thiết kế hệ thống 9

1.1 Thiết kế trong các hệ thống nhỏ và trong các hệ thống lớn 9

3.2.4 Reverse proxy sidecar cache 41

3.2.5 Làm trống cache (Cache eviction) 41

3.3 Các pattern truy cập trong caching 42

4.2 Phương thức giao tiếp giữa các service 53

4.2.1 Giao tiếp đồng bộ dựa trên Remote procedure invocation pattern 54

4.2.2 Giao tiếp bất đồng bộ sử dụng messaging pattern 55

4.3 Khuyết điểm của microservice 58

Chương 5: Service discovery & API Gateway 59

5.1 Microservice routing pattern 59

5.2 Phân loại service discovery 60

5.2.1 Application-level Service Discovery Pattern 61

5.2.2 Platform-provided Service Discovery Pattern 62

5.3 Phân loại hình thức register 64

6.4.2 Saga Execution Coordinator 80

6.5 So sánh Two-phase commit/Three-phase commit và Saga 85

Chương 7: Consensus 86

7.1 Vấn đề Consensus 86

7.1.1 Định nghĩa về vấn đề Consensus 86

7.1.2 Các use-case của sự thống nhất 87

6

7.2 Thuật toán Raft 88

7.2.1 Khái quát về Raft 88

7.2.2 Giao tiếp giữa các nút Raft 89

7.2.3 Triển khai thuật toán Raft 92

7.2.4 Ưu và nhược điểm của Raft 92

Chương 8: Querying in microservice 93

8.1 Querying using the API composition pattern 93

8.1.1 The findOrder() query operation 93

8.1.2 Overview of the API composition pattern 94

8.1.3 Implementing the findOrder() query operation using the API composition pattern 95

8.1.4 API composition design issues 95

8.1.5 The benefits and drawbacks of the API composition pattern 98

8.2 Using the CQRS pattern 99

8.2.1 Motivations for using CQRS 99

8.2.2 Overview of CQRS 102

8.2.3 The benefits of CQRS 105

8.2.4 The drawbacks of CQRS 105

8.3 Designing CQRS views 105

8.3.1 Choosing a view datastore 106

8.3.2 Data access module design 108

8.3.3 Adding and updating CQRS views 109

Chương 9: Deployment 111

9.1 Virtual Machine & Container 111

9.1.1 Container 111

9.1.2 Virtual Machine 112

9.2 Deploy patterns 113

9.2.1 Multiple instance per host 113

9.2.2 Once instance per host 114

Chương 10: Xây dựng hệ thống với Spring Boot 141

10.1 Spring Boot Starter 141

10.2 Spring Data JPA 142

10.3 Spring cache 143

10.4 Spring Cloud Stream 145

8

10.5 Spring Data Elasticsearch 147

10.6 Spring Boot với docker 148

10.7 Spring Security 149

10.8 Spring Boot JSR303 152

10.9 Spring Cloud Open Feign 153

10.10 Spring Cloud Resilience4j 155

10.11 Spring Cloud Consul 156

10.12 Spring Cloud Vault 157

10.13 Spring State Machine 158

Chương 1: Tổng quan về thiết kế hệ thống

Thiết kế hệ thống là quá trình đị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 các hệ thống với quy mô lớn đáp ứng các yêu cầu về chức năng và phi chức năng.

Thiết kế hệ thống sử dụng các khái niệm trong lĩnh vực mạng máy tính (Computer Networking), tính toán song song (Parallel Computing) và hệ thống phân tán (Distributed systems) để xây dựng những hệ thống có khả năng mở rộng và hiệu suất cao.

Thiết kế hệ thống có mục đích xây dựng những hệ thống có độ tin cậy (reliable), hiệu quả, và dễ bảo trì cùng với những đặc điểm khác.

• Hệ thống hiệu quả là hệ thống đáp ứng tất cả các nhu cầu của người dùng và yêu cầu

kinh doanh

• 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ì

1.1 Thiết kế trong các hệ thống nhỏ và trong các hệ thống lớn

1.1.1 Thiết kế trong hệ thống nhỏ

Với các hệ thống nhỏ và tương đối đơn giản, thiết kế và kiến trúc của hệ thống không phải là một vấn đề quá phức tạp, do bản thân các hệ thống này tương đối dễ tổ chức, dễ vận hành, dễ

Với các hệ thống này, Với các hệ thống này, có rất nhiều mô hình phát triển phần mềm đủ đáp

ứng yêu cầu: Kiến trúc client-server, kiến trúc layer, kiến trúc monolithic,…

Hình 1: Kiến trúc Layer

Hình 2: Kiến trúc monolithic

Hình 3: Kiến trúc Client-Server

Một điểm chung của các loại kiến trúc này đều là mô hình hệ thống tập trung vì vậy nó sẽ có các vấn đề sau:

Về mặt “hiệu suất”, các hạn chế về vật lý của phần cứng như nâng cấp CPU, nâng cấp RAM,

nâng ổ cứng,… đặt ra một số giới hạn đối một máy chủ Với các hệ thống có quy mô lớn hơn, mô hình nghiệp vụ phức tạp hơn, nhiều người sử dụng hơn, các mô hình kiến trúc kể trên không đủ khả năng để cung cấp dịch vụ kịp thời, chính xác và ổn định Hơn nữa, việc nâng cao hiệu suất của một máy chủ duy nhất trở nên vô cùng đắt đỏ sau một ngưỡng nhất định.

Về mặt “mở rộng”, việc lưu trữ và xử lý dữ liệu đều đóng góp cho các hệ thống phần mềm về

những giá trị nhất định Vì vậy, Khi lượng khách hàng của hệ thống tăng lên, hệ thống cần xử lý thêm lưu lượng và lưu trữ lượng dữ liệu lớn hơn Tuy nhiên, hệ thống bao gồm một máy chủ duy nhất chỉ có thể mở rộng đến một mức nhất định.

Về mặt “sẵn sàng”, Hiện nay, hầu hết các dịch vụ trực tuyến cần hoạt động liên tục (24/7),

đây là một thách thức lớn đối với các hệ thống Khi một dịch vụ khẳng định có tính “sẵn sàng” 5-9, thì thường hoạt động 99.999% thời gian Điều này do giới hạn phần cứng của một server không thể nào đáp ứng được một nghìn, mười nghìn, thậm chí là cả triệu yêu cầu tại một thời điểm.

1.1.2 Thiết kế trong hệ thống lớn

Để giải quyết các vấn đề của những hệ thống nhỏ, việc thiết kế hệ thống lớn cần phải áp dụng những kiến trúc phức tạp, đặc biệt hơn để đáp ứng nhu cầu chịu tải lớn, đảm bảo độ ổn định, độ chính xác và có khả năng chịu lỗi Một hệ thống có các nhu cầu trên thông thường sẽ sử dụng nhiều server, mỗi server song song chạy chương trình và nhiều cơ sở dữ liệu để đáp ứng nhu cầu lưu trữ.

Thiết kế hệ thống hiện đại với Khối Xây Dựng (Building Blocks)

Trong thiết kế hệ hiện đại, những thành phần thiết kế cơ bản như cân bằng tải (Load balancer)

sẽ được tách ra thành các khối xây dựng cơ bản (Building block).

Điều này phục vụ cho 2 mục đích:

Thứ nhất, có thể thảo luận về tất cả khối xây và các vấn đề thiết kế của chúng.

Thứ hai, khi giải quyết một vấn đề thiết kế, có thể tập trung vào các khía cạnh cụ thể của vấn đề, đề cập đến các khối xây dựng nhất định và cách sử dụng chúng Điều này giúp loại bỏ các cuộc thảo luận trùng lặp về các yếu tố thiết kế thường xuyên xảy ra.

Chi tiết 16 khối xây dựng:

1 Hệ thống tên miền (Domain Name System: DNS): Khối này tập trung vào cách thiết kế các

hệ thống đặt tên phân cấp và phân tán cho các máy tính được kết nối với Internet thông qua các giao thức Internet khác nhau.

2 Bộ cân bằng tải (Load Balancers): Khối này được sử dụng để phân phối cân bằng các yêu

cầu đến từ khách hàng đến một nhóm máy chủ có sẵn Nó cũng giảm tải và có thể bỏ qua các máy chủ khi gặp sự cố.

3 Cơ sở dữ liệu (Databases): Khối này cho phép lưu trữ, truy xuất, sửa đổi và xóa dữ liệu liên

quan đến các thủ tục xử lý dữ liệu khác nhau như là các loại cơ sở dữ liệu, sao chép, phân vùng và phân tích của cơ sở dữ liệu phân tán.

4 Bộ lưu trữ Khóa-Giá trị (Key-Value store): Khối này là cơ sở dữ liệu phi quan hệ, cho phép

lưu trữ dữ liệu dưới dạng cặp khóa-giá trị.

5 Mạng phân phối nội dung (Content Delivery Network: CDN): Khối này được sử dụng để

lưu trữ nội dung lan truyền như video, hình ảnh, âm thanh và trang web Nó hiệu quả trong việc phân phối nội dung cho người dùng cuối mà vẫn giảm thiểu độ trễ và gánh nặng cho các dữ liệu trung tâm.

6 Bộ tạo số thứ tự (Sequencer): Khối này được dùng để tạo số ID duy nhất.

7 Bảng giám sát dịch vụ (Service Monitoring): Khối này quan trọng trong các hệ thống phân

tán chúng giúp phân tích hệ thống và cảnh báo cho các bên liên quan nếu xảy ra vấn đề.

8 Bộ đệm phân tán (Distributed Caching): Khối này là một hệ thống đệm phân tán trong đó

nhiều máy chủ đệm phối hợp để lưu trữ dữ liệu được truy cập thường xuyên.

9 Hàng đợi tin nhắn phân tán (Distributed Messaging Queue): Khối này là một hệ thống hàng

đợi tin nhắn phân tán bao gồm nhiều máy chủ, được sử dụng giữa các thực thể tương tác được gọi là nhà sản xuất và người tiêu dùng Nó giúp tách biệt nhà sản xuất và người tiêu dùng, đảm bảo tính mở rộng độc lập và cải thiện độ tin cậy.

10 Hệ thống xuất bản-đăng ký (Publish-Subscribe System): Khối này là một phương pháp

giao tiếp không đồng bộ giữa các dịch vụ Hệ thống này được phổ biến trong kiến trúc serverless, microservices và hệ thống xử lý dữ liệu.

11 Bộ giới hạn tốc độ (Rate Limiter): Khối này là hệ thống giới hạn số lượng yêu cầu đến cho

một dịch vụ dựa trên giới hạn được xác định trước Hệ thống này thường được sử dụng như một lớp phòng thủ cho các dịch vụ để tránh việc sử dụng quá mức - có ý định hoặc không có ý định.

12 Bộ lưu trữ đối tượng (Blob Store): Khối này được dùng để lưu trữ các dữ liệu phi cấu trúc,

ví dụ như các tệp đa phương tiện và các tệp nhị phân.

13 Bộ tìm kiếm phân tán (Distributed Search): Khối này là một hệ thống tìm kiếm lấy truy

vấn của người dùng và trả về một nội dung liên quan trong một vài giây hoặc ít hơn Khối này tập trung vào 3 thành phần quan trọng: thu thập (crawl), chỉ mục hóa (index) và tìm kiếm (search).

14 Bộ ghi log phân tán (Distributed Logging): Khối này là hệ thống cho phép các dịch vụ

trong một hệ thống phân tán ghi lại sự kiện của họ một cách hiệu quả Hệ thống sẽ được thiết kế để có khả năng mở rộng và đáng tin cậy.

15 Bộ lập lịch công việc phân tán (Distributed Task Scheduling): Khối này là hệ thống trung

gian giữa công việc và tài nguyên Hệ thống sẽ phân bổ tài nguyên một cách hiệu quả cho các nhiệm vụ để đáp ứng các mục tiêu cấp nhiệm vụ và cấp hệ thống, thường được sử dụng để giảm bớt xử lý nền để hoàn thành bất đồng bộ.

16 Bộ đếm phân tán (Sharded Counters): Khối này được sử dụng để xử lý hàng triệu yêu cầu

đọc/viết đồng thời, như số lượt thích trên một bài viết của người nổi tiếng trên mạng xã hội.

Ví dụ về một hệ thống lớn “Youtube”

Đầu tiên, xác định các yêu cầu của Youtube

Yêu cầu về phi chức năng:

• Tính sẵn sàng cao (High availability): Đây là tính chất quan trọng của hệ thống, đòi hỏi

hệ thống luôn sẵn sàng hoạt động Hệ thống phải đảm bảo một tỷ lệ thời gian hoạt động (uptime) cao Thông thường, một tỷ lệ uptime từ 99% trở lên được coi là tốt

• Khả năng mở rộng (Scalability): Để đáp ứng sự tăng trưởng về số lượng người dùng,

hệ thống cần đảm bảo rằng các vấn đề như lưu trữ dữ liệu, băng thông yêu cầu cho việc xem dữ liệu đồng thời, và số lượng yêu cầu từ người dùng đồng thời không gây ra sự kẹt trệ (bottleneck) trong ứng dụng hoặc máy chủ web của chúng ta

• Hiệu suất tốt (Good performance): Việc cung cấp trải nghiệm xem video mượt mà

đóng vai trò quan trọng trong việc cải thiện tổng thể hiệu suất của hệ thống

• Độ tin cậy (Reliability): Dữ liệu được tải lên hệ thống phải được bảo vệ và không được

mất mát hoặc bị hỏng Điều này đảm bảo rằng thông tin quý báu của người dùng không bị ảnh hưởng bởi sự cố hoặc lỗi hệ thống

Bây giờ là các khối xây dựng (Building block) được xác định trong hệ thống Youtube

Databases (Cơ sở dữ liệu): Cơ sở dữ liệu cần được sử dụng để lưu trữ thông tin về video, hình

thu nhỏ, bình luận và thông tin liên quan đến người dùng.

Blob storage (Lưu trữ đối tượng lớn): Lưu trữ đối tượng lớn là một phần quan trọng để lưu trữ

tất cả các video trên nền tảng.

CDN (Mạng phân phối nội dung): Mạng phân phối nội dung được sử dụng để hiệu quả phân

phối nội dung đến người dùng cuối, giảm độ trễ và áp lực đối với máy chủ cuối cùng.

Load balancers (Cân bằng tải): Cân bằng tải là cần thiết để phân phối hàng triệu yêu cầu từ

khách hàng đến các máy chủ có sẵn trong bể máy chủ.

Thiết kế chi tiết của hệ thống Youtube:

Một số thử thách khi triển khai thiết kế hệ thống lớn

Đối với thiết kế các hệ thống lớn, chúng rất phức tạp và khó để thiết kế và triển khai Bên cạnh đó, các hệ thống trên thế giới hiện nay đều được thiết kế dựa trên “Hệ thống phân tán” và có những thử thách nhất định:

Network asynchrony

Network asynchrony là một đặc điểm của mạng truyền thông (Communication network) mà

trong hệ thống phân tán rất khó đảm bảo rằng các thông điệp sẽ được gửi đi và nhận đến theo một thời gian cố định hoặc theo thứ tự cụ thể Ví dụ, trong hệ thống phân tán, các thông điệp có thể mất rất nhiều thời gian để đến đích, hoặc chúng có thể đến theo thứ tự không đúng, hoặc thậm chí không đến đích một cách hoàn toàn Điều này có thể gây ra các hành vi trái với logic và không trực quan, và đòi hỏi các kỹ thuật và giải pháp đặc biệt để quản lý và xử lý.

Partial failures

Partial failures là các trường hợp trong đó chỉ một số thành phần của hệ thống phân tán gặp sự

cố hoặc lỗi Việc này có thể hiếm thấy với một số loại ứng dụng mà chỉ có một máy chủ đơn lẻ triển khai Các ứng dụng phân tán hoạt động dưới giả định rằng hoặc mọi thứ đang hoạt động bình thường, hoặc đã xảy ra sự cố với máy chủ Điều này đặt ra một vấn đề phức tạp khi cần đảm bảo tính nguyên tử qua các thành phần trong một hệ thống phân tán Do đó, một hoạt động hoặc giao dịch được thực hiện hoặc không được thực hiện toàn bộ, không để lại tình trạng không xác định hoặc dữ liệu không đồng nhất khi có lỗi xảy ra.

Concurrency đề cập đến việc thực hiện đồng thời nhiều tính toán hoặc tác vụ cùng lúc, và đôi

khi chúng có thể làm việc trên cùng một dữ liệu đồng thời Việc tính toán song song (concurrency) gây ra sự phức tạp vì khi nhiều tính toán chạy song song, chúng có thể tương tác với nhau và tạo ra các hành vi không mong muốn Điều này khác biệt so với các ứng dụng đơn giản hơn không liên quan đến tính toán song song, trong đó chương trình thực hiện các lệnh theo thứ tự được định nghĩa bởi chuỗi lệnh trong mã nguồn, thường tuân theo một luồng tuần tự tuyến tính.

1.2 Các nguyên lý thiết kế hệ thống

1.2.1 Scalability

Scalability là khả năng mở rộng (scaling) của hệ thống (system), quy trình (process) hay mạng lưới (network), 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 (business model).

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ữ (data storage)

• Gia tăng về số lượng yêu cầu và khối lượng công việc (process/request)

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.

Kích thước

Dưới đây là các khía cạnh mở rộng khác nhau về kích thước của một hệ thống:

Tính mở rộng về kích thước (Size Scalability): Đây là khả năng của hệ thống để tăng cường

kích thước của nó mà không cần sửa đổi cấu trúc hoặc mã nguồn Ví dụ, một trang web có thể thêm nhiều người dùng cùng một lúc mà không gây ra sự giảm sút đáng kể trong tốc độ và hiệu suất của trang web.

Tính mở rộng về Quản lý (Administrative Scalability): Khi hệ thống có tính mở rộng quản lý,

nhiều tổ chức hoặc người dùng có thể sử dụng cùng một hệ thống mà không cần sự phức tạp trong việc quản lý và duy trì Ví dụ, một hệ thống lưu trữ đám mây có thể phục vụ nhiều tổ chức và người dùng mà không gây ra sự rối rắm trong việc quản lý tài khoản và dịch vụ.

Tính mở rộng về Địa lý (Geographical Scalability): Nó đề cập đến việc hệ thống có thể phục

vụ một vùng địa lý rộng, chẳng hạn như một quốc gia hoặc toàn cầu, mà không gây ra độ trễ hoặc giảm hiệu quả đáng kể trong hiệu suất Ví dụ, các dịch vụ trực tuyến như trang web thương mại điện tử cần phải có khả năng phục vụ khách hàng từ khắp nơi trên thế giới mà không gây ra độ trễ lớn trong việc tải trang hoặc giao dịch.

Những cách để thực hiện tính mở rộng của một hệ thống

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… 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 deploy hệ thống Chi phí cho việc vertical scaling thường đắt đỏ.

Vertical-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.

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.

1.2.2 Availability

Tính khả dụng (availability) 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.

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:

Mỗi nhà cung cấp dịch vụ có thể có cách tính toán khả dụng riêng biệt dựa trên thời gian bắt đầu đo lường, cách họ xử lý các sự cố hoặc gián đoạn trong dịch vụ, và cách họ xem xét thời gian ngừng hoạt động Điều này có nghĩa là khi bạn đánh giá hoặc so sánh các nhà cung cấp dịch vụ, bạn nên nắm rõ cách mà họ tính toán và báo cáo mức độ khả dụng của họ để có một cái nhìn chính xác về độ tin cậy của dịch vụ của họ.

Để tăng cường tính khả dụng của một hệ thống, chúng ta có những phương pháp sau đây:

a. Xóa bỏ những tác nhân bị hỏng duy nhất

Để loại bỏ các tác nhân bị hỏng, cần đảm bảo tính dự phòng ở mọi cấp độ hệ thống Một tác nhân hỏng duy nhất là một thành phần trong hệ thống của bạn gây gián đoạn dịch vụ nếu nó gặp sự cố.

Mọi phần quan trọng có trách nhiệm thực thi của một hệ thống cơ bản phải có một bản sao dự phòng để xử lý nếu có sự cố xảy ra đối với thành phần chính Có các mức độ khác nhau về tính dự phòng:

Mô hình N+1 bao gồm số lượng thiết bị (được gọi là "N") cần thiết để duy trì hệ thống hoạt

động, cộng với một bản sao dự phòng độc lập cho mỗi thành phần quan trọng Các thành phần thường là “active” và “passive” (bản sao dự phòng sẵn sàng, chờ đợi để tiếp quản khi xảy ra sự cố) hoặc “active” và “active” (bản sao dự phòng hoạt động ngay cả khi thành phần chính hoạt động với khi không có sự cố).

Mô hình N+2 tương tự như N+1, nhưng mô hình này đảm bảo hệ thống có thể chịu được sự cố

của hai thành phần giống nhau Mô hình N+2 đủ để duy trì hoạt động của hầu hết các tổ chức ở mức độ "sẵn sàng cao".

Mô hình 2N bao gồm gấp đôi số lượng của mọi thành phần cần thiết để chạy hệ thống Có một

bản sao dự phòng hoàn toàn hoạt động của toàn bộ.

Mô hình 2N+1 cung cấp mức độ sẵn sàng và tính dự phòng giống như 2N với sự bổ sung của một thành phần bổ sung để tạo thêm một lớp an toàn.

b.Sao lưu và phục hồi dữ liệu

Hệ thống có tính sẵn sàng cao phải có kế hoạch bảo vệ dữ liệu và phục hồi sau khi gặp sự cố Chiến lược sao lưu dữ liệu là điều tuyệt đối cần thiết, và một công ty phải có khả năng phục hồi từ các sự cố về lưu trữ như mất dữ liệu hoặc lỗi dữ liệu một cách nhanh chóng.

Sử dụng sao chép dữ liệu (data replication) là lựa chọn tốt nhất nếu một doanh nghiệp yêu cầu thời gian phục hồi tối thiểu (RTO) và thời gian mất dữ liệu tối đa (RPO) thấp và không thể chấp nhận mất dữ liệu Cài đặt sao lưu phải có quyền truy cập vào các bản ghi dữ liệu mới nhất để thiết lập một cách trơn tru và đúng đắn nếu xảy ra sự cố với hệ thống chính.

RTO (Recovery Time Objective): Đây là thời gian mà bạn đặt ra để phục hồi hệ thống sau khi

có sự cố Thời gian RTO càng ngắn, thời gian hệ thống quay trở lại hoạt động càng nhanh chóng.

RPO (Recovery Point Objective): Đây là mức độ mà bạn đặt ra cho mất dữ liệu có thể chấp

nhận được sau khi phục hồi Nó đo lường khoảng thời gian mà dữ liệu có thể mất trong trường hợp có sự cố RPO thấp đồn nghĩa bạn không muốn mất nhiều dữ liệu trong trường hợp sự cố xảy ra.

c. Failover

Chỉ riêng dự phòng và sao lưu không đảm bảo tính sẵn sàng cao Một hệ thống cần có cơ chế phát hiện lỗi và hành động khi một trong các thành phần gặp sự cố hoặc không khả dụng Hệ thống có tính khả dụng cao gần như phải chuyển hướng ngay lập tức các yêu cầu sang thiết lập sao lưu trong trường hợp bị lỗi.

Failover có 2 cách: chủ động-thụ động (active-passive) và chủ động-chủ động (active-active).Với failover chủ động-thụ động, heartbeat (nhịp tim) được gửi giữa server chủ động và server thụ động ở chế độ chờ Nếu nhịp tim bị gián đoạn, server thụ động sẽ tiếp nhận địa chỉ IP của server đang hoạt động và tiếp tục dịch vụ Khoảng thời gian ngừng hoạt động được xác định bằng việc server thụ động đã chạy ở chế độ chờ 'nóng' hay cần khởi động từ chế độ chờ 'nguội' Chỉ có server chủ động xử lý yêu cầu Failover chủ động-thụ động cũng có thể được gọi là failover chủ-tớ (master-slave).

Trong trạng thái chủ động-chủ động, cả hai server đều xử lý yêu cầu, tải được cân bằng giữa chúng Nếu các server ở chế độ công khai, thì DNS sẽ cần biết về các IP công khai của cả hai server để có thể hỗ trợ client-side load balancing Nếu các server chỉ giao tiếp nội bộ,

application logic sẽ cần biết về cả hai server Failover chủ động-chủ động cũng có thể được gọi là failover chủ-chủ (master-master).

d.Load Balancing

Cân bằng tải (Load balancing) là một phần quan trọng để đảm bảo tính sẵn sàng cao khi nhiều người dùng truy cập vào một hệ thống cùng một lúc Cân bằng tải phân phối công việc giữa các tài nguyên hệ thống (ví dụ: gửi các yêu cầu dữ liệu đến các máy chủ khác nhau và môi trường CNTT trong kiến trúc đám mây kết hợp).

Bộ cân bằng tải (có thể là một thiết bị phần cứng hoặc một giải pháp phần mềm) quyết định tài nguyên nào hiện tại có khả năng xử lý lưu lượng mạng và công việc tốt nhất Một số thuật toán cân bằng tải phổ biến bao gồm:

Round Robin: Bộ cân bằng tải định hướng yêu cầu đến máy chủ đầu tiên trong danh sách Bộ

cân bằng tải di chuyển xuống danh sách đến máy chủ cuối cùng và sau đó bắt đầu lại từ đầu Phương pháp này dễ triển khai và được sử dụng rộng rãi, nhưng nó không xem xét nếu máy chủ có cấu hình phần cứng khác nhau.

Least Connection: Trong trường hợp này, bộ cân bằng tải chọn máy chủ với ít kết nối hoạt

động nhất Khi có một yêu cầu đến, bộ cân bằng tải tìm máy chủ với ít kết nối hiện tại nhất Phương pháp này giúp tránh quá tải máy chủ web khi phiên người dùng cuối kéo dài trong thời gian dài.

Source IP Hash: Thuật toán này xác định máy chủ nào sẽ được chọn dựa trên địa chỉ IP nguồn

của yêu cầu Bộ cân bằng tải tạo một khóa băm duy nhất bằng cách sử dụng địa chỉ IP nguồn và đích.

Mặc dù cân bằng tải quan trọng, nhưng quá trình này một mình không đủ để đảm bảo tính sẵn sàng cao Nếu bộ cân bằng chỉ định lưu lượng để giảm tải trên một máy tính duy nhất, điều đó không làm cho toàn bộ hệ thống có tính sẵn sàng cao.

Tương tự như tất cả các thành phần khác trong hệ thống có tính khả dụng cao, bộ cân bằng tải cũng cần tính dự phòng để ngăn nó trở thành một điểm hỏng duy nhất.

1.2.3 Reliability

Độ tin cậy (Reliability) đề 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 mean time between failures (MTBF) và mean time to repair (MTTR) như một thông số để đo lường độ tin cậy.

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

1.2.4 Maintainability

Ngoài việc xây dựng một hệ thống, một trong những nhiệm vụ chính sau đó là duy trì hệ thống bằng cách tìm và sửa lỗi, thêm các chức năng mới, cập nhật nền tảng của hệ thống và đảm bảo hoạt động mượt mà của hệ thống Một trong những đặc điểm nổi bật để xác định các yêu cầu của một thiết kế hệ thống xuất sắc là khả năng bảo trì Chúng ta có thể chia khái niệm bảo trì thành ba khía cạnh cơ bản sau:

• Khả năng vận hành (Operability): Đây là điều dễ dàng trong việc đảm bảo rằng hệ

thống hoạt động mượt mà trong điều kiện bình thường và đạt được điều kiện bình thường dưới tình huống có lỗi

• Sự rõ ràng (Lucidity): Điều này liên quan đến sự đơn giản của mã nguồn Mã nguồn

càng đơn giản, thì việc hiểu và bảo trì nó càng dễ dàng, và ngược lại

• Khả năng thay đổi (Modifiability): Đây là khả năng của hệ thống để tích hợp các tính

năng được thay đổi, mới và không được dự kiến mà không gây rắc rối nào

Đo lường khả năng bảo trì

Khả năng 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

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.

Trong đó:

• Mean Time To Repair: Thời gian trung bình để sửa chữa

• Total Maintenance Time: Tổng thời gian bảo trì

• 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ể.

Mối quan hệ giữa Maintainability và Reliability

Khả năng bảo trì có thể được định nghĩa rõ hơn trong mối quan hệ mật thiết với độ tin cậy Sự khác biệt duy nhất giữa chúng là mối quan tâm Khả năng bảo trì quan tâm đến thời gian để sửa chữa, trong khi độ tin cậy quan tâm đến cả thời gian để sửa chữa và thời gian để xảy ra lỗi Kết hợp phân tích khả năng bảo trì và độ tin cậy có thể giúp chúng ta có cái nhìn về khả năng sẵn sàng, thời gian chết, và thời gian hoạt động.

1.2.5 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ị

• 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.

Định Lý CAPCác mô hình về yêu cầu tính nhất quán của một hệ thống:

• Strong Consistency (Tính nhất quán mạnh): Đây là mô hình nhất quán mạnh nhất, cam

kết rằng mọi thao tác trên dữ liệu sẽ được tức thì phản ánh bởi tất cả các máy chủ trong cụm Điều này đồng nghĩa với việc client luôn nhận được dữ liệu mới nhất Mô hình này đặt tính sẵn sàng (availability) sang một bên để đảm bảo tính nhất quán giữa các máy chủ

• Weak Consistency (Tính nhất quán yếu, hoặc tính nhất quán theo sự kiện - Eventual Consistency): Trong mô hình này, các thao tác có thể không được tức thì phản ánh bởi

tất cả các máy chủ trong cụm, và do đó, các yêu cầu đọc từ phía client có thể không thấy dữ liệu mới nhất và có thể trả về dữ liệu cũ Mô hình này đặt tính sẵn sàng cao lên trên tính nhất quán

1.2.6 Fault tolerance

1.2.6.1 Các khái niệm về fault tolerance

• Failure: cả hệ thống bị gián đoạn, không hoạt động

• Fault: một phần của hệ thống không hoạt động

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

 Crash-stop: server sập và dừng hoàn toàn, không hồi phục

 Crash-recovery: server sập và sau đó hồi phục trở lại

 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

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

• 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 1.2.6.3 Các kĩ thuật Fault tolerance

Sao chép (Replication)

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 chống lỗi 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.

Chúng ta cũng có thể cập nhật dữ liệu trong các bản sao bất đồng bộ khi chúng ta có thể chấp nhận tính nhất quán theo sự kiện (eventual consistency), dẫn đến việc đọc dữ liệu lỗi thời cho đến khi tất cả các bản sao hội tụ Do đó, có một sự cân đối giữa cả hai phương pháp tính nhất quán Chúng ta phải hy sinh tính sẵn sàng hoặc tính nhất quán trong trường hợp xảy ra sự cố, điều này là một thực tế được nêu rõ trong định lý CAP.

Kiểm tra (Checkpointing)

Checkpointing là một kỹ thuật giúp lưu trạng thái của hệ thống vào bộ nhớ lưu trữ ổn định khi trạng thái của hệ thống đang trong trạng thái nhất quán Checkpointing được thực hiện trong nhiều giai đoạn khác nhau tại các khoảng thời gian khác nhau Mục đích chính là lưu trạng thái tính toán tại một điểm nhất định Khi một lỗi xảy ra trong hệ thống, chúng ta có thể lấy dữ liệu tính toán cuối cùng từ bản checkpoint trước đó và tiếp tục công việc từ đó.

Checkpointing cũng đối mặt với cùng một vấn đề mà chúng ta gặp trong việc sao chép Khi hệ thống phải thực hiện checkpointing, nó đảm bảo rằng hệ thống đang trong trạng thái nhất quán, có nghĩa là tất cả các quy trình (processes) đều bị tạm dừng, trừ các quy trình đọc (read processes) mà không làm thay đổi trạng thái của hệ thống Loại checkpointing này được gọi là checkpointing đồng bộ (synchronous checkpointing) Ngược lại, checkpointing trong trạng thái không nhất quán dẫn đến vấn đề không nhất quán dữ liệu

Checkpointing trong trạng thái nhất quán và trạng thái không nhất quán Trong hình minh họa bên trái, các bản checkpoint đầu tiên tại quy trình J và I là nhất quán vì m1 đã được gửi và nhận sau khi các checkpoint này được thực hiện Ngược lại, trong hình minh họa bên

phải, bản checkpoint đầu tiên tại quy trình J không biết về m1 trong khi bản checkpoint đầu tiên tại quy trình I ghi lại việc nhận tin nhắn m1 Do đó, trạng thái này là không nhất quán.

Trạng thái nhất quán: Trong ví dụ ở trên, không có sự trao đổi thông tin giữa các quy trình khi hệ thống thực hiện checkpointing Tất cả các quy trình đều đang gửi hoặc nhận tin nhắn trước và sau khi thực hiện checkpointing Trạng thái này của hệ thống được gọi là trạng thái nhất quán Lưu ý rằng trong ví dụ bên trái, việc gửi và nhận bất kỳ tin nhắn nào cũng được ghi lại trong các checkpoint tương ứng Ví dụ, việc gửi và nhận tin nhắn m1 được ghi lại trong hình bên trái, trong khi trong hình bên phải, bản checkpoint trên quy trình J không ghi lại việc gửi nó, trong khi quy trình I lại ghi lại việc nhận nó Nếu cả hai hệ thống đều gặp lỗi tại điểm đó, và chúng ta sử dụng các checkpoint để phục hồi, thì một checkpoint sẽ biết về việc nhận m1, trong khi checkpoint khác sẽ không có bản ghi về việc gửi nó.

Trạng thái không nhất quán: Hình ảnh cũng cho thấy các quy trình giao tiếp qua tin nhắn khi hệ thống thực hiện checkpointing Điều này cho thấy trạng thái không nhất quán, vì khi chúng ta có một checkpoint đã lưu trước đó, Quy trình I sẽ có một tin nhắn (m1) và Quy trình J không có bản ghi về việc gửi tin nhắn.

1.2.6.3 Byzantine fault

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 component có thể bị lỗi và không có thông tin chính xác về việc liệu component đó 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ự thất bại thảm hại 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.

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.

Không có cách để một tướng 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)

Chương 2: Load balancer 2.1 Load balancer

Load balancer (cân bằng tải) là một thành phần quan trọng trong kiến trúc hệ thống phân tán, được sử dụng để phân phối công việc vào các máy chủ hoặc các thành phần xử lý khác nhau trong một hệ thống Mục tiêu của load balancer là tối ưu hóa hiệu suất, tăng tính sẵn sàng và đảm bảo ổn định cho hệ thống

2.2 Phân loại

Có nhiều loại load balancer khác nhau, bao gồm:

2.2.1 Hardware & Software

Hardware load balancer (HLB) là một thiết bị phần cứng có hệ điều hành chuyên dụng giúp phân phối lưu lượng truy cập ứng dụng web trên một cụm máy chủ ứng dụng Để đảm bảo hiệu suất tối ưu, hardware load balancer phân phối lưu lượng theo quy tắc tùy chỉnh để máy chủ ứng dụng không bị quá tải HLB hoạt động ở tầng 4 (Transport Layer) hoặc tầng 7 (Application Layer) trong mô hình OSI

Softwarer load balancer (SLB) là các ứng dụng phần mềm chạy trên máy chủ và thực hiện chức năng cân bằng tải Các ví dụ phổ biến bao gồm Nginx, HAProxy và Apache HTTP Server

Sự khác biệt rõ ràng nhất giữa HLB và SLB là HLB yêu cầu các thiết bị phần cứng, trong khi SLB chỉ cần được cài đặt trên máy chủ hoặc máy ảo Một sự khác biệt quan trọng khác giữa HLB và SLB nằm ở khả năng mở rộng Khi lưu lượng mạng tăng lên, các trung tâm dữ liệu phải cung cấp đủ bộ cân bằng tải để đáp ứng nhu cầu cao điểm Đối với nhiều doanh nghiệp, điều này có nghĩa là hầu hết các HLB sẽ không hoạt động cho đến thời điểm có lưu lượng mạng cao Mặt khác, SLB có thể mở rộng quy mô một cách linh hoạt để đáp ứng nhu cầu Cho dù lưu lượng truy cập mạng thấp hay cao, SLB có thể tự động điều chỉnh quy mô theo thời gian thực một cách đơn giản, loại bỏ chi phí khi cung cấp các HLB quá mức và sự gia tăng lưu lượng truy cập bất ngờ Trên thực tế, các HLB không tương thích với môi trường cloud, trong khi SLB lại tương thích với nền tảng đám mây

2.2.2 Tầng xử lý

Load balancer có thể được phân loại dựa trên tầng xử lý mà chúng hoạt động trong kiến trúc mạng Có hai phân loại chính cho load balancer trên tầng xử lý:

Transport Load Balancer

Load balancer sử dụng thông tin ở tầng vận chuyển làm cơ sở để quyết định cách phân phối các yêu cầu của máy khách trên một nhóm máy chủ dựa trên thông tin về địa chỉ IP nguồn và đích cũng như các port được ghi trên header của packet mà không xem xét nội dung của packet Khi load balancer nhận được yêu cầu và đưa ra quyết định cân bằng tải, nó cũng thực hiện Network Address Translation (NAT) trên gói yêu cầu, thay đổi địa chỉ IP đích từ địa chỉ IP đích của gói thành địa chỉ của máy chủ được chọn trên mạng nội bộ Tương tự, trước khi chuyển tiếp phản hồi của máy chủ đến máy khách, load balancer sẽ thay đổi địa chỉ nguồn được ghi trong header của gói từ địa chỉ IP của máy chủ thành địa chỉ IP của chính nó Transport Load Balancer là một phương pháp phổ biến để xử lý lưu lượng khi phần cứng thông thường chưa mạnh mẽ như hiện nay và sự tương tác giữa máy khách và máy chủ ứng dụng ít phức tạp hơn nhiều Nó đòi hỏi ít tính toán hơn so với các phương pháp cân bằng tải phức tạp hơn (chẳng hạn như Application Load Balancer), nhưng CPU và bộ nhớ hiện nay đủ nhanh và rẻ nên lợi thế về hiệu suất của Transport Load Balancer trở nên không đáng kể hoặc không còn phù hợp trong hầu hết các tình huống

Application Load Balancer

Application Load Balancer (ALB) hoạt động ở tầng ứng dụng trong mô hình OSI, sử dụng các giao thức như HTTP và SMTP để đưa ra quyết định dựa trên nội dung của request Thay vì chỉ chuyển tiếp, bộ cân bằng tải sẽ ngắt luồng mạng, thực hiện giải mã nếu cần, kiểm tra và đưa ra quyết định định tuyến dựa trên nội dung request, khởi tạo kết nối TCP mới đến máy chủ thích hợp và ghi yêu cầu vào máy chủ ALB thường được triển khai trong các môi trường đám mây như Amazon Web Services (AWS) thông qua dịch vụ Elastic Load Balancer (ELB) Nó cung cấp một giải pháp linh hoạt và mạnh mẽ để cân bằng tải và ổn định hoạt động của các ứng dụng web

2.3 Thuật toán

Load balancer có thể được phân loại dựa trên các thuật toán cân bằng tải mà chúng sử dụng để quyết định cách phân phối yêu cầu Dưới đây là một số phân loại phổ biến của load balancer dựa trên thuật toán:

Round Robin

Thuật toán này phân phối yêu cầu theo cách lần lượt đến các máy chủ xử lý tải theo một thứ tự xác định Mỗi yêu cầu mới sẽ được chuyển tiếp đến máy chủ tiếp theo trong danh sách Đây là một thuật toán đơn giản và công bằng, nhưng không xem xét tải của các máy chủ

Weighted Round Robin

Đây là thuật toán mở rộng của thuật toán Round Robin Đối với Round Robin, server phải xử lí khối lượng request là ngang nhau Do đó, server với khả năng xử lí thấp hơn có thể sẽ bị overload và nhanh chóng quá tải trong khi server mạnh hơn thì đang nhàn rỗi huật toán này gán một trọng số (weight) cho mỗi máy chủ, xác định tỷ lệ phân phối tải giữa các máy chủ Máy chủ có trọng số cao sẽ nhận được nhiều yêu cầu hơn so với máy chủ có trọng số thấp

Least Connection

Thuật toán này chọn máy chủ có số kết nối hiện tại ít nhất để chuyển tiếp yêu cầu tới Điều này giúp phân phối tải một cách công bằng hơn dựa trên tình trạng thực tế của máy chủ

Fastest Response Time

Thuật toán này chọn máy chủ có thời gian phản hồi (response time) thấp nhất để chuyển tiếp yêu cầu tới Thời gian đáp ứng được xác định bằng khoảng thời gian giữa gửi một gói tin đến server và thời điểm nhận được gói tin trả lời Việc gửi và nhận này do Load Balancer đảm nhiệm

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

2.4 Patterns

Server-side load balancing và client-side load balancing đề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:

• Server-side load balancing: Server-side load balancing đượ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 Load balancer sẽ nhận các yêu cầu từ client 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 đó, load balancer sẽ chuyển tiếp yêu cầu đến máy chủ backend được chọn và trả về kết quả cho client

• Client-side load balancing: Client-side load balancing được thực hiện bởi client

Client 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 đó, client 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ề

Cả hai loại load balancing đều có ưu và nhược điểm riêng Server-side load balancing đơn giản hơn và dễ triển khai hơn, nhưng có thể tạo ra bottleneck và tăng độ trễ Client-side load balancing linh hoạt hơn và giảm độ trễ, nhưng phức tạp hơn và đòi hỏi client phải có khả năng thực hiện load balancing

2.5 Tăng availability của hệ thống

Single point of failure (SPOF) là một điểm trong hệ thống mà nếu nó gặp sự cố, toàn bộ hệ thống sẽ ngừng hoạt động Việc có một SPOF trong hệ thống có thể dẫn đến nhiều vấn đề, bao gồm:

• Mất dữ liệu: Nếu SPOF là một thiết bị lưu trữ dữ liệu, sự cố có thể dẫn đến mất dữ liệu

quan trọng

• Thời gian chết: Khi SPOF gặp sự cố, toàn bộ hệ thống sẽ ngừng hoạt động, dẫn đến

thời gian chết và ảnh hưởng đến trải nghiệm người dùng

• Mất doanh thu: Thời gian chết có thể dẫn đến mất doanh thu, đặc biệt đối với các

doanh nghiệp phụ thuộc vào hệ thống để bán hàng hoặc cung cấp dịch vụ

• Mất uy tín: Sự cố liên tục có thể làm giảm uy tín của doanh nghiệp và ảnh hưởng đến

lòng tin của khách hàng

Để giảm thiểu rủi ro từ SPOF, ta có thể áp dụng một số phương pháp để tạo ra bản sao của các thành phần trong hệ thống rồi load balance giữa các instance đó

Ta có thể khắc phục SPOF cho database sử dụng Sharding và replication Sharding và replication là hai phương pháp phân tán dữ liệu và tài nguyên trong các hệ thống lớn, không chỉ áp dụng cho cơ sở dữ liệu mà còn cho các dịch vụ khác

• Sharding: Sharding là một phương pháp phân chia dữ liệu hoặc tài nguyên lớn thành

nhiều phần nhỏ hơn và lưu trữ chúng trên nhiều máy chủ khác nhau Mỗi máy chủ sẽ lưu trữ một phần của dữ liệu hoặc tài nguyên và chỉ xử lý các yêu cầu liên quan đến phần đó Sharding giúp tăng khả năng mở rộng và cải thiện hiệu suất của hệ thống bằng cách giảm gánh nặng cho từng máy chủ và cho phép xử lý song song các request • Replication: Replication là một phương pháp sao chép dữ liệu hoặc tài nguyên từ một

máy chủ sang một hoặc nhiều máy chủ khác Mục đích của replication là tăng độ tin cậy và khả dụng của hệ thống bằng cách cung cấp các bản sao dự phòng của dữ liệu hoặc tài nguyên Khi một máy chủ gặp sự cố, các máy chủ khác có thể tiếp tục hoạt động và đảm bảo availability của dịch vụ

Load balancer có vai trò quan trọng trong việc tăng tính sẵn sàng (availability) của hệ thống

Bằng cách chia sẻ công việc và tải trọng, load balancer đảm bảo rằng không có máy chủ nào bị quá tải, giúp tránh tình trạng hệ thống bị chậm hoặc gặp sự cố Nếu một máy chủ gặp vấn đề, load balancer có thể tự động loại bỏ nó khỏi danh sách máy chủ hoạt động, từ đó giữ cho hệ thống vẫn hoạt động một cách liên tục

từ phía client hoặc từ một nguồn lưu lượng nhất định Điều này giúp đảm bảo rằng hệ thống không bị quá tải do lưu lượng truy cập đột ngột tăng cao hoặc tấn công từ phía người dùng

• Giám sát và phát hiện sự cố: Load balancer thường được tích hợp với các tính năng giám sát để theo dõi trạng thái và hiệu suất của các máy chủ hoặc tài nguyên Nếu một máy chủ hoặc tài nguyên trở nên không hoạt động hoặc gặp sự cố, load balancer có thể phát hiện và tự động loại bỏ nó khỏi quá trình phân phối tải, giữ cho hệ thống hoạt động bình thường

trên các tiêu chí như tình trạng máy chủ, vị trí địa lý, hoặc khối lượng công việc Điều này cho phép load balancer đưa ra quyết định phân phối tải dựa trên yếu tố cụ thể để tối ưu hóa hiệu suất và tính sẵn sàng của hệ thống

• Cân bằng tải động: Load balancer có thể tự động điều chỉnh phân phối tải dựa trên tình trạng hoạt động của các máy chủ hoặc tài nguyên Nếu một máy chủ hoặc tài nguyên bắt đầu quá tải, load balancer có thể chuyển hướng yêu cầu đến các máy chủ hoạt động

Chương 3: Caching

Glossary

Cache hit: Khi có bất kỳ yêu cầu nào đến yêu cầu dữ liệu dựa trên một định danh duy nhất

hoặc điều kiện nào đó và nếu dữ liệu đó đã tồn tại trong bộ nhớ cache, thì yêu cầu này sẽ được phục vụ từ bộ nhớ cache thay vì truy vấn vào cơ sở dữ liệu (DB) Trạng thái này có thể được gọi là trạng thái Cache Hit

Cache miss: Đây là trái ngược hoàn toàn với Cache hit, yêu cầu không được phục vụ từ bộ

nhớ cache do không có sẵn dữ liệu yêu cầu trong bộ nhớ cache, vì vậy yêu cầu sẽ được phục vụ bằng phản hồi nhận được từ cuộc gọi bên ngoài đến cơ sở dữ liệu (DB) qua mạng hoặc bất kỳ nguồn dữ liệu nào khác

3.1 Tổng quan về caching

Load balancing giúp hệ thống mở rộng theo chiều ngang bằng cách ngày càng tăng số lượng các máy chủ, nhưng Caching lại là cách để sử dụng tài nguyên (resource) hiệu quả hơn từ đó resource cần cung cấp giảm đi, nhằm tiết kiệm resource và giảm chi phí của hệ thống

Để làm được điều này, hệ thống sẽ cung cấp một vùng nhớ đệm (cache) để chứa những dữ liệu được request nhiều lần mà không thường xuyên thay đổi vào đó, từ đó hệ thống sẽ lấy dữ liệu từ bộ nhớ cache mà không truy cập vào bộ nhớ chính Điều này giúp bộ nhớ chính sẽ được giảm tải đi từ đó năng lực của nó tăng lên

Bộ nhớ cache được sử dụng rất rộng rãi trong mọi thành phần của hệ thống như trong phần cứng (hardware) như RAM/CPU Cache, hệ điều hành (operating systems), trình duyệt web (web browsers), web applications v.v… Bộ nhớ cache giống như một bộ nhớ ngắn hạn (short- term memory) nó có giới hạn về kích cỡ, nhưng thường nhanh hơn rất nhiều lần bộ nhớ chính Về kiến trúc phần mềm thì Cache có thể tồn tại ở hầu hết các thành phần, nhưng chủ yếu nó tồn tại ở phần thao tác với dữ liệu như Database Layer, giúp trả về dữ liệu nhanh hơn mà không cần tốn chi phí để truy cập vào Database, hay ở phần Front-end để Cache những resource tĩnh như js, css, image file bằng cách dùng CDN

3.2 Các pattern trong caching

3.2.1 Local cache

Local cache là một cơ chế lưu trữ dữ liệu tạm thời được sử dụng trong các ứng dụng phần

mềm để lưu trữ dữ liệu được truy cập thường xuyên hoặc được sử dụng gần đây ở một vị trí gần hơn và truy cập nhanh hơn nguồn dữ liệu ban đầu Mục đích chính của bộ đệm cục bộ là cải thiện hiệu suất và khả năng phản hồi của ứng dụng bằng cách giảm thời gian và tài nguyên cần thiết để tìm nạp dữ liệu từ nguồn chậm hơn hoặc từ xa, chẳng hạn như cơ sở dữ liệu, dịch vụ web hoặc hệ thống tệp

3.2.1.1 Local browser caching

Nếu bạn đang xây dựng một ứng dụng web được truy cập từ trình duyệt, bạn có thể sử dụng lưu trữ cục bộ để lưu trữ dữ liệu key-value trong trình duyệt của người dùng

Ví dụ, sau khi người dùng xác thực vào dịch vụ của bạn, bạn có thể lưu trữ một số thông tin về

ID và hồ sơ của người dùng được sử dụng để truy cập dịch vụ để tăng tốc hiển thị ứng dụng của bạn khi xem lại lần sau

Lợi ích của Local browser caching là tính đơn giản của nó, vì API lưu trữ cục bộ đã được bao

gồm trong các trình duyệt web hiện đại Ngoài ra, không cần lo lắng về việc cung cấp cache trước hoặc sợ không có đủ không gian, vì bạn đang thuê không gian trên máy tính của người dùng để lưu trữ dữ liệu này

Nhược điểm của Local browser caching là nó chỉ hữu ích trong trường hợp cụ thể Dữ liệu đã

được lưu trữ không áp dụng cho người dùng khi họ sử dụng thiết bị khác hoặc thậm chí sử dụng một phiên bản trình duyệt khác trên thiết bị đó Hơn nữa, không có cơ chế cho nguồn dữ liệu backend của bạn để tự động vô hiệu hóa các mục trong local cache nếu dữ liệu gốc đã thay đổi

3.2.1.1 Local backend caching

Với Local backend caching , các backend server instances của bạn có thể lưu trữ các network

response hoặc dữ liệu trung gian từ các hệ thống khác Dữ liệu này thường được lưu trữ trong bộ nhớ trong ứng dụng của bạn, chẳng hạn như trong các bản đồ key-value trong ngôn ngữ lập trình của bạn Khi backend server instances của bạn cần truy cập dữ liệu đó, nó sẽ trước tiên kiểm tra đối tượng trong bộ nhớ, sau đó sử dụng nguồn dữ liệu chính nếu giá trị đã lưu trữ không có

Ưu điểm của chiến lược này nằm trong sự dễ sử dụng và tính đơn giản của nó Nếu bạn có dữ liệu thường xuyên truy cập và tồn tại trong thời gian dài, bạn có thể nhanh chóng lưu trữ nó trên từng server instances mà không cần xây dựng và vận hành cơ sở hạ tầng bổ sung Điều này có thể hoạt động tốt cho dữ liệu cấu hình hoặc dữ liệu chậm

Nhược điểm của chiến lược lưu trữ này là nó ít hiệu quả hơn so với các phương pháp lưu trữ từ xa Mỗi backend instance sẽ có bộ nhớ cache riêng biệt Nếu bạn có một tập dữ liệu rộng lớn cần lưu trữ, và bạn chỉ lưu trữ nó sau khi nó đã được yêu cầu một lần trên phiên bản đó, cache hit rate của bạn có thể khá thấp

3.2.2 Distributed cache

Một distributed cache là một cache có dữ liệu của nó được phân tán trên một số nút trong một

(a) cụm, (b) trên một số cụm khác nhau hoặc (c) trên một số trung tâm dữ liệu khác nhau trên khắp thế giới