tiểu luận môn học môn học kiến trúc thiết kế phần mềm đề tài xây dựng hệ thống ecomsys

Thống kê dự án kiến trúc hướng dịch vụ với Django và nghề nghiệp hiện nay:...6Yêu cầu tích hợp AI/deep learning vào các hệ thống:...7 Chương 1: Kiến trúc monolithic và microservice...7 1

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

KHOA CÔNG NGHỆ THÔNG TIN 1

-BÀI TIỂU LUẬN MÔN HỌC

MÔN HỌC: KIẾN TRÚC & THIẾT KẾ PHẦN MỀM.

Đề tài : Xây dựng hệ thống EcomSys

Giảng viên hướng dẫn: Trần Đình Quế

LỜI CẢM ƠN

Lời đầu tiên, em xin được gửi lời cảm ơn chân thành nhất đến thầy Trần Đình

Quế Trong quá trình học tập và tìm hiểu môn Phát Triển Phần Mềm Hướng Dịch Vụ, em đã nhận được rất nhiều sự quan tâm, giúp đỡ, hướng dẫn tâm huyết

và tận tình của thầy Thầy đã giúp em tích lũy thêm nhiều kiến thức về môn học

này để có thể hoàn thành được bài tiểu luận về đề tài: Xây dựng hệ thống

EcomerceSys

Trong quá trình làm bài chắc chắn khó tránh khỏi những thiếu sót Do đó, em kính mong nhận được những lời góp ý của thầy/cô để bài tiểu luận của em ngày càng hoàn thiện hơn

Em xin chân thành cảm ơn!

Mục lục

Mở đầu 5

Lý do học kiến trúc phần mềm: 6

Nghề nghiệp liên quan đến kiến trúc phần mềm: 6

Các kiểu kiến trúc phần mềm và đặc biệt kiến trúc hướng dịch vụ: 6

Thống kê dự án kiến trúc hướng dịch vụ với Django và nghề nghiệp hiện nay: 6

Yêu cầu tích hợp AI/deep learning vào các hệ thống: 7

Chương 1: Kiến trúc monolithic và microservice 7

1.1 Giới thiệu 7

1.1.1 Mục đích: Kiến trúc Monolithic được sử dụng để xây dựng ứng dụng phần mềm bằng cách tích hợp tất cả các thành phần và chức năng vào một đơn vị lớn 7

1.1.2 Sử dụng để làm gì: Được sử dụng cho các ứng dụng đơn giản hoặc có quy mô nhỏ đến trung bình như các trang web tĩnh, ứng dụng di động đơn giản, hoặc các ứng dụng doanh nghiệp nhỏ .7

1.1.3 Ưu điểm: Dễ dàng triển khai và duy trì, ít phức tạp trong việc quản lý và phát triển 7

1.1.4 Nhược điểm: Khó mở rộng khi ứng dụng phát triển lớn, khó khăn trong việc sử dụng công nghệ mới, không linh hoạt trong việc triển khai và quản lý .7

1.1.5 Mục đích: Kiến trúc Microservices tách ứng dụng thành các dịch vụ nhỏ, độc lập với nhau, mỗi dịch vụ chịu trách nhiệm cho một phần cụ thể của ứng dụng 8

1.1.6 Sử dụng để làm gì: Thích hợp cho các ứng dụng lớn, phức tạp, yêu cầu mở rộng linh hoạt và có khả năng mở rộng dễ dàng theo nhu cầu 8

1.1.7 Ưu điểm: Linh hoạt, dễ mở rộng và duy trì, có khả năng triển khai độc lập cho từng dịch vụ, cho phép sử dụng nhiều ngôn ngữ lập trình và công nghệ 8

1.1.8 Nhược điểm: Phức tạp trong việc quản lý và triển khai do có nhiều thành phần, đòi hỏi kỹ năng quản lý hệ thống và mạng lưới cao 8

1.2 Kiến trúc monolithic (Kiến trúc một khối) 8

1.2.1 Khái niệm 8

Những ưu điểm của kiến trúc một khối 9

1.2.2 Viết tắt 11

1.2.3 Kiến trúc và giao thức 11

1.2.4 Sử dụng giao thức HTTP 11

1.2.5 Các dạng format được support 11

1.2.5 Tốc độ 11

1.2.6 Băng thông 11

1.2.7 Transport Independence 11

1.2.8 Tài nguyên 12

1.2.9 Bảo mật 12

1.2.10 Caching 12

1.2.11 Tiếp cận 12

1.2.12 Ví dụ 12

1.3 Kiến trúc microservice 13

1.3.1 Khái niệm 13

1.3.2 Những ưu nhược điểm của kiến trúc microservice 14

1.3.3 Các công nghệ phát triển hệ microservice 15

1.4 Phân rã Hệ thống phần mềm thành các service 17

1.4.1 Mỗi microservice nên có một database riêng biệt 17

1.4.2 Giữ source code của microservice ở mức hợp lý 19

1.4.3 Tạo build script cho mỗi microservice 19

1.4.4 Triển khai mỗi microservice bên trong một app (docker container) 19

1.4.5 Stateless server 19

Kết luận 20

Chương 2: Kiến trúc Hệ thống ecomSys dựa trên Django 20

2.1 Mô tả Hệ ecomSys 20

2.2 Kỹ thuật và Công nghệ Django 21

2.3 Phân rã Hệ ecomSys dựa trên Django 21

Kết luận 23

Chương 3: Thiết kế và xây dựng hệ ecomSys 23

3.1 Giới thiệu 23

3.2 Mô tả yêu cầu các chức năng và phi chức năng của hệ thống bằng ngôn ngữ tự nhiên 24

3.3 Các biểu đồ đặc tả hệ ecomSys 26

3.3.1 Biểu đồ use case 26

3.3.2 Biểu đồ hoạt động/swimlane 32

3.3.3 Biểu đồ lớp phân tích cho từng service 32

3.3.4 Mô hình Data- kiểu/công nghệ dữ liệu 33

3.3.5 Biểu đồ lớp thiết kế cho từng service 33

3.6 Xây dựng hệ ecomSys 34

Module (service/project) user 34

Module Cart 37

Module search 43

Module product 45

Module Manager 68

Module order 71

Thiết kế giao diện (đang trong quá trình hoàn thiện) 74

Login 74

All product 76

Add to cart 76

Cart 76

Profile 76

List category 76

List book 77

Thiết kế database 77

Kết luận 79

Những gì đã đạt được: 79

Hiểu rõ cấu trúc hệ thống: 79

Nâng cao hiệu suất: 79

Thích ứng với công nghệ mới: 79

Những vấn đề chưa giải quyết: 80

Sự phức tạp của dự án: 80

Thiếu kinh nghiệm thực tế: 80

Liên kết với doanh nghiệp: 80

Nâng cao kỹ năng mềm: 80

Mở đầu

Lý do học kiến trúc phần mềm:

Hiểu rõ hệ thống: Học các kiểu kiến trúc phần mềm giúp sinh viên hiểu rõ hơn về cấu trúc và cách hoạt động của các hệ thống phần mềm phức tạp, từ đó có thể thiết

kế, triển khai và bảo trì chúng một cách hiệu quả Tối ưu hóa hiệu suất: Kiến thức

về kiến trúc phần mềm giúp tối ưu hóa hiệu suất, độ tin cậy và khả năng mở rộngcủa hệ thống Cải thiện khả năng hợp tác: Nắm vững các kiểu kiến trúc giúp cảithiện khả năng giao tiếp và hợp tác giữa các thành viên trong nhóm phát triển phầnmềm Tích hợp công nghệ mới: Hiểu biết về kiến trúc phần mềm là nền tảng quantrọng để tích hợp các công nghệ mới như AI, machine learning, và các công cụphát triển hiện đại khác Quản lý dự án tốt hơn: Kiến thức này giúp quản lý dự ánphần mềm một cách hiệu quả hơn, từ khâu lập kế hoạch, thiết kế đến triển khai vàbảo trì

Nghề nghiệp liên quan đến kiến trúc phần mềm:

Kiến trúc sư phần mềm (Software Architect): Thiết kế cấu trúc tổng thể của hệthống phần mềm Kỹ sư phần mềm cao cấp (Senior Software Engineer): Tham giavào việc thiết kế và phát triển các thành phần chính của hệ thống Quản lý dự áncông nghệ thông tin (IT Project Manager): Quản lý các dự án phát triển phần mềm,đảm bảo tuân thủ các nguyên tắc kiến trúc Chuyên gia tư vấn công nghệ thông tin(IT Consultant): Tư vấn cho các doanh nghiệp về lựa chọn và triển khai các kiếntrúc phần mềm phù hợp Kỹ sư hệ thống (Systems Engineer): Thiết kế và quản lý

cơ sở hạ tầng hệ thống, đảm bảo tích hợp liền mạch với phần mềm

Các kiểu kiến trúc phần mềm và đặc biệt kiến trúc hướng dịch vụ:

Kiến trúc đơn tầng (Monolithic Architecture): Tất cả các chức năng của ứng dụngđược tích hợp trong một khối duy nhất Kiến trúc tầng (Layered Architecture):Chia hệ thống thành các tầng như tầng trình bày, tầng logic nghiệp vụ, và tầng dữliệu Kiến trúc vi dịch vụ (Microservices Architecture): Chia hệ thống thành cácdịch vụ nhỏ, độc lập có thể phát triển và triển khai riêng biệt Kiến trúc hướng sựkiện (Event-Driven Architecture): Hệ thống phản ứng với các sự kiện trong thờigian thực Kiến trúc hướng dịch vụ (Service-Oriented Architecture - SOA): Sửdụng các dịch vụ được định nghĩa rõ ràng và giao tiếp qua mạng để thực hiện cácchức năng của hệ thống

Thống kê dự án kiến trúc hướng dịch vụ với Django và nghề nghiệp hiện nay: Django và SOA: Django, một framework Python phổ biến, có thể được sử dụng đểtriển khai các dịch vụ trong kiến trúc SOA nhờ vào sự hỗ trợ tốt cho RESTful API

và dễ dàng tích hợp với các công nghệ khác Thống kê: Dự án Open Source: Nhiều

dự án mã nguồn mở sử dụng Django trong kiến trúc SOA để xây dựng các ứngdụng web phức tạp và có khả năng mở rộng Doanh nghiệp: Nhiều công ty lớn vàstartup áp dụng Django trong kiến trúc SOA để phát triển các ứng dụng dịch vụtrực tuyến, như các nền tảng e-commerce, quản lý nội dung, và hệ thống thông tin

Yêu cầu tích hợp AI/deep learning vào các hệ thống:

E-commerce: Sử dụng AI để cá nhân hóa trải nghiệm mua sắm, dự đoán nhu cầukhách hàng, và quản lý kho hàng thông minh Hệ quản lý nhân sự: AI giúp tự độnghoá quy trình tuyển dụng, phân tích hiệu suất làm việc, và quản lý phát triển nhânviên Quản lý thư viện: Deep Learning có thể được dùng để phân loại tài liệu, đềxuất sách, và quản lý thông tin người dùng hiệu quả Giao thông: AI hỗ trợ tối ưuhóa lộ trình giao thông, quản lý tín hiệu đèn giao thông, và dự đoán lưu lượng giaothông Quản lý dịch vụ: AI giúp tối ưu hoá quy trình dịch vụ, tự động hóa các côngviệc thủ công, và cải thiện trải nghiệm khách hàng thông qua các chatbot thôngminh

Chương 1: Kiến trúc monolithic và microservice

1.1 Giới thiệu

- Kiến trúc Monolithic:

1.1.1 Mục đích: Kiến trúc Monolithic được sử dụng để xây dựng ứng dụng phần mềm bằng cách tích hợp tất cả các thành phần và chức năng vào một đơn vị lớn.1.1.2 Sử dụng để làm gì: Được sử dụng cho các ứng dụng đơn giản hoặc có quy

mô nhỏ đến trung bình như các trang web tĩnh, ứng dụng di động đơn giản, hoặc các ứng dụng doanh nghiệp nhỏ

1.1.3 Ưu điểm: Dễ dàng triển khai và duy trì, ít phức tạp trong việc quản lý và pháttriển

1.1.4 Nhược điểm: Khó mở rộng khi ứng dụng phát triển lớn, khó khăn trong việc

sử dụng công nghệ mới, không linh hoạt trong việc triển khai và quản lý

- Kiến trúc Microservices:

1.1.5 Mục đích: Kiến trúc Microservices tách ứng dụng thành các dịch vụ nhỏ, độc lập với nhau, mỗi dịch vụ chịu trách nhiệm cho một phần cụ thể của ứng dụng.1.1.6 Sử dụng để làm gì: Thích hợp cho các ứng dụng lớn, phức tạp, yêu cầu mở rộng linh hoạt và có khả năng mở rộng dễ dàng theo nhu cầu.

1.1.7 Ưu điểm: Linh hoạt, dễ mở rộng và duy trì, có khả năng triển khai độc lập cho từng dịch vụ, cho phép sử dụng nhiều ngôn ngữ lập trình và công nghệ

1.1.8 Nhược điểm: Phức tạp trong việc quản lý và triển khai do có nhiều thành phần, đòi hỏi kỹ năng quản lý hệ thống và mạng lưới cao

1.2 Kiến trúc monolithic (Kiến trúc một khối)

1.2.1 Khái niệm

Kiến trúc một khối là mẫu thiết kế được dùng nhiều nhất trong giới lập trình web hiện nay bởi tính đơn giản của nó khi phát triển và khi deploy Mặc dù mỗiứng dụng sẽ được triển khai theo những cách khác nhau, nhưng nhìn chung thì khi ứng dụng được lập trình theo kiến trúc một khối, kết quả thường đạt được như sau:

● Nó có thể hỗ trợ nhiều loại client như browser hay các app native trên cả desktop và mobile

● Nó có thể expose API cho bên thứ ba

● Nó có thể tích hợp với các ứng dụng khác thông qua REST/SOAP web service hoặc các message queue

● Nó có thể xử lý các request dạng HTTP, thực hiện logic nghiệp vụ, truy cập cơ sở dữ liệu và có thể trao đổi dữ liệu với các hệ thống khác

● Nó có thể chạy trên các container như Tomcat, JBoss,

● Nó có thể scale theo chiều ngang (vertical scalability) bằng cách tăng sứcmạnh của phần cứng hoặc scale theo chiều dọc (horizontal scalability) bằng cách load balancers

toán, thông báo cho khách hàng / khách sạn, v.v Ứng dụng sẽ được đóng gói và deploy bằng một file Web Application Archive (WAR) duy nhất và được chạy trênmột container như Tomcat và có thể scale bằng load balancer Hãy xem diagram dưới đây:

Những ưu điểm của kiến trúc một khối

- Ưu điểm:

● Dễ phát triển vì các stack công nghệ thống nhất ở tất cả các layer

● Dễ test do toàn bộ project được đóng gói trong một package nên dễ dàng chạy test integration và test end-to-end

● Deploy đơn giản và nhanh chóng nếu bạn chỉ có một package để bận tâm

● Dễ scale vì chúng ta có thể có nhiều instance cho load balancer

● Yêu cầu team size nhỏ cho việc maintain app

● Team member có thể chia sẻ ít nhiều về skill

● Tech stack đơn giản và đa số là dễ học

● Phát triển ban đầu nhanh hơn do đó có thể đem sale hoặc marketing nhanh hơn.

● Yêu cầu cơ sở hạ tầng đơn giản Thậm chí một container đơn giản cũng

● Theo thời gian thì project trở nên phức tạp và lớn dần Các tính năng mới

sẽ mất nhiều thời gian hơn để phát triển và tái cấu trúc các tính năng hiện

có sẽ nhiều khó khăn hơn

● Toàn bộ ứng dụng cần được triển khai lại cho bất kỳ thay đổi nào

● Không hề dễ để hiểu project do các module liên quan chặt chẽ lẫn nhau Một issue nhỏ cũng có thể làm chết toàn bộ ứng dụng

● Áp dụng công nghệ mới khó khăn vì toàn bộ ứng dụng phải thay đổi Do

đó nhiều ứng dụng một khối thường phụ thuộc một công nghệ cũ và lỗi thời

● Các service quan trọng không thể scale riêng dẫn đến lãng phí tài nguyên

vì toàn bộ ứng dụng phải scale theo

● Các ứng dụng một khối lớn sẽ có thời gian khởi động lâu và tốn tài

nguyên CPU cũng như bộ nhớ

● Các team tham gia vào dự án phải phụ thuộc lẫn nhau và tất khó để mở rộng quy mô team

- Có 2 cách để triển khai là REST & SOAP

● Cả 2 loại SOAP và RESTful đều cho phép phía client gửi request đến server để query, nhưng chúng được thực hiện bằng những cách khác nhau Sự khác nhau chính giữa SOAP và REST là cách mà client giao tiếp server thông qua SOAP sẽ bị hạn chế bởi nhiều quy tắc và format được thiết kế chính xác, trong khi với REST cho phép việc giao tiếp thông qua giao thức HTTP và ít các quy tắc rườm rà hơn Từ khi các request HTTP như GET và POST trở nên quen thuộc hơn thì việc sử dụng REST dần trở nên phổ biến, dễ chịu hơn so với thời kỳ SOAP cùng với cấu trúc WSDL đầy quy tắc và luật lệ trước đó Trong bài viết này, chúng ta sẽ cùng xem sự khác biệt giữa SOAP và REST cũng như lợi thế và hạn chế của mỗi loại

● Sự khác nhau giữa REST và SOAP trong Java

* Dưới đây là một vài khác biệt cơ bản giữa REST, RESTful và SOAP

1.2.2 Viết tắt

REST là viết tắt của Representational State Transfer (Chuyển giao trạng thái phản hồi) trong khi SOAP là Simple Object Access Protocol(Giao thức truy cập đối tượng đơn giản)

1.2.3 Kiến trúc và giao thức

REST là một kiểu kiến trúc, từ đó RESTful web service được xây dựng trong khi SOAP là một chuẩn được tạo ra để chuẩn hóa giao tiếpgiữa client và server về format, structure và method

1.2.4 Sử dụng giao thức HTTP

REST thừa hưởng tất cả những lợi ích của giao thức HTTP, bao gồm các method như GET, POST, PUT và DELETE để thực hiện các hànhđộng truy vấn, thêm, sửa, xóa dữ liệu Trong khi đó SOAP sử dụng các message dạng XML để giao tiếp với server

1.2.5 Các dạng format được support

RESTful web service có thể trả về dữ liệu dưới dạng JSON, XML hoặc HTML, trong khi nếu sử dụng SOAP web service thì chúng ta chỉ có thể sử dụng XML bởi vì các quy tắc trong một message SOAP

đã được định nghĩa sẵn trong định dang XML

1.2.7 Transport Independence

Vì các message của SOAP được đóng gói trong một định dạng đặc biệt nên nó có thể gửi qua bất kỳ cơ chế vận chuyển nào như TCP, FTP, SMTP,… Mặt khác thì RESTful phụ thuộc rất nhiều vào giao

thức HTTP Tuy nhiên trong thực tết chúng ta cũng sử dụng giao thức HTTP nhiều hơn nên lợi thế này của SOAP cũng không mấy được coitrọng

1.2.8 Tài nguyên

RESTful sử dụng URL để xác định tài nguyên mong muốn được truy cập trong khi SOAP sử dụng các message dạng XML để xác định các thủ tục hay tài nguyên yêu cầu

1.2.10 Caching

RESTful web service tận dụng tối đa cơ chế caching vì về cơ bản chúng dựa trên URL Mặt khác, các dịch vụ web SOAP hoàn toàn bỏ qua caching web

1.2.11 Tiếp cận

Trong các dịch vụ web dựa trên REST, mọi thực thể đều tập trung vàocác tài nguyên, trong khi trong trường hợp dịch vụ web SOAP, mọi thực thể đều tập trung vào các interface và message

1.2.12 Ví dụ

Giả sử bạn muốn truy xuất thời tiết hôm nay cho một thành phố cụ thể

từ một máy chủ cung cấp thông tin thời tiết, URL RESTful của bạn sẽtrông giống như http://weatherdata.org/data/weather/uk/london, rất giống một request HTTP như http://weatherdata.org/data/weather?q=uk,London Bên cạnh đó thì để có được cùng một dữ liệu bằng SOAP, bạn cần tạo một thông báo XML có tiêu đề và nội dung và gửi

nó

http://www.webservicex.net/globalweather.asmx?op=GetWeather Tóm lại, RESTfull đơn giản, linh hoạt và dễ chịu hơn nhiều so với SOAP trong Java

1.3 Kiến trúc microservice

1.3.1 Khái niệm

Đây là loại kiến trúc đang dần trở nên phổ biến trong những năm gần đây nhờ khả năng module hóa và khả năng mở rộng Kiến trúc microservice có thể cung cấp hầu hết các tính năng của một ứng dụng một khối Ngoài ra, nó cung cấp nhiều tính năng và linh hoạt hơn, do đó nó là sự lựa chọn ưu việt cho ứng dụng phức tạp Không giống như kiến trúc một khối, khá khó để khái quát hóa kiến trúc microservice vì nó có thể thay đổi nhiều tùy thuộc vào trường hợp sử dụng và triển khai Nhưng nhìn chung thì chúng cũng có một số đặc điểm như sau:

● Các component trong kiến trúc microservice liên kết khá lỏng lẻo (loose coupling) Các component có thể được phát triển, test, deploy

và scale độc lập mà không ảnh hưởng đến các component khác

● Các component không cần phải được phát triển cùng một stack công nghệ Điều này có nghĩa là một component có thể chọn stack công nghệ và ngôn ngữ lập trình của riêng nó

● Chúng thường sử dụng các tính năng nâng cao như truy tìm dịch vụ (service discovery), circuit breaking, cân bằng tải (load balance),…

● Các component chủ yếu là nhẹ và chúng làm theo chức năng riêng biệt Ví dụ dịch vụ xác thực sẽ chỉ quan tâm xác thực người dùng vào

hệ thống

● Thường có một thiết lập giám sát (monitor) và xử lý sự cố

1.3.2 Những ưu nhược điểm của kiến trúc microservice

Ưu điểm:

● Các component có kết nối lỏng lẻo dẫn đến dễ cách ly, dễ test và khởi động nhanh

● Vòng đời phát triển nhanh hơn Tính năng mới được phát triển nhanh hơn

và tính năng cũ được cấu trúc lại dễ hơn

● Các service có thể deploy độc lập nên ứng dụng dễ đọc, dễ tạo các bản váhơn

● Những issue, ví dụ liên quan đến memry leak một trong các service, bị côlập và có thể không làm sập ứng dụng

● Việc áp dụng các công nghệ mới dễ hơn Các component có thể được nâng cấp độc lập với nhau

● Các mô hình scale phức tạp và hiệu quả hơn có thể được thiết lập Các service quan trọng có thể scale hiệu quả hơn Các component riêng sẽ khởi động nhanh hơn và cải thiện thời gian khởi động của cả hệ thống.

● Các team tham gia sẽ ít phụ thuộc lẫn nhau Kiến trúc này rất thích hợp cho các đội Agile

Nhược điểm:

● Phức tạp hơn về mặt tổng thể vì các component khác nhau có các stack công nghệ khác nhau nên buộc team phải tập trung đầu tư thời gian để theo kịp công nghệ

● Khó thực hiện test end-to-end và integration test vì có nhiều stack công nghệ khác nhau

● Deploy toàn bộ ứng dụng phức tạp hơn vì có nhiều container và nền tảng

ảo hóa liên quan

● Ứng dụng được scale hiệu quả hơn nhưng thiết lập nâng cấp sẽ phức tạp hơn vì nó sẽ yêu cầu nâng cao nhiều tính năng như truy tìm dịch vụ (service discovery), định tuyến DNS,…

● Yêu cầu một team-size lớn để maintain ứng dụng vì có nhiều component

và công nghệ khác nhau

● Các thành viên trong team chia sẻ các skill khác nhau dựa trên

component họ làm nên sẽ tạo ra sự khó khăn khi thay thế và chia sẻ kiến thức

● Stack công nghệ phức tạp và khó để học hơn

● Thời gian phát triển ban đầu là chậm nên thời gian để có thể làm

marketing lâu hơn

● Yêu cầu cơ sở hạ tầng phức tạp Thông thường sẽ yêu cầu nhiều

container (Docker) và nhiều máy JVM để chạy

1.3.3 Các công nghệ phát triển hệ microservice

● Netflix:

Dự án: Netflix Streaming Platform

Mô tả: Netflix đã chuyển từ kiến trúc monolithic sang kiến trúc

microservices để hỗ trợ quy mô lớn, đồng thời cải thiện tính linh hoạt và hiệu suất

● Amazon:

Dự án: Amazon Web Services (AWS).

Mô tả: AWS cung cấp hàng loạt các dịch vụ phân tán dựa trên kiến trúc microservices, bao gồm EC2, S3, và DynamoDB

● Google:

Dự án: Google Cloud Platform (GCP)

Mô tả: GCP cung cấp các dịch vụ đám mây phân tán sử dụng kiến trúc microservices, bao gồm Google Kubernetes Engine (GKE) và Google Cloud Functions

● Facebook:

Dự án: Facebook Platform

Mô tả: Facebook đã chuyển từ kiến trúc monolithic sang kiến trúc

microservices để hỗ trợ quy mô lớn và cải thiện tốc độ phát triển

● Microsoft:

Dự án: Microsoft Azure

Mô tả: Azure cung cấp các dịch vụ đám mây dựa trên kiến trúc

microservices, bao gồm Azure Kubernetes Service (AKS) và Azure

Functions

● Uber:

Dự án: Uber Platform

Mô tả: Uber đã chuyển từ kiến trúc monolithic sang kiến trúc microservices

để hỗ trợ quy mô lớn và cải thiện tính linh hoạt trong việc phát triển và triểnkhai dịch vụ

1.4 Phân rã Hệ thống phần mềm thành các service

Sơ đồ trên là một thể hiện của mô hình microservice Trên thực tế mô hìnhmicroservice được áp dụng vào các sản phẩm có rất nhiều biến thể, sẽ rất khó để cómột mô hình phù hợp và chính xác cho từng bài toán

Theo kiến trúc trên, một ứng dụng được chia thành một bộ các microservice, mỗimicroservice thực chất là một service có thể được triển khai và chạy độc lập.Chúng tách biệt về mặt mã nguồn, về hoạt động và dữ liệu Mỗi microservice cónơi chứa dữ liệu của riêng của nó và chỉ có nó có quyền truy cập vào vùng dữ liệunày Do các microservice là độc lập, chúng không giao tiếp trực tiếp với nhau màqua một thành phần trung gian được gọi là API gateway Có thể thấy vai trò củaAPI gateway rất quan trọng trong mô hình microservice Nó là điểm đến và đi củamọi yêu cầu hay phản hồi

1.4.1 Mỗi microservice nên có một database riêng biệt

Việc này đảm bảo cho microservice có tính đóng gói cao Tuy vậy việc phân táchnơi chứa dữ liệu cho mỗi microservice không hề đơn giản, nó là phần khó nhấttrong việc thiết kế ứng dụng phần mềm theo kiến trúc microservice Do đó, rấtnhiều người chọn lựa thiết kế sử dụng chung database cho nhiều microservice

Cách này tồn tại một hạn chế là khi database schema cần thay đổi chomicroservice_01 thì nó sẽ làm ảnh hưởng và gây lỗi cho các microservice khác sửdụng chung database này Để sửa lỗi, ta cần sửa đổi, cập nhật toàn bộ microservicecòn lại để chúng có thể hoạt động với schema mới.

Có một cách tiếp cận khác, giúp tránh được hạn chế trên

Sơ đồ trên, microservice2 không truy cập trực tiếp vào database, thay vào đó nótruy cập database thông qua microservice_01 Do đó việc thay đổi schema củadatabase sẽ không ảnh hưởng tới microservice_02 Tuy nhiên với cách tiếp cận nàythì microservice_02 phụ thuộc vào microservice_01, khi microservice_01 có lỗi thìmicroservice2 cũng bị lỗi theo.

Việc chọn cách tiếp cận nào phụ thuộc rất nhiều vào tình hình thực tế của dự án.Cần cân nhắc thiệt hơn của mỗi phương án để đưa ra lựa chọn cuối cùng

1.4.2 Giữ source code của microservice ở mức hợp lý

Như đã đề cập ở phần ưu và nhược điểm của microservice Kích thước source codecủa một microservice không nên quá nhỏ hoặc quá lớn Tuy nhiên cái khó ở đây làkhông có một con số định lượng cho kích thước của một microservice, nên thôngthường việc quyết định kích thước của một microservice là do kinh nghiệm, cảmtính

1.4.3 Tạo build script cho mỗi microservice

Build script có thể là một file bash hoặc Dockerfile để đóng gói microservice vàobên trong một docker image

1.4.4 Triển khai mỗi microservice bên trong một app (docker container)

Việc triển khai mỗi microservice trong một docker container đem lại rất nhiều lợiích cho việc triển khai và mở rộng ứng dụng cũng như việc phân chia tài nguyênphần cứng cho mỗi microservice Hiện nay có rất nhiều công cụ hỗ trợ cho việcliên tục tích hợp, liên tục triển khai hệ thống microservice Các công cụ này giúptăng hiệu quả làm việc cho các lập trình viên, giảm thời gian phôi phối sản phẩmphần mềm, và các công cụ này đòi hỏi mỗi microservice được đóng gói trong mộtdocker image và triển khai trên app

1.4.5 Stateless server

Khi một yêu cầu được gửi đến server thì một phiên làm việc (session) được mở ra,kèm theo đó là các thông tin của phiên Stateless server là server không lưu thôngtin của phiên Mà thông tin về phiên được lưu ở một nơi khác, như caching serverchẳng hạn

Việc này rất quan trọng, bởi vì mỗi microservice thường được đóng gói thành mộtdocker image Khi muốn cập nhật một microservice, ta cập nhật docker image của

nó, và khi chạy docker image mới (xóa bỏ container cũ và tạo container mới dựatrên image mới) thì toàn bộ thông tin của các phiên hoạt động trên container cũ sẽ

bị mất, thông tin phiên thường bao gồm thông tin mà client gửi tới server, mấtthông tin này là một lỗi vô cùng nghiêm trọng Nếu container là stateless thì nókhông lưu thông tin của các phiên nên không có gì để mất cả

Chương 2: Kiến trúc Hệ thống ecomSys dựa trên Django

2.1 Mô tả Hệ ecomSys

Hệ thống mua hàng của chúng tôi cung cấp một trải nghiệm mua sắm đa dạng và tiện lợi cho khách hàng, bao gồm ba danh mục chính là quần áo, điện thoại di động và sách Với danh mục quần áo, khách hàng có thể lựa chọn từ một loạt các sản phẩm thời trang từ các thương hiệu phổ biến và đa dạng phong cách, từ phong cách thể thao đến dịu dàng và lịch lãm Đối với danh mục điện thoại di động, chúng tôi cung cấp các sản phẩm từ các nhà sản xuất hàng đầu trong ngành, đảm bảo khách hàng có được sự lựa chọn phong phú từ các mẫu smartphone mới nhất đến những chiếc điện thoại cơ bản nhưng đáng tin cậy Cuối cùng, danh mục sách của chúng tôi mang lại một thế giới của tri thức và giải trí, từ sách học thuật đến tiểu thuyết và sách thiếu nhi, đảm bảo rằng có một điều gì đó phù hợp với mọi người Hệ thống thanh toán và giao hàng của chúng tôi được thiết kế để đảm bảo sự tiện lợi

và an toàn cho khách hàng, mang lại trải nghiệm mua sắm trực tuyến tốt nhất có thể

2.2 Kỹ thuật và Công nghệ Django

- Khi một yêu cầu được gửi đến một web server, nó sẽ được chuyển đến Django

để tìm cách hiểu yêu cầu đó thực sự là gì Trước tiên, nó cần một địa chỉ web và

cố gắng phân tích những công việc cần làm Phần này sẽ được thực hiện bởi urlresolver của Django (lưu ý rằng địa chỉ trang web được gọi là URL –

Uniform Resource Locator – vì vậy tên urlresolver khá hợp lý phải không?) Tuy nhiên urlresolver cũng không phải là một công cụ quá thông minh – nó sẽ lấy một danh sách các pattern và cố gắng lần lượt khớp với URL Django kiểm tra các pattern từ trên xuống dưới và nếu có thứ gì đó khớp, Django sẽ chuyển

yêu cầu đó đến view function.

- Hãy tưởng tượng một người vận chuyển thư và một lá thư Người đưa thư đi bộ xuống phố và kiểm tra từng số nhà so với địa chỉ ghi trên lá thư Nếu hai thông tin trùng khớp, người đưa thư sẽ để lại thư ở đó Và đó chính là cách hoạt động của urlresolver!

- Tất cả những điều thú vị sẽ diễn ra trong chức năng view: chúng ta có thể nhìn vào cơ sở dữ liệu để tìm kiếm một số thông tin Có thể người dùng yêu cầu thayđổi điều gì đó trong dữ liệu? Giống như một bức thư ghi, “Vui lòng thay đổi mô

tả công việc của tôi.”, view có thể kiểm tra xem bạn có được phép làm điều đó hay không, sau đó cập nhật mô tả công việc cho bạn và gửi lại thông báo: “Đã thay đổi mô tả công việc!” Sau đó, view tạo ra một phản hồi và Django có thể gửi phản hồi đó đến trình duyệt web của người dùng

2.3 Phân rã Hệ ecomSys dựa trên Django

❖ Hệ ecomSys sẽ được phân rã thành các service như sau:

o Dịch vụ người dùng: Dịch vụ này liên quan đến việc quản lý tài khoản ngườidùng và xác thực, chẳng hạn như cho phép người dùng tạo và đăng nhập vàotài khoản của họ cũng như lưu trữ thông tin hồ sơ người dùng

o Dịch vụ sản phẩm: Dịch vụ này liên quan đến việc quản lý sản phẩm có sẵn

để bán trên trang web, chẳng hạn như thêm sản phẩm mới, cập nhật sản phẩm, xoá sản phẩm hay xem chi tiết sản phẩm

o Dịch vụ tìm kiếm: Dịch vụ này liên quan đến việc tìm kiếm các sản phẩm trên trang web để xem chi tiết, thêm giỏ hàng hoặc mua sắm Có thể tìm kiếm bằng text

o Dịch vụ giỏ hàng: Dịch vụ này có khả năng chịu trách nhiệm quản lý các chức năng giỏ hàng của trang web, chẳng hạn như cho phép người dùng

thêm các mặt hàng vào giỏ hàng của họ, cập nhật giỏ hàng khi các mặt hàng được thêm vào hoặc xoá và tính toán tổng chi phí của đơn hàng.

o Dịch vụ đặt hàng: Dịch vụ này liên quan đến quản lý quy trình đặt hàng và thực hiện đơn hàng, chẳng hạn như nhận và xử lý đơn hàng, theo dõi mức tồn kho và cập nhật cho khách hàng về trạng thái đơn hàng

o Dịch vụ thanh toán: Dịch vụ này sẽ xử lý quá trình thanh toán, chẳng hạn như chấp nhận thanh toán bằng tài khoản online (ví điện tử), xác minh tính hợp lệ của thông tin thanh toán và bắt đầu giao dịch với cổng thanh toán hoặc ngân hàng

o Dịch vụ vận chuyển: Dịch vụ này sẽ quản lý việc vận chuyển và giao sản phẩm cho khách hàng, chẳng hạn như theo dõi các gói hàng, phối hợp với hãng vận chuyển và tính toán chi phí vận chuyển

o Dịch vụ nhân viên: Dịch vụ này có thể liên quan đến việc quản lý tài khoản

và quyền của nhân viên, chẳng hạn như cho phép nhân viên truy cập vào một số phần nhất định của trang web và theo dõi chỉ số hiệu suất của nhân viên

❖ Biểu đồ phân rã

o Trong biểu đồ trên:

o Mỗi hình chữ nhật đại diện cho một dịch vụ trong hệ thống (ví dụ: User Service, Product Service, etc.).

o Mũi tên <> biểu thị tương tác giữa các dịch vụ Ví dụ, User Service cóthể tương tác với Cart Service để thêm sản phẩm vào giỏ hàng

o Các dịch vụ có thể giao tiếp với nhau theo nhiều cách, như gửi yêu cầu HTTP, sử dụng message queue, hoặc các cách khác tùy thuộc vào cấu trúc và yêu cầu của hệ thống

Kết luận

Trong tổng thể, kiến trúc của hệ thống ecomSys được phân rã thành các dịch

vụ độc lập, mỗi dịch vụ đảm nhận một phần công việc cụ thể trong quy trìnhhoạt động của hệ thống Từ dịch vụ người dùng, sản phẩm, tìm kiếm đến giỏhàng, đặt hàng, thanh toán, vận chuyển và nhân viên, mỗi phần đều được quản lý một cách rõ ràng và linh hoạt Sự phân rã này giúp tăng tính linh hoạt, dễ bảo trì và mở rộng của hệ thống, cũng như tạo điều kiện cho việc phát triển đồng thời và song song của các tính năng Đồng thời, việc áp dụngkiến trúc hướng dịch vụ cũng giúp tối ưu hóa hiệu suất và quản lý tài nguyênmột cách hiệu quả Đây là một cách tiếp cận hiệu quả để xây dựng và phát triển các hệ thống phần mềm phức tạp, đáp ứng được yêu cầu ngày càng cao của thị trường và người dùng

Chương 3: Thiết kế và xây dựng hệ ecomSys

3.1 Giới thiệu

Trong hệ thống ecomsys , có các chức năng chính sau đây:

● Khách hàng có thể đăng kí đăng nhập, quên mật khẩu, thay đổi mật khẩu,thay đổi thông tin cá nhân

● Khách hàng xem sản phẩm, tạo giỏ hàng, đặt hàng

● Admin quản lí khách hàng, đơn hàng, sản phẩm, thanh toán, xem báo cáo

❖ Mô tả các actor của hệ thống

▪ Primary Actor: Khách hàng – Customer

Những người thức hiện, tham gia vào hoạt động mua bán và tím kiếm sản phẩm trên hệ thống, được xem như là người dùng cuối cùng của

hệ thống

o Hoạt động chính:

▪ Thực hiện đăng kí tài khoản và đăng nhập trên hệ thống

▪ Xem sản phẩm trên hệ thống.

▪ Tìm kiếm các sản phẩm muốn mua

▪ Đặt hàng

▪ Thanh toán

▪ Theo dõi hoặc hủy đơn hàng

▪ Thực hiện đánh giá đơn hàng

▪ Primary Actor: Nhân viên hệ thống - Staff

Đây là những người thực hiện quản lý vàkiểm tra các đơn hàng trên

hệ thống cũng như các dịch vụ liên quan đến khách hàng

o Hoạt động chính:

▪ Đăng nhập bằng tài khoản nhân viên trên hệ thống

▪ Xác nhận các đơn đặt hàng

▪ Thêm, sửa, xóa thông tin sản phẩm trên hệ thống

▪ Xác nhận hủy đơn hàng khi gặp vấn đề

▪ Xem và tư vấn các đánh giá của khách hàng

▪ Secondary Actor: Thu ngân - Bank Đây là người thực hiện các yêucầu thanh toán cótrên hệ thống từ thanh toán online hoặc trả tiền mặt

Họ có nhiệm vụ thực hiện thanhtoán và xuất hóa đơn cho khách hàng

▪ Secondary Actor: Đơn vị vận chuyển Họ là những người nhận và vậnchuyển đơn hàngtới khách hàng Có thể thu hộ tiền mặt nếu có yêucầu

3.2 Mô tả yêu cầu các chức năng và phi chức năng của hệ thống bằng ngôn ngữ tự nhiên

▪ Yêu cầu chức năng

o Người dùng: đăng nhập,đăng ký

o Nhân viên : đăng nhập,thêm sản phẩm, xác nhận đặt hàng

o Khách hàng: tìm sản phẩm ,xem sản phẩm chi tiết, đặt sảnphẩm, trả tiền, thêm sản phẩm,

o Quản lý : thêm nhân viên , thống kê

▪ Yêu cầu phi chức năng

o Tính bảo trì: hệ thống nên có thời gian bảo trì ngắn

o Tính bảo mật: hệ thống bảo mật thông tin của khách hàng

o Hiệu suất: đảm bảo hiệu suất cao khi có lượng lớn truy nhậpvào hệ thống

o Độ tin cậy hệ thống phải có khả năng sao lưu dữ liệu để tránh bịmất mát dữ liệu

▪ Mô tả chức năng

⮚ Khách hàng đặt hàng trên thương mại điện tử : khách hàng đăngnhập theo tài khoản và mật khẩu của mình→ Giao diện của kháchhàng hiên ra → Khách hàng vào giỏ hàng của mình mua sản phẩmsẵn có trong giỏ (nếu có) , khách hàng tìm kiếm sản phẩm mà mìnhmuốn mua → Giao diện hiện ra sản phẩm mà khách hàng cần →Khách hàng chọn sản phẩm mình muốn mua, khách hàng có thểmua ngay (nếu muốn) , hoặc cho vào giỏ hàng rồi mua click nútmua (nếu sản phẩm còn trong kho) → Giao diện hiện ra danh sáchkhách hàng muốn mua ,kèm theo giá của từng loại, tổng tiền phảitrả và phương thức xác nhận → Khách hàng kiểm tra lại thông tintồi click nút xác nhận → Giao diện hiện đặt hàng thành công

⮚ Khách hàng hủy đơn đặt hàng : khách hàng đăng nhập theo tàikhoản và mật khẩu của mình → Giao diện của khách hàng hiện ra

→ Khách hàng vào mục đơn hàng của bạn → Giao diện hiện rathông tin của đơn hàng và trạng thái của đơn hàng , nếu đơn hàngchưa vận chuyển thì có thể click nút hủy đơn hàng , (nếu đơn hàng

đã vận chuyển thì nút hủy đơn hàng không xuất hiện)→ Giao diệnthông báo hủy đơn hàng thành công

⮚ Nhân viên thêm sản phẩm mới :Nhân viên đăng nhập vào hệ thốngvới tài khoản và mật khẩu của mình→ Giao diện của nhân viênhiện ra các chức năng thêm sản phẩm, xác nhận đặt hàng ,phản hồinhận xét của khách hàng → Nhân viên chọn thêm sản phẩm →Giao diện ra form điền thêm sản phẩm (mã sp, tên sp, giá,hình ảnhminh họa) (sản phẩm không có mã trùng với sản phẩm có trên hệthống) → Nhân viên điền thông tin đầy đủ và đến khi hết sản phẩmcần thêm và click vào nút xác nhận → Giao diện hiện thông báothêm sản phẩm thành công

⮚ Nhân viên xác nhận đơn hàng : Nhân viên đăng nhập vào hệ thốngvới tài khoản và mật khẩu của mình → Giao diện của nhân viênhiện ra các chức năng thêm sản phẩm, xác nhận đặt hàng ,phản hồinhận xét của khách hàng→ Nhân viên chọn xác nhận đặt hàng →Giao diện hiện ra danh sách các đơn hàng đã đặt của khách hàng

→ Nhân viên click nút xác nhận cho từng đơn hàng và cập nhật dữliệu để khách hàng dễ dàng theodõi vận chuyển đơn hàng củamình

⮚ Quản lý thêm nhân viên : Quản lý đăng nhập vào hệ thống với tàikhoản và mật khẩu của mình→ Giao diện của quản lý hiện ra :thêm nhân viên , xem báo cáo → Quản lý chọn thêm nhân viên→Giao diện hiện ra form điền thông tin (mã nv, họ tên, năm sinh,dân tộc, địa chỉ, sdt) → Quản lý điền thông tin theo yêu cầu vàclick xác nhận → Giao diện thông báo thêm nhân viên thành công

và hiện lên tài khoản và mật khẩu của nhân viên để đăng nhập vào

hệ thống

⮚ Quản lý thống kê doanh số bán hàng :Quản lý đăng nhập vào hệthống với tài khoản và mật khẩu của mình→ Giao diện của quản lýhiện ra : thêm nhân viên , xem báo cáo → Quản lý xem báo cáo→Giao diện hiện lên ô text nhập ngày bắt đầu và kết thúc → Quản lýnhập ngày bắt đầu và kết thúc và click tìm kiếm → Giao diện hiện

ra doanh số bán hàng tổng và của từng loại mặt hàng , click in báocáo (nếu muốn)→ Nhân viên click vào một hàng để xem chi tiếttừng loại sản phẩm của mặt hàng đó

3.3 Các biểu đồ đặc tả hệ ecomSys

3.3.1 Biểu đồ use case

❖ UseCase tổng quát

❖ UseCase chi tiết

- Sơ đồ usecase tổng quan:

- Biểu đồ usecase chi tiết customerLogin:

- Biểu đồ usecase chi tiết search

- Biểu đồ usecase chi tiết payment

- Biểu đồ usecase thêm vào giỏ hàng

- Biểu đồ usecase chi tiết order

- Biểu đồ usecase chi tiết manage Book

- Biểu đồ usecase chi tiết manage Clothes

- Biểu đồ usecase chi tiết manage Mobile

- Biểu đồ usecase chi tiết manage order

- Biểu đồ usecase chi tiết manage Customer

- Biểu đồ usecase chi tiết manage Staff

3.3.2 Biểu đồ hoạt động/swimlane

3.3.3 Biểu đồ lớp phân tích cho từng service

3.3.4 Mô hình Data- kiểu/công nghệ dữ liệu

3.3.5 Biểu đồ lớp thiết kế cho từng service

from django.contrib.auth.models import AbstractUser

from django.db import models

class User(AbstractUser):

phone_number= models.CharField(max_length=20)

email= models.EmailField(max_length=255, unique=True) username = models.CharField(max_length=100, unique=False,

null=True, default=None)

from rest_framework import status

from rest_framework.response import Response

from rest_framework.views import APIView

from authentication import SafeJWTAuthentication

from utils import generate_access_token, generate_refresh_token

from serializers import ChangePasswordSerializer,

UpdateProfileSerializer, UserInfoSerializer, UserLoginSerializer, UserSerializer

from rest_framework.permissions import IsAuthenticated

from rest_framework.permissions import AllowAny

class RegisterView(APIView):

permission_classes= [AllowAny]

defpost(self, request):

serializer= UserSerializer(data=request.data)

if serializer.is_valid():

user=serializer.save()

access_token=generate_access_token(user) refresh_token =generate_refresh_token(user)

user_serializer = UserInfoSerializer(user)

return Response({

'user': user_serializer.data,

'refresh': refresh_token,

'access': access_token,

}, status=status.HTTP_201_CREATED)

return Response(serializer.errors,

status=status.HTTP_400_BAD_REQUEST)

class LoginView(APIView):

permission_classes= [AllowAny]

defpost(self, request):

serializer= UserLoginSerializer(data=request.data)

if serializer.is_valid():

user=serializer.validated_data

access_token=generate_access_token(user) refresh_token =generate_refresh_token(user)

user_serializer = UserInfoSerializer(user)

}, status=status.HTTP_200_OK)

return Response(serializer.errors,

status=status.HTTP_400_BAD_REQUEST)

class UserInfoView(APIView):

permission_classes= [IsAuthenticated]

authentication_classes= [SafeJWTAuthentication]

defget(self, request):

user=request.user

serializer= UserInfoSerializer(user)

return Response({"user":serializer.data, "message":"Token is valid"}, status=status.HTTP_200_OK)

o Urls

from django.urls import path

from views import *

from django.db import models

# Create your models here

product_id= models.IntegerField(unique=False, null=False) product_type= models.CharField(max_length=50)

class Meta:

db_table='cart_items'

ordering= ['date_added']

defaugment_quantity(self, quantity):

self.quantity= self.quantity+ int(quantity)

self.save()

o Views

from django.shortcuts import render

from rest_framework.views import APIView

from rest_framework.response import Response

from rest_framework import status

from models import *

from serializers import *

return Response({"message":"Bạn phải đăng nhập"})

user=response.json().get("user")

user_id=user.get("id")

cart = Cart.objects.filter(user_id=user_id).first()

cart_item_list = CartItem.objects.filter(cart=cart.id)

serializer= CartItemSerializer(cart_item_list, many=True) totalPrice =0

for cart_item in cart_item_list:

if cart_item.product_type=='book':