đồ án 1 thiết kế và xây dựng hệ thống với net core

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ụngkiến trúc Client - Server như hình dưới:Luồng hoạ

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

MỤC LỤC

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

1.1 Thiết kế trong các hệ thống nhỏ và trong các hệ thống lớn 51.2 Các nguyên lý thiết kế hệ thống 6

1.2.4 Fault tolerance 81.2.4.1 Các khái niệm về fault tolerance 81.2.4.2 Byzantine fault 8

3.2.2 Distributed cache 163.2.3 Reverse proxy cache 16

3.2.5 Reverse proxy sidecar cache 183.3 Làm trống cache (Cache eviction) 183.4 Các pattern truy cập trong caching 19

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

5.1 Phân loại service discovery 24

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

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

7.2.1 Khái quát về Raft 30

9.1.1 Services & Dependency injection 38

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

Đố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ụngkiế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ủachúng ta thông qua tên miềnapi.mysite.com

2 Đị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

3 Sau khi có được địa chỉ IP của website, HTTP request từ người dùng sẽ đượcgửi trực tiếp tới web server của chúng ta

4 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 truycậ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ạyriê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 serverchạy đồng thời song song và đảm bảo chi khi tối ưu khi vận hà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 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…) choserver Đâ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 takhô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

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àycàng được rút ngắn và gần như không để hiện tượng sập xảy ra.

1.2.3 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ùngphải đảm bảo thấy được dữ liệu như nhau, đồng nhất ngay cả khi thực hiện các thaotác cập nhật dữ liệu

1.2.4 Fault tolerance

1.2.4.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ốngkhô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)

1.2.4.2 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ệcmộ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ự đồngthuậ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 đồngthuậ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.1 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 webservers Đây là một thành phần cực kỳ quan trọng cho hệ thống sử dụng đồng thờinhiề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

2.2 Phân loại

2.2.1 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ùychỉ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ănglê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ậnhà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àotrong 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 trongkhi 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ốngcân bằng tải vật lý

2.2.2 Tầng xử lý

Layer 7 load balancer: hoạt động ở tầng application - tầng cao nhất trong mô hìnhOSI, 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ủacá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ìnhOSI, sử dụng thông tin về địa chỉ IP và cổng TCP/UDP để đưa ra quyết định địnhtuyến Layer 3/4 load balancer thường không kiểm tra nội dung gói tin và chỉ chuyểntiế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ơitrê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 raquyết định định tuyến

2.3 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ếtnối nhất

● Weighted Least Connections: tương tự như Least Connections, nhưng cho phépgá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ánmộ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

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ộtdị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ề.

2.5 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 đíchthô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 Serverbằng cách sao chép dữ liệu sơ cấp sang dạng thứ cấp thông qua các networktransactions, 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ườngxuyên được truy cập, sử dụng cho máy chủ thứ cấp và sơ cấp Giải pháp nàycầ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ầnphải thiết lập Windows Clustering

Chương 3: Caching

3.1 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ồithườ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ínhhoặc phản hồi được truy cập và xử lý nhanh hơn

3.2 Các pattern trong caching

3.2.1 Local cache

Ưu điểm của Local cache:

● Đơn giản, dễ sử dụng

● Có độ trễ thấp

Nhược điểm của Local cache:

● Khả năng scale không tốt

3.2.2 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 nodekhá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

3.2.3 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ănghiệ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

3.2.4 Sidecar cache

Sidecar là một container khác nằm trong một container chính để hỗ trợ chức năng choservice 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

3.2.5 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ạyReverse-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ằmphục vụ cho các yêu cầu lặp đi lặp lại

Thừa hưởng cả ưu điểm và nhược điểm của Reverse-proxy và Sidecar cache

3.3 Làm trống cache (Cache eviction)

Cache eviction là quá trình loại bỏ các dữ liệu cũ, không được sử dụng thường xuyênhoặc có dung lượng quá lớn ra khỏi cache nhằm tạo ra không gian trống cho các tệpmới

Chúng ta có thể xóa cache tự động hoặc tự định nghĩa để quyết định khi nào dữ liệucần được giải phóng

3.4 Các pattern truy cập trong caching

3.4.1 Cache-aside

Là cơ chế cache thường được sử dụng nhất, mô hình hoạt động của nó như sau:

Cơ chế này thường được dùng cho trường hợp đọc nhiều và ghi ít Ngoài ra còn phụthuộc vào việc dữ liệu trả về có thay đổi hay không (truy vấn theo primary key thìthường hiếm khi thay đổi)

3.4.2 Read-through

Chiến lược này khá giống với cache-aside, thay vì application phải kết nối với cache

và database, giờ đây application chỉ cần giao tiếp với cache còn cache sẽ tự lấy dữ liệu

ở chính nó hoặc lấy dữ liệu từ database Trong trường hợp này, cache chính làdatabase chính của ứng dụng và đóng vai trò rất quan trọng trong hệ thống Vớicache-aside, việc cache bị chết thì ứng dụng vẫn chạy được, nhưng với read throughcache, nếu cache chết thì ứng dụng chết

3.4.3 Write-through

Với chiến lược này, data sẽ được lưu xuống cache, cache sẽ lưu dữ liệu vào database

Khi một request write tới:

● Dữ liệu sẽ được lưu vào cache

● Cache sẽ gửi yêu cầu lưu dữ liệu vào database ngay lập tức

● Write-through: lưu dữ liệu từ cache xuống database một cách đồng bộ.

● Write-back: lưu dữ liệu từ cache xuống database bất đồng bộ.

Khi một request write tới:

● Dữ liệu sẽ được lưu vào cache

● Sau một khoảng thời gian, cache sẽ gửi yêu cầu lưu dữ liệu vào database

Chương 4: Microservices

4.1 Miêu tả microservice

Nền tảng của kiến trúc microservices là xây dựng một ứng dụng mà ứng dụng này làtổng hợp của nhiều services nhỏ và độc lập có thể chạy riêng biệt, phát triển và triểnkhai độc lập

Ta có thể giải quyết các vấn đề của ứng dụng một khối bằng kiến trúc microservices(nhiều dịch vụ nhỏ) Ý tưởng là chia nhỏ ứng dụng lớn ra thành các dịch vụ nhỏ kếtnối với nhau

Mỗi dịch vụ nhỏ thực hiện một tập các chức năng chuyên biệt như quản lý đơn hàng,quản lý khách hàng 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 Một số dịch vụ nhỏ lộ ra giao tiếp lậptrình API cho dịch vụ nhỏ khác hay ứng dụng client gọi tới Khi vận hành, mỗi dịch

vụ nhỏ được chạy trong một máy ảo hoặc Docker container

Mỗi vùng chức năng bây giờ được thực thi bởi một dịch vụ nhỏ Ứng dụng web cũng

có thể chia nhỏ hơn chuyên cho từng đối tượng người dùng (hành khách/tài xế) Thiết

kế giao diện cho từng đối tượng người dùng giúp tối ưu trải nghiệm tốt hơn, tốc độnhanh hơn, dễ tương thích hơn trong khi chức năng tối giản hơn

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

Remote Procedure Invocation (RPI): sử dụng RPI để liên lạc giữa các service, client

sử dụng một request/reply-based protocol để tạo request đến service

Một vài pattern cho RPI:

● REST

● gRPC

● Apache Thrift

Messaging: sử dụng asynchronous messaging để giao tiếp giữa các services Các

services trao đổi message qua các kênh message

Một vài pattern về asynchronous messaging:

● Apache Kafka

● RabbitMQ

Domain-specific protocol: trong một vài trường hợp đặc biệt chúng ta không thể sử

dụng RPI hay Messaging mà thay vào đó cần dùng domain-specific protocol cho việcgiao tiếp giữa các services

Một vài ví dụ cụ thể về domain-specific protocol:

● Email protocols như: SMTP, IMAP

● Media streaming protocols như: RTMP, HLS, và HDS

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

Cần triển khai việc giao tiếp giữa nhiều inter-services

Handle partial failure là rất phức tạp vì một luồng xử lý cần đi qua nhiều services

Việc thực hiện các requests trải rộng trên nhiều services, điều này cũng đòi hỏi sự phốihợp cẩn thận giữa các teams

Khó khăn khi debug và fix bug: khi một service gặp lỗi do liên quan tới nhiều servicekhác thì xảy ra trường hợp mức độ ưu tiên để giải quyết lỗi trong team này thì khẩncấp nhưng với team khác lại không cao dẫn đến khó khăn khi fix bug

Khó khăn trong việc đảm bảo toàn vẹn CSDL nếu triển khai theo kiến trúc cơ sở dữliệu phân vùng

Triển khai và quản lý microservices nếu làm thủ công theo cách đã làm với ứng dụngmột khối phức tạp hơn rất nhiều

Phải xử lý sự cố khi kết nối chậm, lỗi khi thông điệp không gửi được hoặc thông điệpgửi đến nhiều đích đến vào các thời điểm khác nhau

Chương 5: Service discovery & API Gateway

5.1 Phân loại service discovery

Client-side: theo cách tiếp cận này, client hoặc API gateway sẽ có được vị trí của mộtservice instance bằng cách truy vấn một service registry

Server-side: với phương pháp này, client/API gateway sẽ gửi một request đến mộtcomponent (ví dụ như một load balancer) chạy trên một location đã biết Component

đó sẽ gọi đến service registry và xác định vị trí location mà request cần đến

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

Self registration: service sẽ tự động đăng ký với registry khi nó khởi động Điều nàythường được thực hiện bằng cách sử dụng một thư viện client tích hợp với service,cho phép service giao tiếp với registry và cung cấp thông tin cần thiết để đăng ký