đồ án 2 tìm hiểu về các công nghệ backend

Chương 1: Tổng quan về thiết kế hệ thống Thiết kế hệ thống là quá trình định rõ các thành phần, cách chúng tương tác, các giao diện lập trình ứng dụng APIs, và mô hình dữ liệu để xây dựn

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

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

TÌM HIỂU VỀ CÁC CÔNG NGHỆ BACKEND Giảng viên hướng dẫn: ThS Nguyễn Công Hoan Sinh viên thực hiện 1: 20521200 - Nguyễn Trung Đức Sinh viên thực hiện 2: 20521197 - Nguyễn Ngọc Đức

TP HỒ CHÍ MINH, 2023

MỤC LỤC

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

3.6 Tăng availability của hệ thống 53

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

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

Thiết kế hệ thống là quá trình định rõ các thành phần, cách chúng tương tác, các giao diện lập trình ứng dụng (APIs), và mô hình dữ liệu để xây dựng các hệ thống với quy

mô lớn, đáp ứng đầy đủ yêu cầu chức năng và phi chức năng

Trong quá trình thiết kế hệ thống, chúng tôi tận dụng các khái niệm từ lĩnh vực mạng máy tính, tính toán song song, và hệ thống phân tán để xây dựng những hệ thống có khả năng mở rộng và hiệu suất cao

thêm tính năng mới mà không làm ảnh hưởng đến tính ổn định và hiệu suất

Mục tiêu chính của thiết kế hệ thống là tạo ra những hệ thống hiệu quả, đáng tin cậy và

dễ bảo trì Hệ thống hiệu quả là những hệ thống linh hoạt, có khả năng đáp ứng đầy đủ nhu cầu của người dùng và doanh nghiệp Hệ thống đáng tin cậy được xây dựng với khả năng xử lý lỗi, sự cố và sai sót Hệ thống dễ bảo trì là những hệ thống linh hoạt, dễ mở rộng hoặc thu nhỏ, và có khả năng

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 những hệ thống nhỏ và tương đối đơn giản, quá trình thiết kế và kiến trúc không gặp nhiều phức tạp Những hệ thống này thường dễ tổ chức, vận hành, và bảo trì, đồng thời không có quá nhiều thành phần phức tạp

Đối với những hệ thống này, có nhiều mô hình phát triển phần mềm phù hợp với yêu cầu cụ thể của chúng Các kiến trúc như client-server, layer, monolithic đều là những lựa chọn linh hoạt, phản ánh sự đa dạng trong cách triển khai mô hình phần mềm

Việc sử dụng các mô hình như client-server giúp tách biệt giữa phần giao diện người dùng và phần xử lý logic, giảm sự phức tạp và tăng tính linh hoạt Kiến trúc layer thường được ưa chuộng với những hệ thống có nhiều tầng chức năng, giúp quản lý và phát triển một cách hiệu quả Trong khi đó, kiến trúc monolithic, mặc dù đơn giản, nhưng lại thích hợp cho những ứng dụng nhỏ với quy mô và yêu cầu thấp

Tổng cộng, sự linh hoạt trong lựa chọn kiến trúc giúp phát triển những hệ thống nhỏ một cách hiệu quả, tùy thuộc vào yêu cầu cụ thể và quy mô của dự án

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 là chúng đều sử dụng mô hình tập trung, điều này mang lại một số thách thức cụ thể:

Về Hiệu Suất: Các hạn chế về vật lý của phần cứng như việc nâng cấp CPU, RAM, hay

ổ cứng đặt ra giới hạn đối với một máy chủ cụ thể Đối với các hệ thống lớn, có mô hình nghiệp vụ phức tạp và số lượng người sử dụng lớn, các mô hình kiến trúc trên có thể gặp khó khăn trong việc cung cấp dịch vụ một cách kịp thời, chính xác, và ổn định Nâng cấp hiệu suất của một máy chủ đơn lẻ trở nên đắt đỏ sau một ngưỡng nhất định

Về Mở Rộng: Quản lý và xử lý dữ liệu đóng góp vào giá trị của hệ thống phần mềm Khi lượng khách hàng tăng, hệ thống phải 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 chỉ dựa vào một máy chủ duy nhất sẽ đạt đến giới hạn mở rộng

Về Sẵn Sàng: Dịch vụ trực tuyến ngày nay yêu cầu hoạt động liên tục (24/7), điều này

là một thách thức đối với các hệ thống Đối với các dịch vụ đặt ra yêu cầu về "sẵn sàng" 5-9, tức là hoạt động 99.999% thời gian, hệ thống tập trung trên một máy chủ sẽ gặp khó khăn khi phải đối mặt với hàng nghìn, hàng chục nghìn, thậm chí triệu yêu cầu cùng lúc

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ề chức năng:

● Stream videos

● Upload videos

● Search videos according to titles

● Like and dislike videos

● Add comments to videos

● View thumbnails

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

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 (Khả năng mở rộng) đề cập đến khả năng của hệ thống, quy trình, hoặc mạng

để mở rộng và đáp ứng nhu cầu gia tăng về công việc theo thời gian của mô hình kinh doanh Mô hình kinh doanh có thể cần mở rộng quy mô vì nhiều lý do, bao gồm tăng về khối lượng dữ liệu lưu trữ và số lượng yêu cầu công việc

Ví dụ về Tăng Về Khối Lượng Dữ Liệu Lưu Trữ (Data Storage):

Khi hệ thống phải đối mặt với một lượng lớn dữ liệu, khả năng mở rộng về kích thước (Size Scalability) là quan trọng Một trang web có thể thêm nhiều người dùng mà không làm suy giảm tốc độ và hiệu suất

Ví dụ về Tăng Về Số Lượng Yêu Cầu và Công Việc (Process/Request):

Một dịch vụ thương mại điện tử có thể phải đối mặt với việc tăng số lượng truy cập hay đặt hàng Scalability cần đảm bảo rằng hệ thống có thể đáp ứng nhu cầu mở rộng này

mà không làm giảm hiệu suất

Các Khía Cạnh Mở Rộng:

Tính mở rộng về Kích Thước (Size Scalability):

● Khả năng tăng cường kích thước của hệ thống 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 người dùng mà không làm suy giảm hiệu suất

Tính mở rộng Quản Lý (Administrative Scalability):

● Nhiều tổ chức hoặc người dùng có thể sử dụng hệ thống mà không làm phức tạp 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 làm phức tạp quản lý tài khoản

Tính mở rộng Địa Lý (Geographical Scalability):

● Hệ thống có thể phục vụ một vùng địa lý rộng mà không làm suy giảm

độ trễ hay hiệu quả

● Ví dụ: Dịch vụ trực tuyến phải phục vụ khách hàng trên toàn thế giới mà không làm giảm hiệu suất

Cách Thực Hiện Mở Rộng:

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

Mở Rộng Theo Chiều Dọc (Vertical Scaling) - Scaling Up:

● Nâng cấp hiện tại của server bằng cách nâng cấp CPU, RAM, Storage

● Đắt đỏ và có giới hạn về cấu hình vật lý.

Mở Rộng Theo Chiều Ngang (Horizontal Scalability) - Scaling Out:

● Tăng số lượng máy chủ hoặc nodes trong mạng

● Giải pháp chi phí hiệu quả và linh hoạt hơn

Scalability là yếu tố quan trọng để đảm bảo hệ thống có thể đáp ứng nhu cầu ngày càng tăng mà không làm suy giảm hiệu suất

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) đo lường thời gian mà một dịch vụ hoặc hệ thống

có thể truy cập và hoạt động trong điều kiện bình thường, thường được biểu diễn dưới dạng phần trăm Chỉ số này đo lường mức độ hoạt động và xử lý của

hệ thống khi nó đang ở trạng thái bình thường trong một khoảng thời gian nhất định Ví dụ, nếu một dịch vụ có khả dụng 100%, điều này thể hiện 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 mà không gặp sự cố

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

Để đảm bảo tính dự phòng và loại bỏ các tác nhân bị hỏng, cần thực hiện các biện pháp dự phòng ở mọi cấp độ hệ thống Mỗi thành phần quan trọng của hệ thống cần

có một bản sao dự phòng để đảm bảo khả năng xử lý sự cố một cách nhanh chóng và hiệu quả

● Bao gồm gấp đôi số lượng mọi thành phần cần thiết để chạy hệ thống

● Cung cấp một bản sao dự phòng hoàn toàn hoạt động của toàn bộ hệ thống

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

Để đảm bảo tính sẵn sàng cao của hệ thống, việc có kế hoạch bảo vệ dữ liệu và phục hồi sau khi gặp sự cố là không thể phủ nhận Chiến lược sao lưu dữ liệu

trở thành yếu tố cực kỳ quan trọng, và công ty cần có khả năng phục hồi nhanh chóng sau các sự cố về lưu trữ như mất dữ liệu hoặc lỗi dữ liệu

Sử dụng sao chép dữ liệu (data replication) là lựa chọn tối ưu nếu doanh

nghiệp đặt mức độ quan trọng cao về 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, không thể chấp nhận mất dữ liệu Việc triển khai sao lưu cần đảm bảo quyền truy cập đến các bản ghi dữ liệu mới nhất để

có một quá trình phục hồi mượt mà và chính xác khi có sự cố với hệ thống chính

● RTO (Recovery Time Objective): Thời gian mà bạn đặt ra để phục hồi hệ

thống sau khi có sự cố RTO càng ngắn, hệ thống sẽ quay trở lại hoạt động càng nhanh chóng

● RPO (Recovery Point Objective): 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 RPO đo lường khoảng thời gian

mà dữ liệu có thể mất trong trường hợp có sự cố Mứ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 Những yếu tố này cùng nhau tạo nên một chiến lược hiệu quả để bảo vệ dữ liệu

và đảm bảo tính sẵn sàng của hệ thống

c. Failover

Dự phòng và sao lưu chỉ là một phần của chiến lược đảm bảo tính sẵn sàng cao của

hệ thống Để đạt được mức độ cao này, hệ thống cần có cơ chế phát hiện lỗi và thực hiện các hành động phù hợp khi một trong các thành phần gặp sự cố hoặc trở nên không khả dụng

Hệ thống với tính khả dụng cao thường 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 xảy ra lỗi Quá trình này được thực hiện thông qua

cơ chế failover, có hai hình thức chủ động-thụ động (active-passive) và chủ động-chủ động (active-active)

● Chỉ có server chủ động xử lý yêu cầu Còn gọi là failover chủ-tớ slave)

(master-Failover chủ động-chủ động (Active-Active):

● Cả hai server đều xử lý yêu cầu, tải được cân bằng giữa chúng

● Nếu ở chế độ công khai, DNS cần biết về các IP công khai của cả hai server để hỗ trợ client-side load balancing

● Nếu ở chế độ giao tiếp nội bộ, application logic cần biết về cả hai server

● Còn gọi là failover chủ-chủ (master-master)

Tổng cộng, mô hình failover này đảm bảo rằng hệ thống có thể duy trì tính sẵn sàng cao mà không gián đoạn quá mức khi sự cố xảy ra

d Load Balancing

Cân bằng tải (Load balancing) đóng vai trò quan trọng trong việc đảm bảo tính sẵn sàng cao của hệ thống khi đối mặt với nhiều người dùng truy cập đồng thời Nó giúp phân phối công việc đều giữa các tài nguyên hệ thống, bao gồm việc 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 giải pháp phần mềm, đóng vai trò 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:

Least Connection:

● Chọn máy chủ với ít kết nối hoạt động nhất

● Giúp tránh quá tải máy chủ web khi có phiên người dùng kéo dài

Source IP Hash:

● Xác định máy chủ dựa trên địa chỉ IP nguồn của yêu cầu

● 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 là một thành phần quan trọng, nhưng không đủ để đảm bảo tính sẵn sàng cao Cần tính dự phòng để ngăn bộ cân bằng tải trở thành một điểm hỏng duy nhất, đồng thời đảm bảo rằng lưu lượng được phân phối một cách hiệu quả trên toàn hệ thống

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 hệ thống, một trong những trách nhiệm chính quan trọng 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 và đảm bảo hoạt động mượt mà của hệ thống Một trong những điểm chính để 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ì Khái niệm bảo trì có thể được chia thành ba khía cạnh cơ bản:

Khả năng vận hành (Operability): Điều này liên quan đến 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): Liên quan đến sự đơn giản của mã nguồn Mã nguồn càng đơn giản, việc hiểu và bảo trì nó càng dễ dàng

Khả năng thay đổi (Modifiability): 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

Đo lường khả năng bảo trì thường được thực hiện bằng xác suất mà dịch vụ sẽ khôi phục lại chức năng của nó trong một khoảng thời gian cụ thể sau khi xảy ra lỗi Điều này được ký hiệu là M (Maintainability), và 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

Chẳng hạn, nếu một thành phần có giá trị bảo trì là 95% trong vòng nửa giờ, điều này

có nghĩa là 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

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

Định Lý CAP Cá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

Rất tốt khi bạn đã cung cấp các định nghĩa và khái niệm quan trọng trong lĩnh vực quản lý sự cố và độ tin cậy của hệ thống Dưới đây là một số ý thêm về các khái niệm bạn đã đề cập:

Failure (Sự cố): Đây là trạng thái mà cả hệ thống không hoạt động, gặp vấn đề

và không thể thực hiện chức năng mong đợi

Fault (Lỗi): Là trạng thái mà một phần của hệ thống không hoạt động đúng cách, có thể là do lỗi phần mềm, lỗi phần cứng, hoặc các vấn đề khác

Node Fault (Sự cố tại Node): Đây là khi sự cố xảy ra tại một server node cụ thể trong hệ thống, ảnh hưởng đến hoạt động của nó

Crash-stop (Dừng hoàn toàn sau sự cố): Trạng thái khi một server gặp sự cố và dừng lại hoàn toàn mà không có khả năng tự hồi phục

Crash-recovery (Hồi phục sau sự cố): Trạng thái khi một server gặp sự cố, dừng lại, và sau đó tự hồi phục và tiếp tục hoạt động

Byzantine Fault (Sự cố Byzantine): Là một loại sự cố nơi server không chỉ dừng hoạt động mà còn hoạt động không đáng tin cậy, thậm chí có thể xử lý một cách ngẫu nhiên và không dựa trên chương trình

Network Fault (Sự cố Mạng): Là sự cố xuất hiện tại mức độ đường truyền, kết nối mạng, chẳng hạn như mất tin nhắn, độ trễ, hoặc tắc nghẽn trong mạng

Fault Tolerance (Khả năng chống sự cố): Là khả năng của hệ thống tiếp tục hoạt động một cách bình thường hoặc giảm thiểu ảnh hưởng khi có sự cố xảy

ra

Single Point of Failure (Điểm sự cố duy nhất): Đây là khi sự cố tại một node cụ thể dẫn đến sự cố trên toàn bộ hệ thống, làm giảm tính sẵn sàng và độ tin cậy

Những định nghĩa này quan trọng để hiểu rõ cách mà hệ thống có thể đối mặt với sự

cố và cách đảm bảo tính ổn định và khả năng phục hồi của nó

1.2.6.2 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: Xây dựng hệ thống với NET Core

2.1 ASP.NET Core

ASP.NET Core là một framework mạnh mẽ, mã nguồn mở và đa nền tảng, được thiết

kế để xây dựng các ứng dụng hiện đại có hiệu suất cao và có khả năng kết nối với đám mây và Internet Framework này hỗ trợ xây dựng ứng dụng web, dịch vụ, cũng như ứng dụng Internet of Things (IoT) và phần backend cho các ứng dụng di động

ASP.NET Core khác biệt với các phiên bản trước bởi việc dựa trên framework NET Core .NET Core là một framework mã nguồn mở, đa nền tảng và có hiệu suất cao, mang lại nhiều lợi ích quan trọng Một số điểm nổi bật của NET Core bao gồm khả năng chạy trên nhiều hệ điều hành, hiệu suất ấn tượng, bảo mật mạnh mẽ, và khả năng phát triển song song

.NET Core không chỉ là một công cụ hiệu quả cho việc phát triển ứng dụng mà còn là một cộng đồng lớn và tích cực Sự hỗ trợ và tài nguyên đa dạng từ cộng đồng này giúp các nhà phát triển tận dụng tối đa khả năng của framework, đồng thời giữ cho nó luôn phát triển và cập nhật theo xu hướng công nghệ mới

Một số các tiện ích mà ta có được khi sử dụng ASP.NET Core là:

● Razor Pages giúp việc lập trình trang trở nên dễ dàng và hiệu quả hơn

● Blazor cho phép bạn sử dụng C# trong trình duyệt cùng với JavaScript Chia sẻ logic ứng dụng phía máy chủ và phía máy khách tất cả đều được viết bằng NET

● Khả năng phát triển và chạy trên Windows, macOS và Linux

2.1.1 Services & Dependency injection

Dependency Injection (DI) là một kỹ thuật thiết kế phần mềm cho phép đạt được Inversion of Control (IoC) giữa các lớp và các phụ thuộc của chúng Mặc định thì ASP.NET Core project được tích hợp sẵn tính năng hỗ trợ DI nhưng ta có thể thay thế nó bằng một số thư viện khác như Autofac, Ninject, Simple Injector…

Trong ASP.NET Core, dịch vụ (service) dùng để chỉ một class có khả năng cung cấp chức năng cho ứng dụng Các services được register với dependency injection container và inject vào các middlewares hay services khác

Các services này sẽ được inject vào trong các middleware hay services khác thông qua constructor

Các service này có thể thuộc một trong 3 scope:

● Singleton: Dịch vụ Singleton được tạo ra lần đầu tiên chúng được yêu cầu

và sau đó sẽ được sử dụng cho tất cả các yêu cầu tiếp theo Nếu ta giải quyết cùng một dịch vụ nhiều lần, ta sẽ nhận được cùng một instance

● Scoped: Dịch vụ Scoped được tạo ra một lần cho mỗi yêu cầu (scope) Nếu

ta giải quyết cùng một dịch vụ nhiều lần trong cùng một yêu cầu, ta sẽ nhận được cùng một instance Trong ứng dụng web, scope thường là một yêu cầu HTTP

● Transient: Dịch vụ Transient được tạo ra mỗi khi chúng được yêu cầu từ container DI Điều này có nghĩa là nếu ta giải quyết cùng một dịch vụ nhiều lần trong cùng một yêu cầu, ta sẽ nhận được một instance khác nhau mỗi lần

2.1.2 Middlewares

Middleware trong ASP.NET Core là những thành phần được tích hợp vào pipeline

để xử lý các yêu cầu và phản hồi Mỗi middleware có khả năng chuyển tiếp yêu cầu đến middleware tiếp theo trong pipeline hoặc có thể chọn kết thúc xử lý yêu

cầu Middleware có vai trò tương đương với HttpHandlers và HttpModules trong ASP.NET cũ, yêu cầu được xử lý trong mỗi chuỗi middleware

Thêm middleware vào pipeline có thể được thực hiện thông qua việc sử dụng delegate và hàm Use hoặc bằng cách implement lớp với interface IMiddleware

và sử dụng hàm UseMiddleware Khi một middleware gọi next(), context sẽ được truyền cho middleware tiếp theo trong chuỗi

ASP.NET Core cung cấp sẵn nhiều middleware tích hợp, nhưng cũng cho phép viết middleware tùy chỉnh Middleware có thể được viết thông qua việc tạo một class và đăng ký nó với pipeline bằng phương thức UseMiddleware hoặc thông qua phương thức mở rộng

Dưới đây là một số middleware phổ biến được sử dụng trong ASP.NET Core:

❖ Authentication Middleware: Xác thực người dùng và thiết lập thông tin xác thực cho yêu cầu hiện tại

❖ Authorization Middleware: Kiểm tra xem người dùng có quyền truy cập vào tài nguyên được yêu cầu hay không

❖ Routing Middleware: Ánh xạ yêu cầu đến một điểm cuối (endpoint) cụ thể dựa trên đường dẫn URL và phương thức HTTP

❖ Compression Middleware: Nén phản hồi HTTP để giảm kích thước truyền tải và tăng tốc độ tải trang

❖ Caching Middleware: Lưu trữ phản hồi HTTP trong bộ nhớ cache để giảm thời gian tải trang cho các yêu cầu tiếp theo

❖ UseBlazorFrameworkFiles: Cho phép ứng dụng sử dụng Blazor

❖ CORS Middleware: Cho phép các yêu cầu từ các nguồn khác nhau

(cross-origin) để hỗ trợ chia sẻ tài nguyên giữa các trang web khác nhau

❖ Static Files Middleware: Cho phép ứng dụng phục vụ các static files như hình ảnh, CSS và JavaScript

2.2 ORM

ORM (Object-Relational Mapping) là một kỹ thuật cho phép truy vấn và thao tác dữ liệu

từ cơ sở dữ liệu quan hệ bằng cách sử dụng mô hình lập trình hướng đối tượng Thông qua ORM, việc tương tác với cơ sở dữ liệu trở nên trực tiếp và linh hoạt hơn bằng cách

sử dụng các đối tượng và các phương thức trong ngôn ngữ lập trình, thay vì sử dụng ngôn ngữ truy vấn như SQL

Một thư viện ORM cung cấp một tập hợp các tính năng cần thiết để thao tác dữ liệu, giảm sự phụ thuộc vào việc sử dụng SQL trực tiếp Khi sử dụng ORM, các câu lệnh truy vấn được thực hiện thông qua các đối tượng và phương thức trong ngôn ngữ lập trình của bạn, và thư viện ORM sẽ tự động chuyển đổi các câu lệnh này thành các câu lệnh SQL tương ứng Kết quả của các truy vấn SQL sẽ được ánh xạ trở lại các đối tượng, giúp giảm bớt sự phức tạp trong quá trình làm việc với dữ liệu cơ sở dữ liệu

dữ liệu từ cơ sở dữ liệu

2.2.2 EF Core

Entity Framework Core (EF Core) là một phiên bản nhẹ, mở rộng, mã nguồn mở

và đa nền tảng của công nghệ truy cập dữ liệu Entity Framework, một ORM (Object-Relational Mapping) phổ biến trong cộng đồng phát triển NET EF Core giúp các nhà phát triển NET làm việc với cơ sở dữ liệu một cách thuận tiện bằng