Luận văn tốt nghiệp Đại học ngành kỹ thuật phần mềm Đề tài phát triển Ứng dụng quản lý bán hàng trực tuyến dùng microservices

Nhờ đó mà kiểu kiến trúc này giúp cho hệ thống được phân chia ra thành những thành phần đơn giản, dễ bảo trì, dễ mở rộng hơn, tăng khả năng tích hợp điểm mạnh của nhiều công nghệ.. Với n

GIỚI THIỆU

Mục đích

Trước đây, monolithic application được thiết kế để xử lý nhiều tác vụ liên quan với nhau, thường là những ứng dụng phức tạp và có nhiều tính năng, thành phần có mối liên hệ chặt chẽ với nhau

Lấy ví dụ với một ứng dụng SaaS thương mại điện tử theo kiến trúc monolith Hệ thống này có thể chứa một web server, một bộ cân bằng tải, một catalog dịch vụ, hệ thống đặt hàng, chức năng thanh toán… Tuy nhiên khi đó các công cụ monolithic thường sẽ có khối lượng code rất lớn Một thay đổi nhỏ trong bất kỳ chức năng nào cũng có thể cần phải compile và test lại toàn bộ nền tảng

Thay vì trước đây chỉ có những hệ thống nhỏ, với những trang tin tức, thông tin, với lượng truy cập và tương tác không quá lớn, thì bây giờ là những dịch vụ mạng xã hội, fintech, phát triển đòi hỏi sự phát triển càng ngày càng nhanh để đáp ứng nhu cầu ngày càng tăng đến từ người dùng Do đó, sự bất lợi và những nhược điểm của Monolith bắt đầu xuất hiện

Thêm vào đó, dịch vụ (service) ra đời và ngày càng phát triển đã giúp các nhà xây dựng và phát triển phần mềm tạo ra các hệ thống có khả năng thích ứng cao với nhiều môi trường khác nhau, tăng khả năng tái sử dụng Các hệ thống được phát triển nhanh chóng và giảm được sự phức tạp, hạ giá thành khi xây dựng và triển khai

Tuy nhiên việc không quan tâm đến kích thước của các dịch vụ trong hệ thống đang đặt ra bài toán khó cho các nhà xây dựng và phát triển phần mềm là làm sao giảm chi phí khi xây dựng hệ thống với các dịch vụ, làm sao tránh ảnh hưởng đến cả hệ thống khi muốn thay đổi một số chức năng của hệ thống, …

Phạm vi của dịch vụ càng lớn hệ thống càng trở lên phức tạp, khó phát triển, kiểm thử và bảo trì Chính những điều này đang làm cho việc xây dựng và phát triển hệ thống phần mềm dựa trên dịch vụ đang vượt khỏi khả năng kiểm soát của các kiểu kiến trúc phần mềm hiện có và cần phải có một kiểu kiến trúc mới để giải quyết vấn đề này

Kiến trúc Microservices được coi là lời giải ưu việc cho bài toán xây dựng và phát triển hệ thống dựa trên dịch vụ như hiện nay Từ khi được nghiên cứu và ứng dụng Microservices là một xu hướng thiết kế cho nhiều hệ thống Nó đã và đang được nghiên cứu và ứng dụng rộng rãi gần như là đầu tiên bởi các công ty lớn như: Netflix, Ebay, Paypal, Twitter, Amazon, … Đặc biệt là hiện nay khi các sản phẩm phần mềm đóng gói đang dần được thay thế bởi các phần mềm dịch vụ thì kiến trúc Microservices sẽ là đề tài ngày càng được quan tâm.

Lịch sử giải quyết vấn đề

Đầu tiên đó chính là sự phát triển của mạng Internet, đã bắt đầu nhen nhóm về microservice từ những năm 2004, nhưng chưa quá nổi bật Nhưng đến những năm gần đây với sự bùng nổ của công nghệ với Smartphone, Wifi…dẫn đến việc con người ngày càng tiếp cận với các dịch vụ công nghệ nhiều hơn, nhiều business công nghệ xuất hiện nhằm đáp ứng nhu cầu hiện nay

Trong khoảng thời gian trở lại đây thì có rất nhiều công nghệ mới được ra mắt và đã ảnh hưởng rất nhiều đến việc phát triển phần mềm ví dụ như Cloud Computing, Containerization (Docker, Kubernetes), DevOps Cùng với đó là sự xuất hiện của rất nhiều ngôn ngữ lập trình mới, ví dụ như Golang, Rust, Swift cùng với sự tiện lợi, dễ sử dụng giống như các ngôn ngữ như là JavaScript, Python Một vài sự thay đổi về Software Development model, Waterfall software development model iần như bị loại bỏ và được thay thế bằng phương pháp phát triển phần mềm nhanh, lặp, tăng dần: Phát triển phần mềm Agile Phần cứng máy tính ngày càng rẻ hơn, nhanh hơn và sự phát triển CPU Multi-Core, GPU Những sự thay đổi về CSDL mới như là NoQuery, New Query nổi lên và trở thành xu hướng Để xử lý những vấn đề trên, cùng với những lợi thế đến từ Cloud Computing, Containerization, DevOps, modern Programming languages và đến từ nhu cầu phát triển phần mềm hiện đại (fast development, horizontal scaling), một Software Architecture Style được phát triển từ năm 2012: Microservice Architecture

Hiện nay, đã có nhiều công ty lớn như: Neflix, Amazon, Ebay sử dụng kiến trúc Microservices để giải quyết bài toán xây dựng và phát triển hệ thống dự trên dịch vụ cũng như để tận dụng các nguồn tài nguyên phần cứng, các dịch vụ điện toán đám mây

• Netflix (https://www.netflix.com)

Netflix là một nền tảng cung cấp dịch vụ phát trực tuyến của Mỹ Cho phép người dùng đã đăng ký thành viên có thể xem trực tiếp các chương trình truyền hình và phim ảnh, đồng thời tải chúng về các thiết bị của mình để xem mà không bị gián đoạn bởi quảng cáo

Hiện nay, Netflix đã có mặt trên 190 quốc gia và vùng lãnh thổ, trong đó có Việt Nam Phụ đề tiếng Việt cũng được hỗ trợ để bạn thưởng thức kho tàng chương trình và phim chất lượng cao liên tục được cập nhật mỗi tháng

Hình 0.1: Giao diện của Netflix

• Amazon (https://www.amazon.com)

Amazon là một trang web thương mại điện tử, hay dễ hiểu hơn amazon là trang web bán hàng online trên mạng internet toàn cầu, thuộc quyền sở hữu của công ty Amazon.com Inc, thành lập năm 1994 bởi Jeff Bezos, có trụ sở chính tại

Hình 0.2: Giao diện trang chủ của Amazon

• Ebay (https://www.ebay.com)

Tập đoàn eBay là một công ty của Hoa Kỳ, quản lý trang web eBay.com, một website đấu giá trực tuyến, nơi mà mọi người khắp nơi trên thế giới có thể mua hoặc bán hàng hóa và dịch vụ Ngoài trụ sở tại Mỹ, eBay còn có chi nhánh tại một số quốc gia khác Tập đoàn eBay cũng sở hữu thương hiệu nổi tiếng khác là Paypal

Hình 0.3: Giao diện trang chủ của Ebay

Mục tiêu đề tài

Từ những ý nghĩa thực tiễn trên, chúng tôi đã thực hiện đề tài luận văn “Phát triển ứng dụng quản lý bán hàng trực tuyến dùng Microservices” để nghiên cứu và áp dụng kiến trúc Microservices vào xây dựng ứng dụng để có tích hợp điểm mạnh của nhiều công nghệ và dễ dàng tiếp tục phát triển trong tương lai Bên cạnh đó, chúng tôi cũng tìm hiểu được thêm một số framework và kĩ thuật để áp dụng xây dựng hệ thống tích hợp Microservices như Net, Docker, Identity Server, Elasticsearch, Kibana, gRPC, API Gateway, Message Broker Từ đó đưa ra các phân tích, đánh giá về kiến trúc Microservices cũng như cách vận hành một hệ thống theo kiến trúc Microservices một cách hiệu quả

Trang web của chúng tôi có những chức năng cơ bản sau:

Đối tượng và phạm vi nghiên cứu đề tài

Luận văn này sẽ tập trung trình bày kết quả nghiên cứu của chúng tôi về các nội dung sau: Mô hình Microservices và các công nghệ như: NET Core, RabbitMQ, Docker, Elasticsearch, Kibana, gRPC Mỗi phần chúng tôi sẽ giới thiệu trình bày những nội dung chính, những điểm mạnh hay lợi ích mà nó mang lại cho các nhà phát triển phần mềm Sau khi tìm hiểu chúng tôi sẽ vận dụng kết quả tìm hiểu được vào việc phát triển hệ thống thương mại điện tử đon giản sử dụng kiến trúc Microservices để minh họa cho phần lý thuyết đã trình bày.

Nội dung nghiên cứu

- Tìm hiểu và nghiên cứu kiến trúc Microservices và các công nghệ có liên quan ở các nguồn như các blog, các khóa học, các bài báo, …

- Xác định ưu, nhược điểm cũng như vai trò của từng công nghệ, kĩ thuật trong hệ thống

- Áp dụng kiến trúc Microservices và những công nghệ, kỹ thuật liên quan để xây dựng ứng dụng thương mại điện tử đơn giản để minh họa

- Rút ra cách thiết kế, xây dựng và vận hành hiệu quả hệ thống Microservices.

Những đóng góp chính của đề tài

- Kết quả nghiên cứu có thể dùng để làm tài liệu tham khảo

- Phần nghiên cứu lý thuyết sẽ cung cấp một cách nhìn tổng quát về quá trình phát triển phần mềm theo kiến trúc Microservices, ưu nhược điểm và các điểm liên quan đến kiến trúc Microservices

- Phát triển thành công một hệ thống sử dụng kiến trúc Microservices

Bố cục luận văn

Tài liệu được chia làm 3 phần chính:

- Phần I Mở đầu: Gồm những nội dung chính: Mục đích, tóm tắt lịch sử giải quyết vấn đề, mục tiêu của đề tài, đối tượng, phạm vi và nội dung nghiên cứu, những đóng góp chính của đề tài, bố cục quyển luận văn

- Phần II Nội dung: bao gồm 5 nội dung chính + Chương 1: Đặt tả yêu cầu

+ Chương 2: Trình bày các cơ sở lý thiết cũng như các công nghệ, kỹ thuật có liên quan được áp dụng vào hệ thống

+ Chương 3: Trình bày, đưa ra giải pháp thiết kế, xây dựng hệ thống Các bước thiết kế giải pháp dựa trên kiến trúc Microservices Chương này gồm những nội dung như: thiết kế kiến trúc cho hệ thống, thiết kế cơ sở dữ liệu cho mỗi service, thiết kế chức năng cho hệ thống, triển khai hệ thống có khả năng phục hồi

+ Chương 4: Kiểm thử và đánh giá

+ Chương 5: Nêu bài học rút được và đánh giá lại những gì hệ thống đã đạt được

- Phần III Kết luận: Trình bày kết quả đạt được cũng như hướng phát triển chung của đề tài

NỘI DUNG

ĐẶC TẢ YÊU CẦU

Chương này sẽ mô tả các yêu cầu cơ bản của hệ thống quản lý bán hàng trực tuyến: mô tả chi tiết bài toán, đặt vấn đề, các yêu cầu giao tiếp bên ngoài, các yêu cầu phi chức năng, chức năng chính của hệ thống và sơ đồ usecase

1.1 Yêu cầu cho ứng dụng

1.1.1 Mô tả chi tiết bài toán Đề tài “Phát triển ứng dụng quản lý bán hàng trực tuyến dùng Microservices” đáp ứng những yêu cầu sau:

• Admin: có quyền cao nhất trong hệ thống, quản lý toàn bộ thông tin của hệ thống

• Nhân viên: o Quản lý sản phẩm o Quản lý đơn hàng o Quản lý xuất nhập kho

• Khách hàng: người đã có tài khoản trên hệ thống o Đăng nhập o Quản lý giỏ hàng o Quản lý đơn hàng o Đặt hàng

• Khách vãng lai: o Xem sản phẩm

1.1.2 Tiếp cận giải quyết vấn đề

Hoạt động bán hàng theo kiểu truyền thống gặp nhiều hạn chế như:

- Tìm kiếm, tra cứu thông tin về sản phẩm, đơn hàng, khách hàng mất rất nhiều thời gian và công sức

- Lưu trữ các loại thông tin phải sử dụng nhiều loại giấy tờ, sổ sách Dẫn đến việc thống kê, tổng hợp, báo cáo tốn rất nhiều thời gian và công sức, thậm chí sai sót là điều khó có thể tránh khỏi

- Khách hàng mất thời gian đến tận nơi bán mà không tìm được sản phẩm mình mong muốn

- Khó có thể đảm bảo chất lượng phục vụ với số lượng lớn khách hàng cùng một thời điểm

Ngày nay, với tốc độ phát triển của nền kinh tế thì các loại hình kinh doanh ngày càng phát triển Ngoài mô hình kinh doanh truyền thống là bán hàng tại chính cửa hàng, để tăng doanh số thì các doanh nghiệp còn tham gia thêm hình thức kinh doanh online hay còn gọi là bán hàng qua mạng Với một website bán hàng, cơ sở kinh doanh sẽ có thể đưa các thông tin của các mặt hàng của mình lên trang web để có thể tiếp cận đến nhiều khách hàng hơn

Website bán sách được xây dựng để đáp ứng nhu cầu quản lý hoạt động của nhà sách cho các quản trị viên và nhu cầu mua trực tuyến sách cho khách hàng

Khách hàng sau khi truy cập vào trang web có thể xem sách ở nhiều thể loại, xem chi tiết của cuốn sách với các thông tin như giá cả, nội dung… Sau khi thêm sách vào giỏ, khách hàng có thể vào giỏ hàng trang để xem lại những cuốn sách họ đã chọn Sau khi hoàn thành lựa chọn, khách hàng có thể xác nhận thông tin vận chuyển, phí vận chuyển, tổng số tiền đơn đặt hàng và tiến hành mua hàng Đơn hàng này sẽ chuyển sang trạng thái chờ xử lý và chờ để được phê duyệt từ quản trị viên của cửa hàng

Quản trị viên nhận đơn hàng đã có trên hệ thống, sau đó xem xét thông tin đơn hàng để đưa ra quyết định chấp nhận hay từ chối đơn hàng Nếu đơn đặt hàng là được chấp nhận, nhân viên và quản trị viên sẽ chuẩn bị đơn đặt hàng, tạo hóa đơn, gửi hóa đơn đến khách hàng qua email và gửi đơn đặt hàng đến địa chỉ giao hàng được cung cấp bởi khách hàng

1.1.2.1.2 Các chức năng của sản phẩm

- Quản lý sản phẩm: nhân viên có thể thêm sửa xóa các sản phẩm

- Quản lý đơn hàng: nhân viên có thể xem các đơn hàng, cũng như xác nhận đơn hàng

- Quản lý xuất nhập kho: nhân viên có thế xem lịch sử xuất nhập kho

• Đối với khách hàng (người dùng đã có tài khoản):

- Quản lý giỏ hàng: chức năng cho phép người dùng có thể thêm sản phẩm vào giỏ hàng, thêm sửa xóa sản phẩm trong giỏ hàng, để có thể đặt hàng

- Quản lý đơn hàng: chức năng cho phép người dùng có thể xem lại lịch sử đơn hàng

- Đặt hàng: chức năng cho phép người dùng có thể đặt một đơn hàng

• Đối với khách vãng lai (người dùng chưa có tài khoản):

- Xem sản phẩm: chức năng cho phép người dùng có thể xem một sản phẩm

1.1.2.1.3 Đặc điểm của người dùng

Bảng 1.1: Đặc điểm người dùng

Nhóm người sử dụng Đặc trưng Các chức năng Vai trò Mức độ quan trọng

Admin Là người chịu trách nghiệm quản lý toàn bộ hệ thống

Quản lý tất cả người dùng

Nhân viên Là người chịu trách nhiệm quản lý các đơn hàng, sản phẩm, danh mục

- Quản lý xuất nhập kho

Khách hàng Là khách hàng của hệ thống (đã có tài khoản)

Khách vãng lai Là khách hàng của hệ thống (chưa có tài khoản)

• Website chạy được trên đa nền tảng (Windows, Mac và Linux)

• Ngôn ngữ: C#, HTML, CSS, JS

• Cơ sở dữ liệu: SQL Server, MongoDB, Redis, MySQL,

1.1.2.1.5 Các ràng buộc thực thi và thiết kế

• Thực thi: o Cần phải có Internet với tốc độ ổn định và có thể hoạt động liên tục trong suốt quá trình làm việc o Máy phải đặt trong môi trường, nhiệt độ tốt để hoạt động

• Thiết kế: o Sử dụng mô hình kiến trúc: Microservices, Client – Server o Ngôn ngữ lập trình: C#, Javascript o Các Framework: ASP.NET Core o Các thư viện: o Các công cụ hỗ trợ: Docker o Hệ quản trị cơ sở dữ liệu: SQL Server, MongoDB, Redis, MySQL, o Giao diện hài hòa, dễ tương tác với người dùng

1.1.2.2 Các yêu cầu giao tiếp bên ngoài

• Màu sắc hài hòa, phù hợp với một website bán sách và với các đối tượng sử dụng

• Phong cách giao diện phẳng đặc trưng của Windows 10

• Giao diện thân thiện, đơn giản

• Mỗi nhóm người dùng có giao diện với chức năng riêng biệt

• Hệ thống chạy ổn định, giao diện phù hợp với các thiết bị truy cập (máy tính, máy tính bảng, điện thoại)

Bảng 1.2: Yêu cầu giao tiếp phần cứng

Cấu hình tối thiểu Cấu hình đề nghị

Bộ xử lý Celeon 1.8GHz Pentium III 1.8GHz

Dung lượng ổ cứng 20GB 40GB Độ phân giải 800 x 600 1024 x 720

• Trình duyệt Web: Internet Explorer 10 (hoặc cao hơn), Mozilla Firefox 8.0 (hoặc cao hơn), Google Chrome và các trình duyệt web khác có hỗ trợ

• Hệ điều hành: Windows 7, Windows 8, Windows 10 (hoặc cao hơn)

1.1.2.2.4 Giao tiếp truyền thông tin

• Chuẩn truyền thông tin: Hệ thống hoạt động theo mô hình Client – Server Client gửi yêu cầu cho Server, Server nhận sau đó xử lý rồi phản hồi lại Client

• Trình duyệt web: Google Chrome, Microsoft Edge, FireFox (hỗ trợ tốt nhất cho Google Chrome)

1.1.2.3 Các yêu cầu chức năng của hệ thống

Hình 1.1: Sơ đồ trường hợp sử dụng của website

Hình 1.2: Sơ đồ trường hợp sử dụng xem sản phẩm

Hình 1.3: Sơ đồ trường hợp sử dụng đặt hàng

Tên yêu cầu Đăng ký

Mức độ ưu tiên Cao

Mô tả Người dùng muốn đăng ký tài khoản để sử dụng trong hệ thống Đối tượng sử dụng

Người dùng khách Tiền điều kiện Không

Các thao tác xử lý 1 Người dùng truy cập vào trang web

2 Người dùng nhấn nút “Đăng ký”

3 Người dùng nhập đầy đủ thông tin đăng ký và nhấn nút

4 Hệ thống kiểm tra và xử lý đăng ký

5 Thông báo thành công hay thất bại

6 Kết thúc sự kiện Kết quả Người dùng đăng ký tài khoản thành công

Tên yêu cầu Đăng nhập

Mô tả Người dùng muốn đăng nhập tài khoản để sử dụng hệ thống Đối tượng sử dụng

Admin, nhân viên, người dùng

Tiền điều kiện Tài khoản người dùng đã được tạo trong hệ thống

Các thao tác xử lý 1 Người dùng truy cập vào trang web

2 Người dùng nhấn nút “Đăng nhập”

3 Người dùng nhập đầy đủ thông tin đăng nhập và nhấn nút “Đăng nhập”

4 Hệ thống kiểm tra và xử lý đăng nhập

5 Thông báo thành công hay thất bại

Kết quả Người dùng đăng nhập thành công và hệ thống trả về token dùng để xác thực người dùng

Bảng 1.5: Usecase thêm mới sản phẩm

Tên yêu cầu Thêm sản phẩm mới

Mô tả Nhân viên muốn thêm một sản phẩm mới Đối tượng sử dụng

Tiền điều kiện Nhân viên phải đăng nhập vào hệ thống

Các thao tác xử lý 1 Nhân viên chọn chức năng “Quản lý sản phẩm”

2 Hệ thống hiển thị giao diện quản lý sản phẩm

3 Nhân viên chọn nút “Thêm mới”

4 Hệ thống hiển thị giao diện thêm mới sản phẩm

5 Nhân viên nhập đầy đủ thông tin sản phẩm

6 Nhân viên nhấn nút “Thêm”

7 Hệ thống thêm sản phẩm mới vào danh sách các sản phẩm

8 Kết thúc sự kiện Kết quả Nhân viên thêm sản phẩm mới vào hệ thống thành công

Bảng 1.6: Usecase cập nhật sản phẩm

Tên yêu cầu Cập nhật sản phẩm

Mô tả Nhân viên muốn cập nhật một sản phẩm Đối tượng sử dụng

3 Nhân viên chọn vào biểu tượng hình bút chì trên dòng sản phẩm mà nhân viên muốn cập nhật

4 Hệ thống hiển thị giao diện cập nhật sản phẩm

5 Nhân viên nhập đầy đủ thông tin cập nhật sản phẩm

6 Nhân viên nhấn nút “Cập nhật”

7 Hệ thống cập nhật sản phẩm

8 Kết thúc sự kiện Kết quả Nhân viên cập nhật sản phẩm vào hệ thống thành công

Bảng 1.7: Usecase xóa sản phẩm

Tên yêu cầu Xóa sản phẩm

Mô tả Nhân viên muốn xóa một sản phẩm Đối tượng sử dụng

3 Nhân viên chọn vào biểu tượng hình thùng rác trên dòng sản phẩm mà nhân viên muốn xóa

4 Hệ thống hiển thị giao diện xác nhận xóa sản phẩm

5 Nhân viên nhấn nút “Có”

6 Hệ thống xóa sản phẩm danh sách các sản phẩm

7 Kết thúc sự kiện Kết quả Nhân viên xóa sản phẩm khỏi hệ thống thành công

Bảng 1.8: Usecase thêm danh mục mới

Tên yêu cầu Thêm danh mục mới

Mô tả Nhân viên muốn thêm một danh mục mới Đối tượng sử dụng

Các thao tác xử lý 1 Nhân viên chọn chức năng “Quản lý danh mục”

2 Hệ thống hiển thị giao diện quản lý danh mục

3 Nhân viên chọn nút “Thêm mới”

4 Hệ thống hiển thị giao diện thêm mới danh mục

5 Nhân viên nhập đầy đủ thông tin danh mục

6 Nhân viên nhấn nút “Thêm”

7 Hệ thống thêm danh mục mới vào danh sách các danh mục

8 Kết thúc sự kiện Kết quả Nhân viên thêm danh mục mới vào hệ thống thành công

Bảng 1.9: Usecase cập nhật danh mục

Tên yêu cầu Cập nhật danh mục

Mô tả Nhân viên muốn cập nhật một danh mục Đối tượng sử dụng

3 Nhân viên chọn vào biểu tượng hình bút chì trên dòng danh mục mà nhân viên muốn cập nhật

4 Hệ thống hiển thị giao diện cập nhật danh mục

5 Nhân viên nhập đầy đủ thông tin cập nhật danh mục

6 Nhân viên nhấn nút “Cập nhật”

7 Hệ thống cập nhật danh mục

8 Kết thúc sự kiện Kết quả Nhân viên cập nhật danh mục vào hệ thống thành công

Bảng 1.10: Usecase xóa danh mục

Tên yêu cầu Xóa danh mục

Mô tả Nhân viên muốn xóa một danh mục Đối tượng sử dụng

3 Nhân viên chọn vào biểu tượng hình thùng rác trên dòng danh mục mà nhân viên muốn xóa

4 Hệ thống hiển thị giao diện xác nhận xóa danh mục

5 Nhân viên nhấn nút “Có”

6 Hệ thống xóa danh mục danh sách các danh mục

7 Kết thúc sự kiện Kết quả Nhân viên xóa danh mục khỏi hệ thống thành công

1.1.2.3.9 Thêm sản phẩm vào giỏ hàng

Bảng 1.11: Usecase thêm sản phẩm vào giỏ hàng

Tên yêu cầu Thêm sản phẩm vào giỏ hàng

Mô tả Cho phép khách hàng thêm vào giỏ hàng Đối tượng sử dụng

Tiền điều kiện Khách hàng phải truy cập vào trang web

Các thao tác xử lý 1 Khách hàng chọn một sản phẩm bất kỳ

2 Hệ thống hiển thị giao diện thông tin chi tiết sản phẩm

3 Khách hàng chọn vào nút “Thêm vào giỏ hàng”

4 Hệ thống thêm sản phẩm vào giỏ hàng của khách hàng

5 Kết thúc sự kiện Kết quả Khách hàng thêm sản phẩm vào giỏ hàng thành công

1.1.2.3.10 Cập nhật số lượng sản phẩm trong giỏ hàng

Bảng 1.12: Usecase cập nhật số lượng sản phẩm trong giỏ hàng

Tên yêu cầu Cập nhật số lượng

Mô tả Cho phép khách hàng cập nhật số lượng sản phẩm trong giỏ hàng Đối tượng sử dụng

Các thao tác xử lý 1 Khách hàng chọn biểu tượng giỏ hàng

2 Hệ thống hiển thị giao diện quản lý giỏ hàng

3 Khách hàng cập nhật số lượng

4 Hệ thống cập nhật số lượng sản phẩm trong giỏ hàng của khách hàng

5 Kết thúc sự kiện Kết quả Khách hàng cập nhật số lượng sản phẩm trong giỏ hàng thành công

1.1.2.3.11 Xóa sản phẩm khỏi giỏ hàng

Bảng 1.13: Usecase xóa sản phẩm khỏi giỏ hàng

Tên yêu cầu Xóa sản phẩm khỏi giỏ hàng

Mô tả Cho phép khách hàng xóa sản phẩm khỏi giỏ hàng Đối tượng sử dụng

3 Khách hàng nhấn vào nút “X” của dòng sản phẩm mà khách hàng muốn xóa

4 Hệ thống cập nhật xóa sản phẩm khỏi giỏ hàng của khách hàng

5 Kết thúc sự kiện Kết quả Khách hàng xóa sản phẩm khỏi giỏ hàng thành công

Tên yêu cầu Đặt hàng

Mô tả Cho phép khách hàng đặt hàng Đối tượng sử dụng

Tiền điều kiện Khách hàng phải đăng nhập vào trang web

3 Khách hàng nhấn vào nút “Check out”

4 Hệ thống hiển thị giao diện đặt hàng

5 Khách hàng nhập vào thông tin giao hàng

6 Khách hàng chọn nút “Đặt hàng”

7 Hệ thống hiện thị giao diện đặt hàng thành công

8 Kết thúc sự kiện Kết quả Khách hàng đặt hàng thành công

Bảng 1.15: Usecase xác nhận hàng

Tên yêu cầu Xác nhận đơn hàng

Mô tả Cho phép nhân viên xác nhận đơn hàng Đối tượng sử dụng

Tiền điều kiện Nhân viên phải đăng nhập vào trang web

Các thao tác xử lý 1 Nhân viên chọn mục đơn hàng

2 Hệ thống hiển thị giao diện danh sách đơn hàng

3 Nhân viên nhấn vào nút “Chi tiết” của một đơn hàng

4 Hệ thống hiển thị giao diện chi tiết đơn hàng

5 Nhân viên nhấn vào nút “Chấp nhận”

6 Kết thúc sự kiện Kết quả Đơn hàng chuyển sang trạng thái đã được xác nhận

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

- Phần mềm hoạt động tốt trên các hệ điều hành được đề ra

- Tốc độ truy cập trang web phải nhanh và ổn định (ngắn hơn 5s)

- Hệ thống vẫn có thể hoạt động nếu 1 trong các Service gặp vấn đề 1.1.2.4.2 Yêu cầu an toàn

- Phục hồi dữ liệu ngay lập tức từ các bản sao lưu nếu có sự cố xảy ra

- Hệ thống không chứa virus, malware, tập tin rác

- Thông điệp được gửi đến hệ thống phải được xác thực và phân quyền theo từng nhóm người dùng

- Mật khẩu người dùng lưu trong cơ sở dữ liệu phải được mã hóa

1.1.2.4.4 Các đặc điểm chất lượng phần mềm

- Độ chính xác và tin cậy cao

- Dễ dàng bảo trì và sửa chửa

- Có các thông báo xác nhận khi người dùng thực hiện các thao tác cập nhật hoặc xóa dữ liệu

- Tài liệu của dự án được quản lý có hệ thống

1.2 Yêu cầu phát triển và yêu cầu nghiên cứu

- Phần mềm cần được phát triển bằng mô hình Microservics để tăng tính mô đun hóa, tái sử dụng và dễ mở rộng

- Phần mềm cần được triển khai lên web

- Khi nào nên áp dụng kiến trúc Microservices?

- Xác định phạm vi của mỗi Service như thế nào?

- Thiết kế cơ sở dữ liệu cho mỗi Service như thế nào?

- Làm thế nào để liên lạc giữa các Service một cách hiệu quả?

- Các phương pháp để làm cho hệ thống microservices có khả năng phục hồi?

CƠ SỞ LÝ THUYẾT

Chương 2 sẽ trình bày các khái niệm nền tảng của kiến trúc Microservices: định nghĩa kiến trúc Microservices và các mẫu thiết kế của kiến trúc Microservices, cũng như là các kiến thức, công nghệ có liên quan sẽ được dùng trong dự án này

Microservices là kiến trúc phần mềm mà toàn bộ hệ thống được chia thành một bộ các microservice, mỗi microservice 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ệu nà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ủa API gateway rất quan trọng trong mô hình microservice Nó là điểm đến và đi của mọi yêu cầu hay phản hồi

2.1.2 Các đặc trưng của microservices

- Tính độc lập: Các microservice hoạt động tách biệt nhau trong hệ thống, do vậy việc xây dựng một microservice cũng độc lập với việc xây dựng các microservice khác Thông thường, để tiện cho việc phát triển và duy trì các microservice, người phát triển nên viết các xây dựng mã khác nhau cho mỗi microservice Do tính tách biệt này mà mỗi microservice đều dễ dàng thay thế và mở rộng Hơn thế nữa, nó còn giúp việc phát triển các microservice linh động hơn, các microservice có thể được phát triển bởi các team khác nhau, dùng các ngôn ngữ khác nhau và tiến độ phát triển dự án cũng nhanh hơn do không có sự phụ thuộc giữa các team, mỗi team có thể chủ động quản lý phần việc riêng của mình

- Tính chuyên biệt: Mỗi microservice là một dịch vụ chuyên biệt, có thể hoạt động độc lập, thông thường mỗi microservice đại diện cho một tính năng mà các công ty/ doanh nghiệp muốn cung cấp tới người dùng, do vậy người thiết kế hệ thống microservice cần hiểu rõ về hoạt động kinh doanh của công ty Các đầu vào đầu ra và chức năng của mỗi microservice cần được định nghĩa rõ ràng

- Phòng chống lỗi: Kiến trúc microservice sinh ra là để dành cho các hệ thống từ lớn đến vô cùng lớn Nó áp dụng phương pháp chia để trị, phương pháp này giúp việc áp dụng các công cụ, kỹ thuật cho việc giám sát, phòng chống lỗi phần mềm, lỗi hệ thống hiệu quả Khi một thành phần trong hệ thống bị lỗi, nó có thể được thay thế bằng các thành phần dự phòng một cách dễ dàng, trong quá trình thay thế thành phần bị lỗi, các thành phần khác vẫn hoạt động bình thường, do vậy hoạt động của toàn bộ hệ thống sẽ không hoặc ít bị gián đoạn

2.1.3 Giao tiếp giữa các Microservices

Một hệ thống dựa trên microservice là một hệ thống phân tán chạy trên nhiều quy trình hoặc dịch vụ, thường là trên nhiều máy chủ hoặc máy chủ Mỗi trường hợp dịch vụ thường là một quy trình Do đó, các dịch vụ phải tương tác bằng giao thức giao tiếp giữa các quá trình như HTTP, AMQP hoặc giao thức nhị phân như TCP, tùy thuộc vào bản chất của mỗi dịch vụ

ASP.NET Core là g? Nó là một open-source mới và framework đa nền tảng (cross-platform) cho việc xây dựng những ứng dụng hiện tại dựa trên kết nối đám mây, giống như web apps, IoT và backend cho mobile Ứng dụng ASP.NET Core có thể chạy trên NET Core hoặc trên phiên bản đầy đủ của NET Framework Nó được thiết kế để cung cấp và tối ưu development framework cho những dụng cái mà được triển khai trên đám mây (clound) hoặc chạy on-promise

Nó bao gồm các thành phần theo hướng module nhằm tối thiểu tài nguyên và chi phí phát triển, như vậy bạn giữ lại được sự mềm giẻo trong việc xây dựng giải pháp của bạn Bạn có thể phát triển và chạy những ứng dụng ASP.NET Core đa nền tảng trên Windows, Mac và Linux Đồng thời nó đã trở thành một mã nguồn mở Đây là một thay đổi rất lớn và theo mình là quan trọng nhất của ASP.NET Core Điều mà trước đây khó có một lập trình viên nào có thể nghĩ đến Có lẽ đó cũng là một xu thế mà các ngôn ngữ lập trình hiện nay đang hướng tới [1]

HTML (viết tắt của từ HyperText Markup Language, hay là "Ngôn ngữ Đánh dấu Siêu văn bản") là một ngôn ngữ đánh dấu được thiết kế ra để tạo nên các trang web trên World Wide Web Nó có thể được trợ giúp bởi các công nghệ như CSS và các ngôn ngữ kịch bản giống như JavaScript

Các trình duyệt web nhận tài liệu HTML từ một web server hoặc một kho lưu trữ cục bộ và render tài liệu đó thành các trang web đa phương tiện HTML mô tả cấu trúc của một trang web về mặt ngữ nghĩa và các dấu hiệu ban đầu được bao gồm cho sự xuất hiện của tài liệu

Các phần tử HTML là các khối xây dựng của các trang HTML Với cấu trúc HTML, hình ảnh và các đối tượng khác như biểu mẫu tương tác có thể được nhúng vào trang được hiển thị HTML cung cấp một phương tiện để tạo tài liệu có cấu trúc bằng cách biểu thị ngữ nghĩa cấu trúc cho văn bản như headings, paragraphs, lists, links, quotes và các mục khác Các phần tử HTML được phân định bằng các tags, được viết bằng dấu ngoặc nhọn Các tags như và giới thiệu trực tiếp nội dung vào trang Các tags khác như

bao quanh và cung cấp thông tin về văn bản tài liệu và có thể bao gồm các thẻ khác làm phần tử phụ Các trình duyệt không hiển thị các thẻ HTML, nhưng sử dụng chúng để diễn giải nội dung của trang

HTML có thể nhúng các chương trình được viết bằng scripting như JavaScript, điều này ảnh hưởng đến hành vi và nội dung của các trang web Việc bao gồm CSS xác định giao diện và bố cục của nội dung World Wide Web Consortium (W3C), trước đây là đơn vị bảo trì HTML và là người duy trì hiện tại của các tiêu chuẩn CSS, đã khuyến khích việc sử dụng CSS trên HTML trình bày rõ ràng kể từ năm 1997 [2]

CSS là chữ viết tắt của Cascading Style Sheets, nó là một ngôn ngữ được sử dụng để tìm và định dạng lại các phần tử được tạo ra bởi các ngôn ngữ đánh dấu (HTML) Nói ngắn gọn hơn là ngôn ngữ tạo phong cách cho trang web Bạn có thể hiểu đơn giản rằng, nếu HTML đóng vai trò định dạng các phần tử trên website như việc tạo ra các đoạn văn bản, các tiêu đề, bảng…thì CSS sẽ giúp chúng ta có thể thêm style vào các phần tử HTML đó như đổi bố cục, màu sắc trang, đổi màu chữ, font chữ, thay đổi cấu trúc…

CSS được phát triển bởi W3C (World Wide Web Consortium) vào năm

1996, vì HTML không được thiết kế để gắn tag để giúp định dạng trang web

Phương thức hoạt động của CSS là nó sẽ tìm dựa vào các vùng chọn, vùng chọn có thể là tên một thẻ HTML, tên một ID, class hay nhiều kiểu khác Sau đó là nó sẽ áp dụng các thuộc tính cần thay đổi lên vùng chọn đó

Mối tương quan giữa HTML và CSS rất mật thiết HTML là ngôn ngữ markup (nền tảng của site) và CSS định hình phong cách (tất cả những gì tạo nên giao diện website), chúng là không thể tách rời [3]

THIẾT KẾ VÀ CÀI ĐẶT GIẢI PHÁP

Chương này sẽ trình bày những thiết kế và cài đặt cho hệ thống thi trắc nghiệm trực tuyến dựa trên kiến trúc Microservices Đầu tiên, chương này sẽ mô tả tổng quan về hệ thống, sau đó sẽ trình bày về thiết kế cơ sở dữ liệu cho từng Service, dữ liệu giao tiếp giữa các Service và cuối cùng là thiết kế theo chức năng và giao diện cho hệ thống

3.1.1 Các vấn đề về thiết kế một kiến trúc microservice

Nhiều tổ chức, như Amazon, eBay và Netflix, đã giải quyết vấn đề này bằng cách áp dụng những gì bây giờ được gọi là Microservices Architecture pattern Thay vì xây dựng một ứng dụng đơn khối, ý tưởng là chia ứng dụng của bạn thành một tập hợp các services kết nối nhỏ hơn

Một service thường thực hiện một tập hợp các tính năng hoặc chức năng riêng biệt, chẳng hạn như quản lý đơn hàng, quản lý khách hàng, v.v … Mỗi microservice là một ứng dụng nhỏ có cấu trúc lục giác (hexagonal architecture) riêng bao gồm logic nghiệp vụ cùng với các adapters khác nhau Một số microservice sẽ cung cấp API được sử dụng bởi các microservices khác hoặc bởi các ứng dụng của khách hàng Một số Microservices khác có thể triển khai giao diện người dùng web Khi chạy, mỗi instance thường là một cloud VM or a Docker container

Mô hình Microservices tác động đáng kể đến mối quan hệ giữa ứng dụng và cơ sở dữ liệu Thay vì chia sẻ một lược đồ cơ sở dữ liệu duy nhất với các dịch vụ khác, mỗi dịch vụ có lược đồ cơ sở dữ liệu riêng của nó Một mặt, cách tiếp cận này là mâu thuẫn với ý tưởng của một mô hình dữ liệu toàn doanh nghiệp Ngoài ra, nó thường dẫn đến trùng lặp một số dữ liệu Tuy nhiên, có một lược đồ cơ sở dữ liệu cho mỗi dịch vụ là điều cần thiết nếu bạn muốn hưởng lợi từ microservices, bởi vì nó đảm bảo các khớp nối lỏng lẻo (loose coupling)

Mỗi dịch vụ đều có cơ sở dữ liệu riêng Hơn nữa, một dịch vụ có thể sử dụng một loại cơ sở dữ liệu phù hợp nhất với nhu cầu của nó, cái gọi là kiến trúc bền bỉ đa điểm (polyglot persistence architecture) Ví dụ: Driver Management cần tìm tài xết gần với hành khách tiềm năng, phải sử dụng cơ sở dữ liệu hỗ trợ truy vấn địa lý hiệu quả

Phát triển một hệ thống website bán sách cho một cửa hàng với kiến trúc Microservices dùng ASP.NET Core cùng với các hệ quản trị cơ sở dữ liệu để lưu trữ và truy xuất dữ liệu

Các Service trong kiến trúc Microservices cần được xác định sao cho các Service này phải tách rời nhau nhằm đảm bảo khi thay đổi bất cứ Service nào cũng không làm ảnh hưởng đến các Service khác nhưng đồng thời cũng cần đảm bảo phải đáp ứng đầy đủ yêu cầu của hệ thống

Việc xác định các Service phải đảm bảo sao cho khi ta muốn thay đổi một hành vi hoặc một chức năng nào đó thì chúng ta chỉ cần thay đổi ở một Service Để làm được điều này chúng ta nên nhóm các hành vi có liên quan với nhau lại trong cùng một Service nhưng việc nhóm các hành vi này vẫn phải đảm bảo không làm tăng tính phụ thuộc giữa cho các Service trong hệ thống

Hệ thống sẽ được xây dựng với kiến trúc bên dưới đây:

Hình 3.1: Sơ đồ kiến trúc hệ thống nti t r ic M ic r r ic a k t r rin g n nt r a ckg r n r ic a il r ic r ct nt ata a gl M at a tat a lth C h ck n nt r g C C h ck t a g a rch t rt r n tit r ct a k t r r n nt r

Các request từ Client sẽ được điều hướng đến các Service tương ứng thông qua API Gateway

Dựa trên yêu cầu của hệ thống, ta sẽ chia hệ thống thành những Service khác nhau để đảm nhiệm nhóm chức năng nhất định:

• Identity Service: Đảm nhiệm nhóm chức năng liên quan đến quản lý đăng nhập, đăng ký, xác thực người dùng, định danh người dùng

• Product API: Đảm nhiệm nhóm chức năng liên quan đến quản lý sản phẩm

• Basket API: Đảm nhiệm nhóm chức năng liên quan đến giỏ hàng của người dùng

• Ordering API: Đảm nhiệm nhóm chức năng liên quan đến đặt hàng và quản lý đơn hàng của người dùng

• Inventoty API: Đảm nhiệm nhóm chức năng liên quan đến kho

• Inventory gRPC: Đảm nhiệm chức năng tính số tồn kho của sản phẩm và trả về kết quả

• Checkout Saga.Orchestrtor: Đảm nhiệm chức năng checkout một đơn hàng

• Background Job Service dùng để xử lý ứng dụng nền, task nền Dùng Google SMTP

• WebStatus HealthCheck để kiểm tra các services có chạy tốt không

Các Service sẽ giao tiếp với nhau một cách bất đồng bộ qua một Message Bus, cụ thể sẽ là RabbitMQ Việc giao tiếp bất đồng bộ sẽ giúp các Service có thể tiếp tục thực hiện tác vụ khác khi đã gửi một thông điệp bất kì mà không cần đợi Service khác phản hồi Đồng thời, các Service cũng sẽ cần giao tiếp đồng bộ với nhau Với sự hỗ trợ của gRPC, các thông điệp sẽ được truyền tải nhanh hơn rõ rệt

Do hệ thống được chia thành nhiều service khác nhau nên mỗi service phải được thiết kế một cơ sở dữ liệu riêng để có thể hoạt động độc lập, hạn chế phục thuộc vào dữ liệu của service khác nhất có thể Đảm bảo đặc tính độc lập của Microservices

3.2.1 Cơ sở dữ liệu ProductDB (MySQL)

- Với những ưu điểm của MySQL như: ổn định, dễ sử dụng, đặt biệt là cơ sở dữ liệu quan hệ giúp có thể dễ dàng tương tác để cài đặt các chức năng như tìm kiếm sản phẩm

- Cơ sở dữ liệu ProductDB dành cho ProductAPI service sẽ được thiết kế theo mô hình với bảng Product sẽ lưu trữ thông tin sản phẩm và bảng Category sẽ lưu trữ thông tin danh mục sản phẩm

Hình 3.2: Mô hình dữ liệu logic của ProductDB Bảng 3.1: Mô tả bảng Product của ProductDB

STT Tên thuộc tính Kiểu dữ liệu

1 Id int PK X Mã sản phẩm

2 No varchar X Mã sản phẩm

3 Name varchar X Tên sản phẩm

4 Description varchar Mô tả sản phẩm

5 Detail varchar Chi tiết sản phẩm

6 Price decimal X Giá sản phẩm

8 ImageUrl varchar X Liên kết hình ảnh

Bảng 3.2: Mô tả bảng Category của ProductDB

1 Id int PK X Mã danh mục

2 Name varchar X Tên danh mục

3 ParentId int FK Mã của danh mục cha

Bảng 3.3: Mô tả bảng ProductCategory của ProductDB

1 ProductId int PK X Mã sản phẩm

2 CategoryId varchar X Mã danh mục

3.2.2 Cơ sở dữ liệu BasketDB (Redis)

- Với việc Redis là một cơ sở dữ liệu bộ nhớ cache, chúng ta có thể dùng nó để tăng hiệu suất với việc các nhóm chức năng liên quan đến quản lí giỏ hàng sẽ được sử dụng rất nhiều bởi người dùng

- Cơ sở dữ liệu CustomerDB dành cho BasketAPI service sẽ thiết kế và lưu trữ với dạng key-value sẽ lưu trữ thông tin giỏ hàng khách hàng Key: Username

Value: là một string json có dạng như sau:

"itemName": " Nhà Giả Kim (Tái Bản 2020)",

"itemUrl": " https://cloud.com/iamge.jpg",

3.2.3 Cơ sở dữ liệu OrderingDB (SQL Server)

KIỂM THỬ VÀ ĐÁNH GIÁ

Chương này sẽ trình bày quy trình và đánh giả kết quả kiểm thử đối với một số chức năng cơ bản của hệ thống

- Nhằm kiểm soát và phát hiện các lỗi tiềm ẩn có trong hệ thống

- Kiểm tra các tính năng có hoạt động đúng với các yêu cầu đặt ra hay không

- Liệt kê kết quả có được sau khi kiểm thử

- Làm tài liệu cho giai đoạn bảo trì

Quy trình kiểm thử được thực hiện qua các công đoạn:

- Kiểm thử thiết kế: kiểm tra giao diện thiết kế có đúng với đặc tả

- Kiểm thử chấp nhận: kiểm thử chức năng hệ thống có hoạt động và đáp ứng đặc tả yêu cầu

- Kiểm thử chức năng: kiểm thử chức năng có xử lý đúng dữ liệu

- Kiểm thử cài đặt: tìm và sửa các lỗi xảy ra khi kiểm thử

4.2 Chi tiết kế hoạch kiểm thử

4.2.1 Các trường hợp kiểm thử

- Chức năng thêm sản phẩm vào giỏ hàng

Với mỗi tính năng chính hay các nhóm tính năng sẽ được kiểm thử theo thứ tự từ trên xuống dưới và từ trái sang phải để đảm bảo rằng sẽ kiểm thử không bỏ sót chức năng cần kiểm thử

4.2.3 Tiêu chí kiểm thử thất bại/thành công

- Tiêu chí kiểm thử thành công là kết quả thực hiện chức năng đúng với mong đợi, phù hợp với đặc tả yêu cầu

- Tiêu chí kiểm thử thất bại là kết quả không như mong đợi, xuất hiện lỗi, không phù hợp với các yêu cầu đặc tả

4.2.4 Tiêu chí đình chỉ và yêu cầu bắt đầu lại

- Tiêu chí đình chỉ là dừng việc thực hiện công việc khi một chức năng thông báo lỗi

- Yêu cầu bắt đầu lại khi chức năng đình chỉ đã được sửa lỗi

4.3.1 Các hoạt động/công việc được lập kế hoạch, sự tiến hành kiểm thử

- Lập kế hoạch kiểm thử

- Bộ vi xử lý: Intel core i5 11th 1135G7

- Hệ điều hành: Windows 10 Home 64 bit

- Cơ sở dữ liệu: SQL Server

4.3.3 Trách nhiệm và quyền hạn

Bảng 4.1: Trách nhiệm và quyền hạn kiểm thử

4.3.4 Tài nguyên và sự cấp phát nhúng

- Tài nguyên sử dụng kiểm thử: Laptop

- Các công cụ hỗ trợ trong quá trình kiểm thử: Postman, Google Chrome, Microsoft Edge, FireFox

4.3.5 Kế hoạch dự đoán và chi phí

Bảng 4.2: Mô tả kế hoạch dự đoán và chi phí

Công việc Thời gian (ngày) Công cụ

Lập kế hoạch kiểm thử 1 Microsoft Word

Thiết kế test case 1 Microsoft Word

Tiến hành kiểm thử 1 Google Chrome,

Microsoft Edge Đánh giá 1 Microsoft Word

Bảng 4.3: Các rủi ro kiểm thử

Tên rủi ro Mức độ Kế hoạch

Kiểm thử không đúng tiến độ

Cao Cần bằng thời gian giữa các lần kiểm thử, tăng cường hiệu suất kiểm thử.

Thiếu nhân sự kiểm thử Cao Tăng số lượng kiểm thử và tốc độ kiểm thử Kiểm thử không hiệu quả Trung bình Tham khảo các nguồn tài liệu kiểm thử

Bảng 4.4: Mô tả kịch bản kiểm thử

Mã Tài liệu đặc tả Mô tả kịch bản kiểm thử

Số trường hợp kiểm thử

TS_FQ_01 Mục 1.1.2.3.2 Kiểm tra người dùng có thể đăng nhập vào hệ thống

TS_FQ_02 Mục 1.1.2.3.9 Kiểm tra người dùng có thể thêm sản phẩm vào giỏ hàng của họ

TS_FQ_03 Mục 1.1.2.3.12 Kiểm tra người dùng có thể đặt hàng

4.4 Các trường hợp kiểm thử

Sau khi thực hiện kiểm thử và sửa lỗi, các trường hợp kiểm thử cuối cùng được trình bày bên dưới

- Tiền điều kiện: Phải có kết nối Internet và đang truy cập vào trang đăng nhập

Bảng 4.5: Kịch bản kiểm thử đăng nhập

Kết quả thực tế Đánh giá

Kiểm thử đăng nhập với dữ liệu hợp lệ

Tài khoản đã tồn tại trước đó

2 Gủi dữ liệu kiểm thử vào hệ thống:

Trả về accce ss token

Kiểm thử đăng nhập với dữ liệu không hợp lệ

Tài khoản đã tồn tại trước đó

Tài khoản đã tồn tại

2 Gủi dữ liệu kiểm thử vào

Pass với dữ liệu không hợp lệ

(passw ord rỗng) trước đó

4.4.2 Thêm sản phẩm vào giỏ hàng

Bảng 4.6: Kịch bản kiểm thử thêm sản phẩm vào giỏ hàng

Kiểm thử thêm sản phẩm vào giỏ hàng với dữ liệu hợp lệ

Người dùng đã đăng nhập vào hệ thống

-username: new@gmail.co m -items:

+ itemUrl: https://cloud.co m/image/1

Trả về giỏ hàng của user

Kiểm thử thêm sản phẩm vào giỏ hàng với dữ liệu không hợp lệ

Trả về lỗi với thông báo:

The field quant ity must be >Trả về lỗi với thông báo:

The field quant ity must be >Pass ty bằng

Kiểm thử thêm sản phẩm vào giỏ hàng với dữ liệu không hợp lệ

The field itemP rice must be >0.1

Bảng 4.7: Kịch bản kiểm thử đặt hàng

Kiểm thử đặt hàng với phươn g thức thanh toán

-Địa chỉ nhận hàng: 132 3/2, Hung Loi, Ninh Kieu,

1 Thêm sản phẩm vào giỏ hàng

3 Nhập thông tin giao hàng và chọn phương thức thanh toán

Trả về thông báo đặt hàng thành công

Kiểm thử đặt hàng với phươn g thức thanh toán

-Địa chỉ nhận hàng: 132 3/2, Hung Loi, Ninh Kieu, Can Tho

1 Thêm sản phẩm vào giỏ hàng

3 Nhập thông tin giao hàng và chọn phương thức thanh toán

Trả về thông báo đặt hàng thành công

4.5 Đánh giá kết quả kiểm thử

• Qua kết quả kiểm thử cho thấy: o Chức năng đăng nhập hoạt động đúng như mong đợi o Chức năng thêm sản phẩm vào giỏ hàng hoạt động đúng như mong đợi o Chức năng đặt hàng hoạt động đúng như mong đợi

ĐÁNH GIÁ HỆ THỐNG MICROSERVICES

5.1 Hệ thống nào nên áp dụng kiến trúc microservice

• Đường đi dài và có định hướng scale up

• Hệ thống có nhiều nghiệp và xử lý phức tạp

• Hệ thống có lượng người dùng lớn

• Các thành viên phát triển hệ thống phải có trình độ nhất định

• Quy mô lớn: Khi ứng dụng phải xử lý hàng ngàn hoặc hàng triệu yêu cầu mỗi ngày, kiến trúc microservice có thể giúp tăng tốc độ xử lý và giảm tải cho từng dịch vụ

• Độ linh hoạt cao: Khi ứng dụng phải thay đổi và phát triển liên tục, kiến trúc microservice cho phép phát triển và triển khai các dịch vụ độc lập nhau mà không cần phải thay đổi toàn bộ hệ thống

• Phân tán địa lý: Khi ứng dụng phải phục vụ nhiều địa điểm khác nhau, kiến trúc microservice cho phép triển khai các dịch vụ gần với người dùng để tối ưu tốc độ phản hồi

• Phân tách chức năng: Khi ứng dụng có nhiều chức năng phức tạp và phụ thuộc vào nhau, kiến trúc microservice giúp phân tách các chức năng đó thành các dịch vụ độc lập để dễ quản lý và bảo trì

5.2 Những điểm lợi của kiến trúc microservices

• Chuyên biệt hóa các nghiệp vụ theo service nên việc can thiệp cũng như bổ sung logic đỡ phức tạp hơn

• Triển khai theo từng service nên không ảnh hưởng lớn đến toàn bộ hệ thống

• Thoải mái trong việc lựa chọn công nghệ cho mỗi service

• Microservice cho phép bảo trì tốt hơn trong các hệ thống phức tạp, lớn và có tính mở rộng cao bằng cách cho phép bạn tạo các ứng dụng dựa trên nhiều dịch vụ có thể triển khai độc lập mà mỗi dịch vụ có tổ chức kết cấu và vòng đời riêng biệt

• Microservice có thể mở rộng quy mô độc lập Thay vì có một ứng dụng nguyên khối duy nhất mà bạn phải mở rộng thành một đơn vị, thay vào đó bạn có thể mở rộng quy mô các dịch vụ microservices cụ thể Bằng cách đó, bạn có thể chỉ mở rộng khu vực chức năng cần nhiều sức mạnh để xử lý hoặc băng thông mạng hơn để hỗ trợ nhu cầu, thay vì mở rộng các khu vực khác của ứng dụng không cần phải được chia tỷ lệ Điều đó có nghĩa là tiết kiệm chi phí vì bạn cần ít phần cứng hơn

Hình 5.1: So sánh kiến trúc Monolithic và Microservices

Như Hình trên cho thấy, theo cách tiếp cận nguyên khối truyền thống, ứng dụng chia tỷ lệ bằng cách nhân bản toàn bộ ứng dụng trong một số máy chủ/VM Trong cách tiếp cận microservice, chức năng được tách biệt trong các dịch vụ nhỏ hơn, do đó mỗi dịch vụ có thể mở rộng quy mô độc lập Cách tiếp cận microservice cho phép thay đổi nhanh và lặp lại nhanh chóng của từng microservice, bởi vì bạn có thể thay đổi các khu vực cụ thể, nhỏ của các ứng dụng phức tạp, lớn và có thể mở rộng

Kiến trúc các ứng dụng dựa trên microservice chi tiết cho phép tích hợp liên tục và thực hành phân phối liên tục Nó cũng tăng tốc cung cấp các chức năng mới vào ứng dụng Thành phần nhỏ của các ứng dụng cũng cho phép bạn chạy và kiểm tra các dịch vụ vi mô một cách cô lập và để phát triển chúng một cách tự chủ trong khi duy trì các hợp đồng rõ ràng giữa chúng Miễn là bạn không thay đổi giao diện hoặc hợp đồng, bạn có thể thay đổi việc triển khai nội bộ của bất kỳ dịch vụ microservice nào hoặc thêm chức năng mới mà không phá vỡ các services khác

5.3 Các khía cạnh quan trọng để xây dựng thành công một hệ thống microservices

• Giám sát và kiểm tra “sức khỏe” của các dịch vụ và cơ sở hạ tầng

• Cơ sở hạ tầng mở rộng cho các dịch vụ (cloud and orchestrators)

• Thiết kế và thực hiện bảo mật ở nhiều cấp độ: xác thực, phân quyền, quản lý bí mật, giao tiếp an toàn…

• Chuyển giao ứng dụng nhanh, thường với các nhóm khác nhau tập trung vào các dịch vụ microservice khác nhau

• DevOps và thực tiễn CI/CD và cơ sở hạ tầng

5.4 Những nhược điểm của kiến trúc Microservice

• Độ phức tạp quản lý: Kiến trúc microservice có nhiều phần tử nhỏ và phân tán, điều này gây ra độ phức tạp trong việc quản lý và giám sát các dịch vụ đó Vì vậy, cần có sự đầu tư và quản lý tốt để đảm bảo hoạt động ổn định của hệ thống

• Khó khăn trong việc kiểm tra, gỡ lỗi và thử nghiệm: Vì các dịch vụ trong kiến trúc microservice được phát triển và triển khai độc lập, việc kiểm tra, gỡ lỗi và thử nghiệm trở nên khó khăn hơn so với kiến trúc truyền thống Việc phát hiện và sửa lỗi cũng cần sự chuyên môn cao và thời gian đáp ứng nhanh

• Tăng chi phí vận hành: Vì có nhiều dịch vụ nhỏ, phân tán trong kiến trúc microservice, việc triển khai, cập nhật và quản lý hệ thống sẽ tốn nhiều chi phí hơn so với kiến trúc truyền thống Ngoài ra, việc triển khai kiến trúc này cần sự đầu tư vào các công cụ và công nghệ mới để có thể quản lý và giám sát các dịch vụ

• Vấn đề về bảo mật: Việc phân tán các dịch vụ trong kiến trúc microservice đồng nghĩa với việc tăng khả năng tấn công và giảm khả năng kiểm soát bảo mật của hệ thống Do đó, việc đảm bảo an ninh thông tin trong kiến trúc microservice trở nên phức tạp và đòi hỏi sự chuyên môn cao

• Khó khăn trong việc quản lý phiên bản: Vì các dịch vụ trong kiến trúc microservice có thể được phát triển độc lập, điều này dẫn đến việc quản lý phiên bản trở nên phức tạp hơn Việc đảm bảo tương thích và tính ổn định của các phiên bản khác nhau cũng đòi hỏi sự chuyên môn và công nghệ cao

5.5 Giao tiếp giữa các service sao cho hiệu quả

Việc giao tiếp giữa các Service cần phối hợp cả giao tiếp đồng bộ và giao tiếp không đồng bộ

Giao tiếp đồng bộ có nghĩa là các Service tham gia gửi và nhận dữ liệu phải đợi phản hồi từ Service còn lại Một ví dụ điển hình về việc trao đổi dữ liệu một cách đồng bộ là giao tiếp thông qua HTTP như Hình 5.2, khi một yêu cầu được gửi đến một Service thông qua HTTP, Service gửi yêu cầu sẽ phải đợi đến khi nhận được phản hồi

Hình 5.2: Giao tiếp đồng bộ giữa các services với HTTP/1.1

Việc đợi phải hồi từ Service khác có thể ảnh hưởng đến thời gian xử lý tác vụ của Service, nhất là khi một Service phải gửi yêu cầu đến nhiều Service khác nhau Vì vậy việc tối ưu thời gian phản hồi trong giao tiếp nội bộ giữa các Service là rất cần thiết

Tiêu đề	Phát triển ứng dụng quản lý bán hàng trực tuyến dùng Microservices
Tác giả	Dương Hoàng Kha
Người hướng dẫn	TS. Nguyễn Công Danh
Trường học	Trường Đại học Cần Thơ, Trường Công nghệ Thông tin và Truyền thông, Khoa Công nghệ Phần mềm
Chuyên ngành	Kỹ thuật Phần mềm
Thể loại	Luận văn tốt nghiệp
Năm xuất bản	2023
Thành phố	Cần Thơ

Định dạng
Số trang	105
Dung lượng	4,21 MB