PHẦN MỞ ĐẦU 1. TÍNH CẤP THIẾT CỦA ĐỀ TÀI Ngày nay, lĩnh vực CNTT đang phát triển mạnh mẽ, thúc đẩy việc đổi mới trong các hoạt động truyền thống như giáo dục, y tế, và kinh doanh. Một lĩnh vực ứng dụng mạnh mẽ CNTT không ai khác chính là thương mại điện tử. Hầu hết các công ty lớn hiện nay đều tập trung vào việc thúc đẩy kinh doanh trực tuyến.
Ngoài các sàn thương mại điện tử truyền thống như Lazada, Tiki, và Shopee, các ứng dụng mạng xã hội như TikTok và Facebook cũng tạo ra các sàn thương mại điện tử riêng để theo kịp xu thế hiện nay. Việc kinh doanh trực tuyến đã trở nên dễ dàng, ai cũng có thể tham gia vào thị trường này mà không cần đòi hỏi quá nhiều về kỹ thuật. Nhưng tại sao các hệ thống như Facebook và TikTok có thể tích hợp các sàn thương mại điện tử vào hệ thống của mình một cách nhanh chóng và dễ dàng, trong khi các tính năng cơ bản của họ vẫn hoạt động ổn định? Vì lý do này, nhóm em đã tìm hiểu về kiến trúc microservice, một nền tảng được sử dụng để xây dựng hầu hết các hệ thống lớn tại các công ty công nghệ. Chúng em quyết định áp dụng kiến thức này vào việc xây dựng sàn thương mại điện tử trong đề tài “Xây dựng hệ thống TMĐT áp dụng kiến trúc microservice”.
Website của chúng em mang đến tính năng mua bán hàng hóa giữa các người dùng, tích hợp các công nghệ thanh toán hiện nay, và tất cả đều được xây dựng trên kiến trúc microservice. Ngoài ra, chúng em tích hợp thêm trí tuệ nhân tạo để người dùng dễ dàng tìm kiếm sản phẩm bằng hình ảnh. MỤC TIÊU CỦA ĐỀ TÀI - Tìm hiểu kiến trúc Microservice và các công cụ liên quan. - Xây dựng trang thương mại điện tử hoàn chỉnh trên kiến trúc microservice.
- Website có chức năng quan trọng như quản lý người dùng, sản phẩm, giỏ hàng, cửa hàng, đặt hàng, tính phí vận chuyển, … - Tích hợp nhiều công nghệ mới vào hệ thống. - Triển khai ứng dụng và đánh giá hiệu năng thực tế. - Tích hợp vào trí tuệ nhân tạo để dễ dàng tìm kiếm sản phẩm. Trang 24 Khóa Luận Tốt Nghiệp - Triển khai thực tế trên môi trường Internet.
PHƯƠNG PHÁP THỰC HIỆN - Tìm hiểu các kiến thức liên quan đến kiến trúc Microservice - Khảo sát các hệ thống thực tế. - Tìm hiểu các công nghệ đang sử dụng trong các hệ thống lớn. - Đọc các tài liệu nghiên cứu về lĩnh vực tìm kiếm hình ảnh sử dụng Deep Learning - Phát triển các tính năng cốt lõi của một trang web thương mại điện tử. - Dùng Postman để kiểm tra lại hiệu năng của hệ thống Trang 25 Chương 1 Cơ Sở Lý Thuyết PHẦN NỘI DUNG CHƯƠNG 1.1 Kiến trúc Microservice 1.1 Giới thiệu về kiến trúc Microservice Microservice hiểu như việc tách các module thành những service nhỏ.
Mỗi service sẽ được hoạt động trên các môi trường khác nhau, giao tiếp với nhau thông qua HTTP/REST, Message Queues. Trước đây khi chưa có Microservice thì một kiến trúc thường được sử dụng đó là Monolith khi toàn bộ các chức năng của hệ thống được viết trên một ứng dụng. Những ứng dụng này thường rất nặng nề cồng kềnh có thể có từ vài trăm nghìn dòng code là chuyện bình thường. Cho nên rất khó khăn trong việc nâng cấp và bảo trì các tính năng trong ứng dụng.1 Mô hình mẫu của kiến trúc Monolithic Ngày nay khi xu thế các công nghệ mới phát triển và cập nhật liên tục cũng như các phần mềm được phát triển trong mô hình Agile khi phần thiết kế có thể được đổi mới liên tục phù hợp với yêu cầu thì kiến trúc nguyên khối có lẽ đã không còn hợp với thời đại nữa.
Trang 26 Chương 1 Cơ Sở Lý Thuyết Hình 1.2 Mô hình mẫu kiến trúc Microservice Kiến trúc microservice được ứng dụng trong các dụng Backend để giảm thiểu tính phức tạp của hệ thống khi chia thành các module nhỏ hơn. Trong kiến trúc microservice thì các nhóm tính năng liên quan với nhau sẽ được gom lại tạo thành một module để viết thành một ứng dụng ví dụ User-services có thể có các chức năng như đăng nhập đăng ký tài khoản, quản lý và phân quyền,… tương tự cho các service khác. Các service này được xây dựng trên nhiều công nghệ khác nhau và giao tiếp với nhau thông qua Message hoặc RestAPI tùy vào từng loại chức năng. Các service này sẽ được triển khai trên các hệ thống khác nhau và có thể ở nhiều vị trí địa lý mà không ảnh hưởng nhiều đến hiệu năng của hệ thống.
Nếu triển khai trên cùng một hệ thống thì thường sẽ dùng các môi trường ảo hóa như Docker để triển khai các service nằm trên các vùng ảo hóa khác nhau để tránh sự cố khi một vùng ảo hóa bị sự cố thì các chức năng vẫn có thể hoạt động một cách bình thường.2 Giao tiếp trong Microservice Tiếp theo ta cần biết vấn đề communication (giao tiếp) trong các ứng dụng microservice như thế nào. Phụ thuộc vào tính chất của service, người ta thường dùng 3 communication styles chính: - 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. Trong kiểu này người ta thường dùng các chuẩn như REST, gRPC, Apache Thrift… - Messaging: Sử dụng asynchronous messaging để giao tiếp giữa các serivces. Các services trao đổi message qua các kênh message.
Trang 27 Chương 1 Cơ Sở Lý Thuyết - Domain-specific protocol: Trong một vài trường hợp người ta cần dùng các chuẩn như SMTP, IMAP, RTMP, HLS, và HDS để giao tiếp giữa các ứng dụng. Khi hệ thống cần sử dụng các chức năng của các service một các tuần tự thực hiện đồng bộ từ trên xuống thì sẽ dùng RPI tiêu biểu là chuẩn Restful API để thực hiện giao tiếp. Khi các chức năng được thực hiện song song một các bất đồng bộ tiêu biểu là sử dụng mô hình EDA thì người ta sẽ sử dụng Message để giao tiếp giữa các services. Về message sẽ được giới thiệu rõ hơn ở phần công cụ hỗ trợ Microservices 1.3 Các công cụ hỗ trợ cho Microservice 1.1 Message Queue Message queue được hiểu như là một hộp thư, cho phép các thành phần/service trong một hệ thống (hoặc nhiều hệ thống), gửi thông tin cho nhau.
Các message có thể là dạng string, json,… tùy vào định nghĩ của người lập trình. Các message được lấy ra theo cơ chế FIFO (First In First Out). Một hệ thống sử dụng Message Queue thường có những thành phần sau đây: - Message: Thông tin được gửi đi (có thể là text, binary hoặc JSON) - Message Queue: Nơi chứa những message này, cho phép producer và consumer có thể trao đổi với nhau - Producer: Chương trình/service tạo ra thông tin, đưa thông tin vào message queue - Consumer: Chương trình/service nhận message từ message queue và xử lý, một chương trình/service có thể vừa là producer, vừa là consumer. Trong các hệ thống dùng kiến trúc microservice, ta sử dụng message queue để giúp các service liên hệ với nhau một cách bất đồng bộ.
Service A làm xong việc có thể gửi message queue để service B biết mà xử lý, không cần phải chờ service B làm xong. Trang 28 Chương 1 Cơ Sở Lý Thuyết Một số message queue hay được dùng hiện này bao gồm: RabbitMQ, Kafka (Kafka không chỉ dừng lại ở việc lưu trữ và phân phối phát triển nó rất mạnh mẽ do hỗ trợ các tính năng như stream pipeline,…) 1.2 Docker Tiền thân của docker chính là ảo hóa (virtualization) cho phép chia nhỏ một phần cứng thành nhiều phần cứng ảo (virtual machine) khác chạy trên nó. Tại các phần cứng ảo này sẽ được chạy độc lập tách biệt với nhau được quản lý bởi các chương trình ảo hóa. Tuy nhiên VM (virtual machine) thường theo các thành phần như OS (hệ điều hành), các ứng dụng đi kèm với OS cho nên dung lượng của từng VM là rất lớn có thể lên đến hàng chục Gigabyte làm cho hệ thống rất nặng nề.
Công nghệ container ra đời cho phép chia sẻ cùng một Host OS (Hệ điều hành gốc) thành các container chạy trên nó chỉ bao gồm các ứng dụng và dependency cần thiết cho ứng dụng làm giảm thiểu kích thước của ứng dụng khi được triển khai.3 Sự khác nhau giữa container và virtual machines Docker là một nền tảng để cung cấp cách để building, deploying và running ứng dụng dễ dàng hơn bằng cách sử dụng các containers. Trang 29 Chương 1 Cơ Sở Lý Thuyết Hình 1.4 Các thành phần của Docker Docker Engine : là thành phần chính của Docker, như một công cụ để đóng gói ứng dụng Docker Hub : là một nơi để lưu trữ các images. Trên DockerHub có hàng ngàn public images được tạo bởi cộng đồng cho phép bạn dễ dàng tìm thấy những image mà bạn cần. Images: là một khuôn mẫu để tạo một container.
Thường thì image sẽ dựa trên 1 image có sẵn với những tùy chỉnh thêm. Ví dụ bạn build 1 image dựa trên image Centos mẫu có sẵn để chạy Nginx và những tùy chỉnh, cấu hình để ứng dụng web của bạn có thể chạy được. Bạn có thể tự build một image riêng cho mình hoặc sử dụng những image được chia sẻ từ cộng đồng Docker Hub. Một image sẽ được build dựa trên những chỉ dẫn của Dockerfile.
Container: là một instance của một image. Bạn có thể create, start, stop, move or delete container dựa trên Docker API hoặc Docker CLI. Docker Client: là một công cụ giúp người dùng giao tiếp với Docker host. Trang 30 Chương 1 Cơ Sở Lý Thuyết Docker Daemon: lắng nghe các yêu cầu từ Docker Client để quản lý các đối tượng như Container, Image, Network và Volumes thông qua REST API.
Các Docker Daemon cũng giao tiếp với nhau để quản lý các Docker Service. Dockerfile: là một tập tin bao gồm các chỉ dẫn để build một image. Volumes: là phần dữ liệu được tạo ra khi container được khởi tạo.3 API Gateway Một hệ thống microservices sẽ có vài chục cho tới hàng trăm services khác nhau, nếu như client giao tiếp trực tiếp với các services này thì có thể số lượng cái endpoint URL sinh ra sẽ rất khủng khiếp cũng như việc phân bổ các luồng request tới từng service rất lộn xộn và khó quản lý trong việc bảo mật hệ thống cũng như các sự cố có thể diễn ra. Để giải quyết vấn đề trên thì API Gateway ra đời với nhiệm vụ chính là điều phối các luồng request đến từng service cụ thể trong hệ thống.
API Gateway thường dùng để phân luồng request, bảo mật API, giám sát (monitoring), phân tích (analytics) số lượng requests cũng như tình trạng hệ thống phía sau.