Đồ Án 1: Thiết Kế và Xây Dựng Hệ Thống với .NET Core - Nguyễn Hoàng Văn Tiến

Đồ án 1: Thiết kế & xây dựng hệ thống với .NET Core. Hướng dẫn chi tiết từng bước, từ lên kế hoạch đến triển khai dự án thực tế. Tìm hiểu ngay!

Chuyên ngành

Công nghệ phần mềm

Người đăng

Ẩn danh

Thể loại

Đồ án

2023

46
4
0

Phí lưu trữ

30 Point

Mục lục chi tiết

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

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

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

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

1.4. Byzantine fault

2. Chương 2: Load balancer

2.1. Load balancer

2.2. Tăng availability của hệ thống

3. Chương 3: Caching

3.1. Tổng quan về caching

3.2. Các pattern trong caching

3.3. Reverse proxy cache

3.4. Reverse proxy sidecar cache

3.5. Làm trống cache (Cache eviction)

3.6. Các pattern truy cập trong caching

3.7. Write-back (Write-behind)

4. Chương 4: Microservices

4.1. Miêu tả microservice

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

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

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

5.1. Phân loại service discovery

5.2. Phân loại hình thức register

5.3. Sử dụng service

5.4. Kiến trúc

6. Chương 6: Distributed transactions

6.1. Tổng quan về transaction

6.2. Two-phase commit (2PC)

6.3. Three-phase commit (3PC)

6.4. So sánh Two-phase commit/Three-phase commit và Saga

7. Chương 7: Consensus

7.1. Thuật toán Raft

7.2. Khái quát về Raft

7.3. Bầu cử leader

7.4. Hoạt động bình thường của thuật toán

7.5. Ưu và nhược điểm của Raft

7.6. Nhược điểm

8. Chương 8: Deployment

8.1. Multiple instance per host

8.2. Once instance per host

8.3. Kubernetes và Helm

8.4. Grafana

9. Chương 9: Xây dựng hệ thống với . Services & Dependency injection

9.1. Thiết kế hệ thống lớn

10. Chương 10: Demo

Tóm tắt

I. Tổng Quan Thiết Kế Hệ Thống

Trong bối cảnh phát triển ứng dụng hiện đại, việc thiết kế hệ thống đóng vai trò then chốt, quyết định khả năng mở rộng, hiệu năng và độ tin cậy. Đối với các hệ thống nhỏ, kiến trúc Client-Server đơn giản có thể đáp ứng được nhu cầu. Tuy nhiên, khi hệ thống trở nên phức tạp hơn, số lượng người dùng tăng lên, đòi hỏi một kiến trúc mạnh mẽ hơn, có khả năng xử lý đồng thời lượng lớn truy cập. Lúc này, việc phân tách các thành phần như Web ServerDatabase Server chạy độc lập trở nên cần thiết. Điều này giúp hệ thống có thể mở rộng và tối ưu hóa hiệu năng. Một hệ thống lớn cần tuân thủ các nguyên lý thiết kế quan trọng như Scalability (khả năng mở rộng), Availability (khả năng sẵn sàng) và Consistency (tính nhất quán). Scalability có thể đạt được thông qua Vertical Scaling (nâng cấp phần cứng) hoặc Horizontal Scaling (thêm nhiều server). Availability đòi hỏi hệ thống phải có khả năng xử lý các yêu cầu liên tục trong một khoảng thời gian dài, được đánh giá bằng các chỉ số như 99.99% uptime. Consistency đảm bảo rằng tất cả người dùng đều thấy dữ liệu như nhau, đồng nhất, ngay cả khi có các thao tác cập nhật dữ liệu. Ngoài ra, cần xem xét các khái niệm về Fault Tolerance (khả năng chống chịu lỗi) và Byzantine Fault (lỗi Byzantine) để đảm bảo hệ thống vẫn hoạt động ổn định khi có lỗi xảy ra. Theo tài liệu gốc, khi hệ thống nhỏ phát triển, việc chuyển từ kiến trúc đơn giản sang kiến trúc phức tạp hơn với nhiều server là tất yếu. Việc này đòi hỏi kiến thức về các nguyên lý thiết kế hệ thống và khả năng áp dụng chúng vào thực tế. Các quyết định thiết kế ban đầu sẽ ảnh hưởng lớn đến khả năng phát triển và bảo trì của hệ thống trong tương lai. Tóm lại, việc lựa chọn kiến trúc và tuân thủ các nguyên lý thiết kế là vô cùng quan trọng để xây dựng một hệ thống .NET Core mạnh mẽ, ổn định và dễ mở rộng.

1.1. So Sánh Kiến Trúc Client Server và Đa Server Trong .NET Core

Kiến trúc Client-Server phù hợp cho các ứng dụng nhỏ, đơn giản, với một server duy nhất xử lý tất cả các yêu cầu. Ưu điểm của kiến trúc này là dễ triển khai và quản lý. Tuy nhiên, khi số lượng người dùng tăng lên hoặc ứng dụng trở nên phức tạp hơn, kiến trúc này sẽ gặp khó khăn trong việc đáp ứng yêu cầu về hiệu năng và khả năng mở rộng. Kiến trúc đa server, với việc phân tách các thành phần như Web Server và Database Server, cho phép hệ thống mở rộng dễ dàng hơn. Khi số lượng người dùng tăng lên, có thể thêm nhiều Web Server để xử lý các yêu cầu. Khi dung lượng dữ liệu tăng lên, có thể nâng cấp hoặc mở rộng Database Server. Tuy nhiên, kiến trúc này phức tạp hơn và đòi hỏi nhiều kỹ năng quản lý hơn.

1.2. Các Chỉ Số Đánh Giá Mức Độ Availability Trong Hệ Thống .NET Core

Mức độ Availability của một hệ thống được đánh giá bằng tỷ lệ thời gian hệ thống hoạt động so với tổng thời gian. Các chỉ số thường được sử dụng bao gồm 99%, 99.9%, 99.99% và 99.999% uptime. Ví dụ, hệ thống với 99.99% uptime chỉ có khoảng 52 phút downtime mỗi năm. Để đạt được mức độ Availability cao, cần áp dụng các kỹ thuật như Replication, FailoverLoad Balancing. Replication cho phép sao chép dữ liệu sang nhiều server khác nhau, đảm bảo rằng dữ liệu vẫn có sẵn khi một server bị lỗi. Failover cho phép tự động chuyển sang một server dự phòng khi server chính bị lỗi. Load Balancing phân phối lưu lượng truy cập đến nhiều server, giảm tải cho mỗi server và tăng khả năng chịu lỗi.

II. Load Balancer Trong

Load Balancer (cân bằng tải) là một thành phần quan trọng trong hệ thống sử dụng đồng thời nhiều server. Chức năng chính của Load Balancer là phân phối đồng đều lưu lượng truy cập giữa các Web Servers, giúp giảm tải cho hệ thống và cải thiện hiệu suất. Load Balancer có thể là phần cứng (Hardware Load Balancer) hoặc phần mềm (Software Load Balancer). Hardware Load Balancer thường có hiệu năng cao hơn nhưng chi phí cũng cao hơn. Software Load Balancer là một giải pháp tiết kiệm chi phí nhưng vẫn đảm bảo hiệu suất vận hành tốt. Load Balancer có thể hoạt động ở nhiều tầng khác nhau trong mô hình OSI, bao gồm Layer 7 Load Balancer (tầng Application) và Layer 3/4 Load Balancer (tầng Network và tầng Transport). Layer 7 Load Balancer có thể đưa ra quyết định định tuyến dựa trên thông tin chi tiết về HTTP/HTTPS header, URL hoặc cookie. Layer 3/4 Load Balancer chỉ sử dụng thông tin về địa chỉ IP và cổng TCP/UDP. Ngoài ra, còn có Global Server Load Balancer, phân phối lưu lượng truy cập trên các server ở nhiều nơi trên toàn thế giới. Có nhiều thuật toán khác nhau để Load Balancer quyết định điều hướng lưu lượng, bao gồm Round Robin, Weighted Round Robin, Least Connections, Weighted Least ConnectionsIP Hash. Các pattern như Server-Side Load BalancingClient-Side Load Balancing cũng được sử dụng để cải thiện hiệu suất và độ tin cậy của hệ thống. Theo tài liệu gốc, Load Balancer đóng vai trò quan trọng trong việc tăng Availability của hệ thống bằng cách phân phối lưu lượng truy cập và giảm tải cho các server. Việc lựa chọn loại Load Balancer phù hợp và cấu hình nó đúng cách là rất quan trọng để đảm bảo hiệu năng và độ tin cậy của hệ thống .NET Core.

2.1. So Sánh Hardware Load Balancer và Software Load Balancer Trong .NET Core

Hardware Load Balancer là các thiết bị phần cứng chuyên dụng, được thiết kế để xử lý lưu lượng truy cập lớn. Chúng thường có hiệu năng cao hơn và độ tin cậy cao hơn so với Software Load Balancer. Tuy nhiên, Hardware Load Balancer cũng đắt hơn và khó cấu hình hơn. Software Load Balancer là phần mềm chạy trên các server thông thường. Chúng có chi phí thấp hơn và dễ cấu hình hơn. Tuy nhiên, Software Load Balancer có thể không có hiệu năng cao bằng Hardware Load Balancer. Việc lựa chọn giữa Hardware Load Balancer và Software Load Balancer phụ thuộc vào yêu cầu về hiệu năng, chi phí và độ phức tạp của hệ thống.

2.2. Các Thuật Toán Điều Hướng Lưu Lượng Trong Load Balancer .NET Core

Round Robin là thuật toán đơn giản nhất, phân phối lưu lượng truy cập đến các server theo lượt. Weighted Round Robin cho phép gán trọng số cho các server để ưu tiên một số server hơn. Least Connections chuyển hướng lưu lượng truy cập đến các server có ít kết nối nhất. Weighted Least Connections tương tự như Least Connections, nhưng cho phép gán trọng số cho các server. IP Hash sử dụng địa chỉ IP nguồn và đích để tính toán một giá trị băm và gán kết nối đến một server cụ thể dựa trên giá trị băm này. Việc lựa chọn thuật toán phù hợp phụ thuộc vào yêu cầu về hiệu năng, tính công bằng và khả năng chịu lỗi của hệ thống.

2.3. Các Giải Pháp Tăng Availability Hệ Thống .NET Core

Có nhiều giải pháp để tăng Availability của hệ thống, bao gồm Replication, Log Shipping, Mirroring, ClusteringAlwaysON Availability Groups. Replication sao chép dữ liệu sang nhiều server khác nhau. Log Shipping sao chép Transaction Log để đồng bộ dữ liệu. Mirroring thiết lập High Availability cho database. Clustering sử dụng dữ liệu đã lưu trữ ở những địa điểm thường xuyên được truy cập. AlwaysON Availability Groups chuyển dữ liệu sơ cấp sang dạng thứ cấp bằng các network transactions. Việc lựa chọn giải pháp phù hợp phụ thuộc vào yêu cầu về tính sẵn sàng, tính nhất quán và chi phí của hệ thống.

III. Caching Trong

Caching là một kỹ thuật quan trọng để cải thiện hiệu năng của ứng dụng .NET Core bằng cách lưu trữ tạm thời kết quả của các phép tính hoặc phản hồi thường xuyên vào một vùng nhớ cache. Điều này giúp các yêu cầu tiếp theo của cùng phép tính hoặc phản hồi được truy cập và xử lý nhanh hơn. Có nhiều pattern caching khác nhau, bao gồm Local Cache, Distributed Cache, Reverse Proxy CacheSidecar Cache. Local Cache đơn giản và dễ sử dụng, nhưng khả năng scale không tốt. Distributed Cache sử dụng các thuật toán hash để phân mảnh data và lưu chúng trên nhiều node khác nhau, có khả năng scale tốt. Reverse Proxy Cache giảm tải cho server bằng cách cache HTTP request. Sidecar Cache hoạt động như local cache và có độ trễ thấp. Ngoài ra, cần xem xét các kỹ thuật Cache Eviction (làm trống cache) để loại bỏ các dữ liệu cũ hoặc không được sử dụng thường xuyên. Các pattern truy cập trong caching bao gồm Cache-Aside, Read-Through, Write-ThroughWrite-Back. Theo tài liệu gốc, Caching là một phương pháp hiệu quả để giảm thời gian truy cập dữ liệu và cải thiện hiệu năng của ứng dụng. Việc lựa chọn pattern caching phù hợp và cấu hình nó đúng cách là rất quan trọng để đảm bảo hiệu quả và độ tin cậy của hệ thống .NET Core.

3.1. So Sánh Local Cache và Distributed Cache Trong .NET Core

Local Cache lưu trữ dữ liệu trên cùng một server với ứng dụng. Ưu điểm của Local Cache là tốc độ truy cập nhanh và dễ triển khai. Tuy nhiên, Local Cache không thể scale được và dữ liệu sẽ bị mất nếu server bị lỗi. Distributed Cache lưu trữ dữ liệu trên nhiều server khác nhau. Ưu điểm của Distributed Cache là khả năng scale tốt và dữ liệu sẽ không bị mất nếu một server bị lỗi. Tuy nhiên, Distributed Cache có tốc độ truy cập chậm hơn Local Cache và phức tạp hơn trong việc triển khai.

3.2. Các Chiến Lược Cache Eviction Làm Trống Cache Phổ Biến

Cache Eviction là quá trình loại bỏ các dữ liệu cũ, không được sử dụng thường xuyên hoặc có dung lượng quá lớn ra khỏi cache. Các chiến lược Cache Eviction phổ biến bao gồm Least Recently Used (LRU), Least Frequently Used (LFU)First In First Out (FIFO). LRU loại bỏ các dữ liệu ít được sử dụng nhất trong thời gian gần đây. LFU loại bỏ các dữ liệu ít được sử dụng nhất trong lịch sử. FIFO loại bỏ các dữ liệu được thêm vào cache đầu tiên. Việc lựa chọn chiến lược Cache Eviction phù hợp phụ thuộc vào đặc điểm của dữ liệu và yêu cầu về hiệu năng của hệ thống.

3.3. Phân Tích Các Pattern Truy Cập Cache Cache Aside Read Through Write Through

Cache-Aside là pattern phổ biến nhất, ứng dụng tự kiểm tra cache trước khi truy vấn database. Read-Through cho phép cache tự động lấy dữ liệu từ database khi không tìm thấy trong cache. Write-Through ghi dữ liệu vào cả cache và database đồng thời. Việc lựa chọn pattern phù hợp phụ thuộc vào yêu cầu về tính nhất quán, hiệu năng và độ phức tạp của hệ thống.

IV. Microservices

Microservices là một kiến trúc phần mềm trong đó ứng dụng được xây dựng như một tập hợp các dịch vụ nhỏ, độc lập, có thể chạy riêng biệt, phát triển và triển khai độc lập. Thay vì xây dựng một ứng dụng monolithic lớn, microservices chia nhỏ ứng dụng thành các dịch vụ nhỏ kết nối với nhau, mỗi dịch vụ thực hiện một tập các chức năng chuyên biệt. Mỗi dịch vụ là một ứng dụng nhỏ có kiến trúc đa diện, lõi là business logic kết nối ra các adapter khác nhau. Các dịch vụ giao tiếp với nhau thông qua các API hoặc các kênh messaging. Khi vận hành, mỗi dịch vụ được chạy trong một máy ảo hoặc Docker container. Có nhiều phương thức giao tiếp giữa các services, bao gồm Remote Procedure Invocation (RPI)Messaging. RPI sử dụng request/reply-based protocol, trong khi Messaging sử dụng asynchronous messaging. Tuy nhiên, microservices cũng có một số khuyết điểm, bao gồm sự phức tạp trong việc triển khai, quản lý và debug. Theo tài liệu gốc, microservices là một kiến trúc phù hợp cho các ứng dụng lớn, phức tạp, đòi hỏi khả năng mở rộng, linh hoạt và dễ bảo trì. Tuy nhiên, cần cân nhắc kỹ các khuyết điểm trước khi quyết định sử dụng kiến trúc này.

4.1. Ưu Điểm và Khuyết Điểm của Kiến Trúc Microservices Trong .NET Core

Ưu điểm của Microservices bao gồm khả năng mở rộng, linh hoạt, dễ bảo trì, phát triển độc lập và triển khai độc lập. Khuyết điểm bao gồm sự phức tạp trong việc triển khai, quản lý, debug, giao tiếp giữa các services và đảm bảo tính toàn vẹn dữ liệu.

4.2. Các Phương Thức Giao Tiếp Giữa Các Microservices RPI và Messaging

Remote Procedure Invocation (RPI) sử dụng request/reply-based protocol để giao tiếp giữa các services. Ví dụ như REST, gRPC và Apache Thrift. Messaging sử dụng asynchronous messaging để giao tiếp giữa các services. Ví dụ như Apache Kafka và RabbitMQ. Việc lựa chọn phương thức phù hợp phụ thuộc vào yêu cầu về hiệu năng, độ tin cậy và tính phức tạp của hệ thống.

4.3. Các Thách Thức Khi Triển Khai Microservices Trong .NET Core

Các thách thức khi triển khai Microservices bao gồm việc triển khai giao tiếp giữa nhiều inter-services, xử lý partial failure, thực hiện các requests trải rộng trên nhiều services, debug và fix bug, đảm bảo toàn vẹn CSDL và triển khai, quản lý microservices.

V. Service Discovery API Gateway Quản Lý Microservices

Service DiscoveryAPI Gateway là hai thành phần quan trọng trong việc quản lý microservices. Service Discovery cho phép các services tự động tìm kiếm và kết nối với nhau. API Gateway đóng vai trò là một cửa ngõ cho các yêu cầu từ client, xử lý các yêu cầu đó và redirect chúng đến service thích hợp. Service Discovery có thể được phân loại thành Client-SideServer-Side. API Gateway cung cấp các chức năng như bảo mật API, monitoring, phân tích số lượng request và đánh giá tình trạng hệ thống. Theo tài liệu gốc, Service Discovery và API Gateway giúp đơn giản hóa việc quản lý microservices và tăng cường tính bảo mật, hiệu năng và khả năng mở rộng của hệ thống .NET Core.

5.1. So Sánh Client Side Service Discovery và Server Side Service Discovery

Trong Client-Side Service Discovery, client hoặc API gateway sẽ có được vị trí của một service instance bằng cách truy vấn một service registry. Trong Server-Side Service Discovery, client/API gateway sẽ gửi một request đến một component (ví dụ như một load balancer) chạy trên một location đã biết.

5.2. Lợi Ích và Nhược Điểm Khi Sử Dụng API Gateway Trong .NET Core

Lợi ích khi sử dụng API Gateway bao gồm che dấu được cấu trúc của hệ thống microservices với bên ngoài, code phía frontend gọn gàng hơn, dễ dàng theo dõi và quản lý traffic, requests caching và cân bằng tải, thêm một lớp bảo mật nữa cho hệ thống và thay thế authentication services. Nhược điểm bao gồm tăng thời gian response, thêm tác nhân gây lỗi, có thể gây nghẽn cổ chai và phát sinh thêm chi phí.

5.3. Giới Thiệu Envoy L7 Proxy Hiện Đại Cho Microservices .NET Core

Envoy là một L7 proxy được thiết kế cho các kiến trúc service-oriented hiện đại và quy mô lớn. Envoy có thể hoạt động với bất kỳ ngôn ngữ lập trình nào, với một lần triển khai Envoy duy nhất có thể tạo thành một mạng lưới giữa Java, C++, Go, PHP, Python…

VI. Deployment

Deployment (Triển khai) là quá trình đưa ứng dụng từ môi trường phát triển sang môi trường sản xuất để người dùng có thể sử dụng. Có nhiều mô hình triển khai khác nhau, bao gồm Multiple Instance Per Host, Once Instance Per Host, Serverless, DockerKubernetes. Multiple Instance Per Host triển khai nhiều instance của hệ thống lên mỗi host. Once Instance Per Host triển khai mỗi service instance trên một host. Serverless cho phép chạy ứng dụng mà không cần quản lý máy chủ. Docker đóng gói ứng dụng vào các container. Kubernetes là một container orchestrator giúp quản lý việc deploy các container. Theo tài liệu gốc, việc lựa chọn mô hình triển khai phù hợp phụ thuộc vào yêu cầu về hiệu năng, khả năng mở rộng, độ tin cậy và chi phí của hệ thống .NET Core.

6.1. So Sánh Multiple Instance Per Host và Once Instance Per Host

Multiple Instance Per Host triển khai nhiều instance của hệ thống lên mỗi host. Ưu điểm là deploy đơn giản và dễ xử lý lỗi. Khuyết điểm là không tốt trong việc scale lên, cần phải biết rõ dependency của một instance, không có phân định rõ resources của một instance và một instance crash có thể ảnh hưởng đến các instance khác trên cùng một host. Once Instance Per Host triển khai mỗi service instance trên một host. Ưu điểm là phân định resource rõ ràng, tăng tính bảo mật, có thể scale tốt và có thể đóng gói các service lại thành một black box. Khuyết điểm là khó deploy hơn và khó phát hiện lỗi.

6.2. Lợi Ích và Hạn Chế Khi Sử Dụng Serverless Trong .NET Core

Lợi ích khi sử dụng Serverless bao gồm không cần phải tập trung quá nhiều về deployment, có thể tập trung nhân lực vào việc phát triển service và chỉ bị tính phí cho mỗi request. Khuyết điểm bao gồm có nhiều giới hạn như không thể deploy stateful application như database và ứng dụng cần phải có tốc độ startup nhanh.

6.3. Kubernetes và Helm Quản Lý Triển Khai Container .NET Core

Kubernetes là một container orchestrator giúp quản lý việc deploy các container của một hệ thống. Helm là một trình quản lý gói và công cụ quản lý ứng dụng cho Kubernetes, đóng gói nhiều tài nguyên Kubernetes vào một đơn vị triển khai logic duy nhất được gọi là Chart.

15/09/2025

Trích đoạn nội dung tài liệu

Chương 1: Tổng quan về thiết kế hệ thống 1. Thiết kế trong các hệ thống nhỏ và trong các hệ thống lớn Đối với các hệ thống nhỏ không quá phức tạp thì ứng dụng của chúng ta sẽ sử dụng kiến trúc Client - Server như hình dưới: Luồng hoạt động của một ứng dụng đơn giản sử dụng kiến trúc Client - Server sẽ như sau: 1. Người dùng sử dụng trình duyệt web hoặc app mobile truy cập vào website của chúng ta thông qua tên miền api. Địa chỉ IP của website sẽ được trả về trình duyệt web hoặc app mobile mà người dùng truy cập.

Sau khi có được địa chỉ IP của website, HTTP request từ người dùng sẽ được gửi trực tiếp tới web server của chúng ta. Web server trả về các trang HTML hoặc dữ liệu JSON và hiển thị các thông tin mà người dùng mong muốn ở chính thiết bị của người dùng. Tuy nhiên, khi hệ thống có nhiều chức năng phức tạp hay số lượng người dùng truy cập hệ thống ngày càng nhiều và phải phục vụ cùng một lúc một số lượng lớn user thì hệ thống đơn giản trên sẽ không đủ khả năng để phục vụ. Như vậy, chúng ta cần phải áp dụng cách thiết kế khác để đáp ứng nhu cầu trên.

Bằng cách sử dụng đồng thời nhiều server thay vì một server lưu trữ toàn bộ như trước thì giờ đây chúng ta sẽ phân tách ra độc lập Web server và Database server chạy riêng biệt hoàn toàn. Công việc lúc này của chúng ta sẽ phải thiết lập nhiều server chạy đồng thời song song và đảm bảo chi khi tối ưu khi vận hành. Các nguyên lý thiết kế hệ thống 1. Scalability Scalability là khả năng mở rộng của hệ thống.

Có 2 cách để scale hệ thống: Vertical scaling và Horizontal scaling. Vertical scaling (scale up): chúng ta nâng cấp phần cứng (CPU, RAM, ổ cứng…) cho server. Đây là một cách đơn giản để cải thiện hiệu suất của hệ thống nhưng chúng ta không thể nâng cấp phần cứng liên tục, không giới hạn CPU, RAM vào server được vì giới hạn của phần cứng. Đây là nhược điểm lớn nhất của Vertical scaling.

Horizontal scaling (scale out): chúng ta mở rộng, thêm nhiều server khác vào hệ thống. Cách này sẽ khắc phục giới hạn của Vertical scaling và là lựa chọn tối ưu nhất để thiết kế trong các hệ thống lớn. Availability Availability là khả năng sẵn sàng của hệ thống để xử lý các yêu cầu liên tục trong một khoảng thời gian. Dưới đây là các chỉ số được áp dụng để đánh giá mức độ Availability của hệ thống: Như vậy, với mức độ sẵn sàng càng cao thì thời gian sập của hệ thống phải càng ngày càng được rút ngắn và gần như không để hiện tượng sập xảy ra.

Consistency Consistency là tính nhất quán của hệ thống. Tại cùng một thời điểm, tất cả người dùng phải đảm bảo thấy được dữ liệu như nhau, đồng nhất ngay cả khi thực hiện các thao tác cập nhật dữ liệu. 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.

Fault tolerance: khả năng chống fault - hệ thống vẫn tiếp tục hoạt động khi có fault (khi số lượng fault dưới một ngưỡng tối đa). Byzantine fault Byzantine fault hay còn được biết đến với Bài toán các vị tướng Byzantine, mô tả việc một nhóm các vị tướng Byzantine gặp các vấn đề về liên lạc khi cố gắng đạt sự đồng thuận về bước đi tiếp theo. Bài toán giả định rằng mỗi tướng có quân đội riêng và mỗi tướng đóng quân ở các địa điểm khác nhau xung quanh thành phố mà họ dự định tấn công. Các tướng phải đồng thuận về việc tấn công hoặc rút lui.

Vấn đề tấn công hay rút lui không quan trọng mà là sự đồng thuận của tất cả các tướng, tức là, đồng thuận về một quyết định chung để cùng phối hợp thực hiện. Do đó, chúng ta có thể xem xét kỹ càng các mục tiêu sau để đưa ra quyết định: ● Mỗi tướng phải quyết định: tấn công hoặc rút lui (có hay không). ● Không thể thay đổi quyết định sau khi đưa ra. ● Tất cả tướng phải nhất trí về một quyết định giống nhau và tiến hành đồng bộ với nhau.

Chương 2: Load balancer 2. Load balancer Load balancer (cân bằng tải) để phân phối đồng đều lưu lượng truy cập giữa các web servers. Đây là một thành phần cực kỳ quan trọng cho hệ thống sử dụng đồng thời nhiều server. Ưu điểm của Load balancer: ● Phân phối khối lượng công việc trên nhiều server, giảm tải cho hệ thống.

● Cải thiện hiệu suất và độ tin cậy cho website. Hardware & Software Hardware load balancer: là các thiết bị phần cứng máy tính chạy trên các phần mềm mã nguồn đóng, được xây dựng đặc biệt để có thể vận hành trên các bộ xử lý tùy chỉnh. Với càng nhiều lưu lượng truy cập, số lượng các thiết bị cân bằng tải phải tăng lên theo tỷ lệ thuận để có thể đáp ứng nhu cầu dịch vụ của khách hàng. Software load balancer: là giải pháp tiết kiệm chi phí nhưng mang lại hiệu suất vận hành tối ưu cho doanh nghiệp.

Chúng ta chỉ cần cài đặt phần mềm cân bằng tải vào trong hệ thống của mình, vẫn đảm bảo lưu lượng truy cập mà hệ thống chịu tải trong khi không cần bỏ một mức chi phí rất lớn cho việc sử dụng và vận hành các hệ thống cân bằng tải vật lý. Tầng xử lý Layer 7 load balancer: hoạt động ở tầng application - tầng cao nhất trong mô hình OSI, nó đưa ra quyết định định tuyến dựa trên các thông tin chi tiết về đặc điểm của các HTTP/HTTPS header, loại URL hoặc dữ liệu cookie… Layer 3/4 load balancer: hoạt động ở tầng network và tầng transport trong mô hình OSI, sử dụng thông tin về địa chỉ IP và 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. Global server load balancer: phân phối lưu lượng truy cập trên các server ở nhiều nơi trên toàn thế giới.

Sử dụng DNS và các thông tin về tài nguyên dịch vụ để đưa ra quyết định định tuyến. Thuật toán Các thuật toán thường được dùng để Load balancer quyết định điều hướng: ● 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.

● 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. Patterns Server-side load balancing: cung cấp các dịch vụ mạng và phân phối nội dung bằng cách sử dụng một loạt thuật toán cân bằng tải. Nó ưu tiên phản hồi các yêu cầu cụ thể từ khách hàng qua mạng.

Điều này nhằm đảm bảo phân phối ứng dụng nhất quán, hiệu suất cao. Client-side load balancing: là phương pháp trong đó việc phân phối lưu lượng mạng được thực hiện ở phía 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ề.

Tăng availability của hệ thống Về cơ bản sẽ có 5 giải pháp để tăng availability cho hệ thống: ● Replication: với giải pháp này thì dữ liệu gốc sẽ được sao chép đến điểm đích thông qua những tác vụ sao chép (agent/job). ● Log Shipping: thông qua những tác vụ sao lưu Transaction Log, dữ liệu gốc sẽ được tiến hành sao chép đến điểm đích. ● Mirroring: thiết lập High availability dành cho database trong MS SQL Server bằng cách sao chép dữ liệu sơ cấp sang dạng thứ cấp thông qua các network transactions, nhờ sự hỗ trợ của các connection point cùng với port number. ● Clustering: giải pháp này sử dụng dữ liệu đã lưu trữ ở những địa điểm thường xuyên được truy cập, sử dụng cho máy chủ thứ cấp và sơ cấp.

Giải pháp này cần phải thiết lập Windows Clustering ở những nơi có sự chia sẻ dữ liệu chung. ● AlwaysON Availability Groups: dữ liệu sơ cấp sẽ được chuyển sang dạng thứ cấp bằng các network transactions. Với giải pháp này thì chúng ta không cần phải thiết lập Windows Clustering. Chương 3: Caching 3.

Tổng quan về caching Caching là phương pháp lưu trữ tạm thời kết quả của các phép tính hoặc phản hồi thường xuyên vào một vùng nhớ cache, giúp các yêu cầu tiếp theo của cùng phép tính hoặc phản hồi được truy cập và xử lý nhanh hơn. Các pattern trong caching 3. Local cache Ưu điểm của Local cache: ● Đơn giản, dễ sử dụng. Nhược điểm của Local cache: ● Khả năng scale không tốt.

Distributed cache Ưu điểm của Distributed cache: ● Sử dụng các thuật toán hash để phân mảnh data và lưu chúng trên nhiều node khác nhau. ● Tận dụng Redis, Memcache… làm backing data store. ● Khả năng scale, chịu lỗi và khả năng phục hồi tốt. Nhược điểm của Distributed cache: ● Độ trễ lớn hơn so với Local cache.

Reverse proxy cache Ưu điểm của Reverse proxy cache: ● Giảm tải cho server. ● Cache HTTP request khi Client thực hiện các request lặp lại nhiều lần, tăng hiệu suất truy cập. Nhược điểm của Reverse proxy cache: ● Không có khả năng chịu lỗi và phục hồi. ● Phụ thuộc vào API Gateway dẫn đến mức độ availability không cao.

Sidecar cache Sidecar là một container khác nằm trong một container chính để hỗ trợ chức năng cho service chạy trong container chính. Ưu điểm của Reverse proxy cache: ● Độ trễ thấp vì sidecar cache hoạt động như local cache. ● Dữ liệu cache không chiếm nhiều bộ nhớ cho ứng dụng đang hoạt động. Nhược điểm của Reverse proxy cache: ● Chỉ có thể triển khai khi dùng các nền tảng hỗ trợ containerized như Kubernetes.

● Nếu Pod phải khởi động lại khi gặp sự cố nào đó thì cả container sẽ phải khởi động lại và dữ liệu cache sẽ bị xóa. Reverse proxy sidecar cache Đây là sự kết hợp giữa Reverse-proxy và Sidecar cache, được tạo bằng cách chạy Reverse-proxy container và cache data container trên cùng một Pod. Trong cơ chế này thì chỉ có các phản hồi API mới được lưu vào Sidecar cache nhằm phục vụ cho các yêu cầu lặp đi lặp lại.

Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ