KHÓA LUẬN TỐT NGHIỆP XÂY DỰNG MẠNG XÃ HỘI CHO NHỮNG NGƯỜI YÊU THÚ CƯNG

Chương 6: Hướng dẫn triển khai và cài đặt hệ thống Chương 7: Kết luận: đưa ra ý kiến về khóa luận Chương 6: Hướng phát triển: nêu ra hướng phát triển của ứng dụng sau khi kết thúc khó

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

KHOA CÔNG NGHỆ PHẦN MỀM

NGUYỄN DUY CƯƠNG

VI CHÍ THIỆN

KHÓA LUẬN TỐT NGHIỆP

XÂY DỰNG MẠNG XÃ HỘI CHO NHỮNG NGƯỜI YÊU

THÚ CƯNG

Build a social network for pet lovers

KỸ SƯ NGÀNH KỸ THUẬT PHẦN MỀM

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH

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

KHOA CÔNG NGHỆ PHẦN MỀM

NGUYỄN DUY CƯƠNG – 16520147

VI CHÍ THIỆN – 16521169

KHÓA LUẬN TỐT NGHIỆP

XÂY DỰNG MẠNG XÃ HỘI CHO NHỮNG NGƯỜI YÊU

THÔNG TIN HỘI ĐỒNG CHẤM KHÓA LUẬN TỐT NGHIỆP

Hội đồng chấm khóa luận tốt nghiệp, thành lập theo Quyết định số

……… ngày ……… của Hiệu trưởng Trường Đại học Công nghệ Thông tin

LỜI CẢM ƠN

Để hoàn thành tốt đề tài luận văn tốt nghiệp này, với tình cảm chân thành, chúng em bao gồm Nguyễn Duy Cương và Vi Chí Thiện xin bày tỏ lòng biết ơn sâu sắc tới trường Đại học Công nghệ Thông tin - Đại học Quốc gia Thành phố Hồ Chí Minh đã xây dựng một môi trường học tập chất lượng, hiện đại và năng động, tạo điều kiện để chúng em học hỏi, phát triển tối đa bản thân Xin chúc trường ngày càng phát triển, hiện đại và hội nhập hơn, chúc trường ngày càng thể hiện được vị thế trung tâm hàng đầu về nghiên cứu, đào tạo nguồn nhân lực chất lượng cao trong khu vực châu Á và thế giới

Chúng em xin bày tỏ lòng cám ơn thân thương nhất tới các thầy cô trong khoa Công nghệ Phần mềm, xin cám ơn thầy cô đã truyền đạt những kiến thức và những kinh nghiệm bổ ích giúp chúng em ứng dụng và hoàn thành tốt khóa luận tốt nghiệp lần này Xin chúc khoa sẽ chinh phục được những thành tựu mới trong giảng dạy, đào tạo và nghiên cứu, xin chúc các thầy cô có thật nhiều sức khoẻ, hạnh phúc để mãi vun đắp cho sự nghiệp trồng người

Đặt biệt, chúng em xin trân trọng gửi lời cảm ơn tới người thầy đáng kính Nguyễn Công Hoan đã dẫn dắt, cố vấn, tiếp sức cho chúng em trong suốt thời sinh viên về học tập, công việc, cuộc sống Thầy là người trực tiếp nhận trách nhiệm hướng dẫn

và giúp đỡ chúng em hoàn thành xuất sắc đề tài luận văn tốt nghiệp này Xin cám ơn thầy, chúc thầy luôn luôn mạnh khoẻ, hạnh phúc và thành công

Chúng em xin chân thành cảm ơn!

TP Hồ Chí Minh, ngày 15 tháng 1 năm 2021

Nguyễn Duy Cương

Vi Chí Thiện

MỤC LỤC

Chương 1 MỞ ĐẦU 2

1.1 Lý do chọn đề tài 2

1.2 Mục đích 3

1.3 Đối tượng 3

1.4 Phạm vi nghiên cứu 4

Chương 2 TỔNG QUAN 6

2.1 Tình hình mạng xã hội ở Việt Nam 6

2.2 Tổng quan thị trường thú cưng 7

2.3 Thị trường mạng xã hội thú cưng 7

2.4 Tầm nhìn phát triển của dự án 4Pet 8

2.5 Bài toán giải quyết trong khoá luận 8

2.5.1 Xây dựng phiên bản MVP 9

2.5.2 Xây dựng hệ thống hiệu năng cao, dễ dàng mở rộng 9

Chương 3 CƠ SỞ LÝ THUYẾT 10

3.1 Lý thuyết về sản phẩm và quy trình phát triển phần mềm 10

3.1.1 MVP 10

3.1.1.1 MVP là gì? 10

3.1.1.2 Ý nghĩa của MVP 11

3.1.2 Agile và Scrum 11

3.1.2.1 Tổng quan về Agile 11

3.2.1 Flutter 15

3.2.1.1 Flutter là gì? 15

3.2.1.2 Lý do chọn flutter 15

3.2.2 Google Play Console 16

3.3 Lý thuyết về kiến trúc hệ thống 17

3.3.1 Tổng quan về kiến trúc Microservice 17

3.3.1.1 Kiến trúc Monolithic 17

3.3.1.2 Kiến trúc Microservice 19

3.3.2 Tìm hiểu về CQRS (Command Query Responsibility Segregation) 22 3.3.2.1 Mô hình MVC 22

3.3.2.2 Mô hình 3 lớp 23

3.3.2.3 Mô hình CQRS 26

3.3.2.4 Tóm tắt về 3 mô hình 28

3.3.3 CDC (Change Data Capture) với Debezium 29

3.3.3.1 CDC là gì? 29

3.3.3.2 Tổng quan về Debezium 29

3.3.4 Message Queue 32

3.3.4.1 Message Queue là gì? 32

3.3.4.2 Phân loại Message Queue 33

3.3.4.3 Tổng quan về Kafka 34

3.4 Lý thuyết về công nghệ cho back-end service 36

3.4.1 Elasticsearch 36

3.4.1.1 Elasticsearch là gì? 36

3.4.1.2 Các khái niệm cơ bản 37

3.4.1.3 Ưu nhược điểm của Elasticsearch 40

3.4.2 Tổng quan về gRPC 41

3.4.2.1 RPC 41

3.4.2.2 Protobuf 42

3.4.2.3 gRPC 43

3.4.3 GraphQL 44

3.4.3.1 GraphQL là gì? 44

3.4.3.2 Đặc điểm của GraphQL 44

3.4.3.3 Lợi ích GraphQL 45

3.4.4 Docker 45

3.4.4.1 Tại sao phải dùng Docker? 45

3.4.4.2 Docker là gì? 46

3.4.4.3 Lợi ích của Docker 46

3.4.4.4 Một số khái niệm 47

3.4.4.5 Dockerfile 48

3.4.5 NodeJS 49

3.4.5.1 NodeJS là gì? 49

3.4.5.2 Các đặc tính của NodeJS 49

3.5 Lý thuyết về DevOps 50

3.5.1 Kubernetes 50

3.5.1.1 Tổng quan về Kubernetes 50

3.5.2.1 CI/CD là gì? 55

3.5.2.2 CI/CD với GitHub Actions 56

3.5.3 Google Cloud 58

3.5.3.1 Google Cloud là gì? 58

3.5.3.2 Những dịch vụ Google Cloud cấp cao 59

Chương 4 Giải quyết vấn đề 61

4.1 GraphQL hiệu năng cao với HTTP/2 61

4.1.1 Tổng quan về kiến trúc hệ thống 61

4.1.2 Vấn đề của GraphQL với HTTP/1.1 62

4.1.3 Triển khai GraphQL với HTTP/2 64

4.2 Kiến trúc Microservices 67

4.2.1 Gateway service 68

4.2.1.1 Schema Stitching 68

4.2.1.2 Authentication / Authorization 69

4.2.1.3 API Document 71

4.2.2 Các microservice 72

4.2.3 GraphQL PubSub 73

4.2.4 Database 74

4.2.4.1 SQL 74

4.2.4.2 NoSQL 74

4.2.4.3 Elasticsearch 75

4.3 Hệ thống realtime với Kafka và GraphQL Subscription 75

4.3.1 Vấn đề áp dụng 75

4.3.2 Triển khai hệ thống realtime 76

4.4 Tối ưu luồng Read và Write cho database với Change Data Capture(CDC) 77

4.5 Tối ưu Elasticsearch model với Kafka Stream 81

4.6 Kubernetes 83

4.6.1 Quản trị Docker image bằng Docker Hub 83

4.6.2 Triển khai và điều khiển Kubernetes cluster bằng kubectl 84

4.6.3 Quản lý Kubernetes một cách trực quan bằng K9S 87

4.6.4 Định nghĩa Secret và ConfigMap 88

4.6.5 Định nghĩa Deployment 90

4.6.6 Định nghĩa Volume 92

4.6.7 Định nghĩa Service 94

4.6.8 Cấu hình Ingress 96

4.6.9 Horizontal Pod Autoscaler 97

4.7 CI/CD 98

4.7.1 CI/CD cho 4pet-sdk 98

4.7.2 CI/CD cho microservice 99

Chương 5 Phân tích thiết kế hệ thống 101

5.1 Kiến trúc hệ thống 101

5.1.1 Kiến trúc tổng quan 101

5.1.2 Kiến trúc Microservices: 102

5.1.3 Kiến trúc database 103

5.2.3 Đặc tả use-case 106

5.2.3.1 Login 106

5.2.3.2 Story 107

5.2.3.3 Notification 108

5.2.3.4 Chat 109

5.2.3.5 Discover 110

5.2.3.6 Profile 111

5.2.3.7 Logout 112

5.3 Thiết kế cơ sở dữ liệu 114

5.3.1 Cơ sở dữ liệu của auth service 114

5.3.1.1 Mô tả lớp account 114

5.3.1.2 Mô tả bảng user 115

5.3.1.3 Mô tả bảng social_account 116

5.3.1.4 Mô tả bảng thông tin người theo dõi 117

5.3.2 Cơ sở dữ liệu của media service 118

5.3.2.1 Mô tả bảng media 119

5.3.2.2 Mô tả bảng storage 119

5.3.3 Cơ sở dữ liệu của story service 120

5.3.3.1 Mô tả bảng story 121

5.3.3.2 Mô tả bảng comment 121

5.3.3.3 Mô tả bảng comment_media 122

5.3.3.4 Mô tả bảng story_media 123

5.3.4 Cơ sở dữ liệu của notification service 124

5.3.5 Cơ sở dữ liệu của reaction service 125

5.3.6 Cơ sở dữ liệu của chat service 127

5.4 Thiết kế giao diện 128

5.4.1 Màn hình đăng nhập: 128

5.4.2 Màn hình story 130

5.4.3 Màn hình hiển thị danh sách bình luận 132

5.4.4 Màn hình create story 133

5.4.5 Màn hình tạo story với danh sách hình ảnh và video 134

5.4.6 Hình ảnh nội dung story 135

5.4.7 Màn hình discover 136

5.4.8 Màn hình tìm kiếm story và user 137

5.4.9 Màn hình kết quả tìm kiếm story 138

5.4.10 Màn hình kết quả tìm kiếm user 139

5.4.11 Màn hình thông báo 140

5.4.12 Màn hình danh sách đoạn hội thoại 141

5.4.13 Màn hình chi tiết hội thoại 142

5.4.14 Màn hình thêm mới một hội thoại 143

5.4.15 Màn hình profile 144

5.4.16 Màn hình follower 145

5.4.17 Màn hình sửa đổi profile 146

Chương 6 Cài đặt và triển khai hệ thống 147

6.1 Cài đặt và triển khai hệ thống trên Azure Kubernetes Service (AKS) 147

6.1.2.2 Cài đặt kubectl 147

6.1.2.3 Cài đặt k9s 148

6.1.3 Khởi tạo Kubernetes cluster instance trên Azure Kubernetes Service (AKS) 148 6.1.3.1 Đăng nhập Azure từ Azure CLI 148

6.1.3.2 Tạo một resource group 149

6.1.3.3 Lấy danh sách các phiên bản Kubernetes sẵn có theo khu vực 150

6.1.3.4 Tạo một Cluster 152

6.1.3.5 Xác nhận AKS Cluster đã tồn tại 153

6.1.3.6 Đặt AKS Cluster là context mặc định của kubectl 155

6.1.4 Triển khai hệ thống 155

6.1.4.1 Cấu trúc source code: 155

6.1.4.2 Áp dụng cấu hình hệ thống lên Azure Kubernetes Service (AKS) 157 6.2 Cài đặt triển khai ứng dụng di động: 157

6.2.1 Yêu cầu hệ thống: 157

6.2.2 Chạy chương trình 158

Chương 7 Kết luận 159

Chương 8 Hướng phát triển 160

8.1 Trong thời gian ngắn hạn: 160

8.2 Trong 1 năm tới: 160

DANH MỤC HÌNH

Hình 3.1: MVP là gì? 10

Hình 3.2: 4Pet sử dụng Trello để quản lý dự án 14

Hình 3.3: Kiến trúc Monolithic 17

Hình 3.4: Kiến trúc Microservice 20

Hình 3.5: Mô hình MVC 22

Hình 3.6: Mô hình 3 lớp 25

Hình 3.7: Mô hình CQRS 27

Hình 3.8: Kiến trúc Debezium 30

Hình 3.9: Message Queue là gì? 32

Hình 3.10: Point to point 33

Hình 3.11: Publisher - Subscriber 33

Hình 3.12: Cấu trúc của Kafka cơ bản 34

Hình 3.13: Cấu trúc của Kafka chi tiết 35

Hình 3.14: Mô hình giao tiếp client/server trong RPC 42

Hình 3.15: Benchmarking Protocol Buffers, JSON, and XML in Go 43

Hình 3.16: gRPC technology stack 43

Hình 3.17: Kiến trúc của GraphQL 45

Hình 3.18: Truy vấn GraphQL 45

Hình 3.19: Kiến trúc của Docker 47

Hình 4.2: Kiến trúc cơ bản của hệ thống với GraphQL sử dụng HTTP/1.1 62

Hình 4.3: So sánh REST và gRPC về response time 63

Hình 4.4: So sánh REST và gRPC về throughput 63

Hình 4.5: Kiến trúc cơ bản của hệ thống với GraphQL sử dụng HTTP/2 64

Hình 4.6: Kiến trúc của hệ thống với GraphQL và gRPC 65

Hình 4.7: Triển khai GraphQL server với HTTP2 66

Hình 4.8: Kiến trúc microservices của 4Pet 67

Hình 4.9: Schema Stitching 68

Hình 4.10: GraphQL Playground Web 72

Hình 4.11: GraphQL Subscription tích hợp với Kafka 74

Hình 4.12: Hệ thống realtime cơ bản 76

Hình 4.13: Kiến trúc realtime sử dụng Kafka và GraphQL Subscription 77

Hình 4.14: Sử dụng Kafka và Debezium để đồng bộ dữ liệu từ PostgreSQL sang Elasticsearch 78 Hình 4.15: Định nghĩa Kafka và Debezium bằng Docker Compose 79

Hình 4.16: Control Center Overview 80

Hình 4.17: Control Center Topics 80

Hình 4.18: Control Center Connect 81

Hình 4.19: Cấu trúc model của Elasticsearch 81

Hình 4.20: Sử dụng Kafka Stream để tổng hợp model cho Elasticsearch 82

Hình 4.21: Mô hình microservices triển khai sử dụng Kubernetes 83

Hình 4.22: Một Docker image của dự án 4pet trên Docker Hub 84

Hình 4.23: Lệnh get 85

Hình 4.24: Lệnh describe 85

Hình 4.25: Lệnh delete 86

Hình 4.26: Lệnh apply 86

Hình 4.27: lệnh logs 86

Hình 4.28: Lệnh autoscale 86

Hình 4.29: Danh sách các pod của 4pet’s Kubernetes cluster 87

Hình 4.30: Danh sách các container của một pod 88

Hình 4.31: Log của một container 88

Hình 4.32: Một file Secret của dự án 4Pet 89

Hình 4.33: Một file ConfigMap của dự án 4Pet 90

Hình 4.34: Một file Deployment của dự án 4Pet 91

Hình 4.35: Một file Storage Class của dự án 4Pet 92

Hình 4.36: Một file Volume của dự án 4Pet 93

Hình 4.37: Một file Service của dự án 4Pet 95

Hình 4.38: Một file Ingress của dự án 4Pet 96

Hình 4.39: Một file Horizontal Pod Autoscaler của dự án 4Pet 97

Hình 4.40: CI/CD cho 4pet-sdk 98

Hình 4.41: Kết quả chạy CI/CD 98

Hình 4.42: CI/CD cho microservice 99

Hình 4.43: Kết quả chạy CI/CD 100

Hình 5.2: Kiến trúc microservice 102

Hình 5.3: Kiến trúc database 103

Hình 5.7: Cơ sở dữ liệu của story service 120

Hình 5.8: Bảng thông báo 124

Hình 5.9: Cơ sở dữ liệu của chat service 127

Hình 5.10: Màn hình login 129

Hình 5.11: Màn hình story 131

Hình 5.12: Màn hình comment 132

Hình 5.13: Màn hình tạo story bước 1 133

Hình 5.14: Màn hình tạo story với danh sách hình ảnh và video 134

Hình 5.15: Màn hình tạo nội dung cho story 135

Hình 5.16: Màn hình discovery 136

Hình 5.17: Màn hình tìm kiếm user và story 137

Hình 5.18: Màn hình kết quả tìm kiếm story 138

Hình 5.19: Màn hình kết quả tìm kiếm người dùng 139

Hình 5.20: Màn hình danh sách thông báo 140

Hình 5.21: Màn hình danh sách hội thoại 141

Hình 5.22: Màn hình chi tiết hội thoại 142

Hình 5.23: Màn hình thêm mới hội thoại 143

Hình 5.24: Màn hình profile 144

Hình 5.25: Màn hình Follower 145

Hình 5.26: Màn hình sửa đổi profile 146

Hình 6.2: Cài đặt kubectl 148

Hình 6.3: Cài đặt k9s 148

Hình 6.4: Đăng nhập Azure 148

Hình 6.5: Kết quả đăng nhập 149

Hình 6.6: Tạo resource group 149

Hình 6.7: Kết quả tạo resource group 150

Hình 6.8: Lấy danh sách phiên bản 150

Hình 6.9: Kết quả lấy danh sách 151

Hình 6.10: Tạo Cluster 152

Hình 6.11: Kết quả tạo cluster 153

Hình 6.12: Xác nhận Cluster tồn tại 154

Hình 6.13: Kết quả xác nhận cluster tồn tại 154

Hình 6.14: Đặt AKS Cluster là context mặc định 155

Hình 6.15: Kết quả đặt AKS Cluster là context mặc định 155

Hình 6.16: Kiến trúc thư mục 156

Hình 6.17: Áp dụng cấu hình 157

Hình 6.18: Kết quả 157

DANH MỤC BẢNG

Bảng 4.1: Danh sách microservice của 4Pet 73

Bảng 4.2: Bảng nhiệm cụ thể của từng giai đoạn CI/CD trong 4pet sdk 98

Bảng 4.3: Bảng nhiệm vụ cụ thể từng giai đoạn ci/cd cho microservice 99

Bảng 5.1: Kiến trúc microservice 102

Bảng 5.2: Danh sách actor 104

Bảng 5.3: Danh sách use-case 105

Bảng 5.4: Đặc tả use-case login 106

Bảng 5.5: Đặc tả story 108

Bảng 5.6: Đặc tả use-case notification 109

Bảng 5.7: Đặc tả use-case chat 110

Bảng 5.8: Đặc tả use-case discover 111

Bảng 5.9: Đặc tả use-case profile 112

Bảng 5.10: Đặc tả use-case logout 113

Bảng 5.11: Mô tả bảng tài khoản 115

Bảng 5.12: Mô tả bảng người dùng 116

Bảng 5.13: Bảng mô tả tài khoản mạng xã hội 117

Bảng 5.14: Bảng thông tin người theo dõi 117

Bảng 5.15: Mô tả bảng media 119

Bảng 5.16: Mô tả bảng storage 120

Bảng 5.17: Bảng mô tả story 121

Bảng 5.18: Bảng mô tả bình luận 122

Bảng 5.19: Mô tả comment và media 123

Bảng 5.20: Mô tả bảng story_media 123

Bảng 5.21: Mô tả bảng notifications 125

Bảng 5.22: Bảng reaction service 125

Bảng 5.23: Bảng mô tả bảng reactions 126

Bảng 5.24: Mô tả bảng tin nhắn 128

Bảng 5.25: Mô tả của bảng hội thoại 128

DANH MỤC TỪ VIẾT TẮT

3 B2B Business to Business Doanh nghiệp với doanh nghiệp

4 B2C Business to Customer Doanh nghiệp với khách hàng

5 CDC Change data capture Thu thập thay đổi dữ liệu

6 CI/CD Continuous Integration /

Phân tách trách nhiệm truy vấn

8 gRPC Google remote

procedure call

Giao thức gọi thủ tục hàm từ xa được phát triển bởi Google

9 HTTP Hypertext Transfer

Protocol

Giao thức truyền tải siêu văn bản

14 Pub/sub Publisher/ subscriber Nhà xuất bản / người đăng ký

15 Rest API Representational state

transfer Application programming interface

Tiêu chuẩn thiết kế giao diện lập trình ứng dụng

16 SQL Structured Query

Language

Ngôn ngữ truy vấn có cấu trúc

17 STT Số thứ tự Số thứ tự trong bảng

18 UI User interface Giao diện người dùng

19 UX User Experience Trải nghiệm người dùng

TÓM TẮT KHÓA LUẬN

Khóa luận “Xây dựng mạng xã hội cho những người yêu thú cưng” nhằm mục đích xây dựng nên một mạng xã hội cho những người thích và yêu thú cưng Khóa luận bao gồm 8 chương:

Chương 1: Mở đầu: đặt vấn đề, lý do chọn đề tài, mục đích và phạm vi nghiên cứu của đề tài

Chương 2: Tổng quan: nêu ra hiện trạng bài toán mạng xã hội hiện tại đang gặp phải Nêu ra các vấn đề của mạng xã hội của thú cưng, đưa ra giải pháp giả định Phân tích, nghiên cứu thực trạng các mạng xã hội dành cho thú cưng đang có trên thị trường Tìm ra ưu điểm và khuyết điểm từ đó làm rõ vấn đề cần giải quyết, tổng quát hóa thành mục tiêu cần giải quyết trong khóa luận này

Chương 3: Cơ sở lý thuyết: liệt kê và giải thích rõ các thuật ngữ công nghệ, kỹ thuật

sẽ sử trong khóa luận này

Chương 4: Giải quyết vấn đề: Trình bày cụ thể phương pháp, giải thích về cách thức giải quyết bài toán gặp phải và công nghệ áp dụng

Chương 5: Phân tích thiết kế hệ thống: Đi chi tiết vào việc nghiên cứu và đưa ra kiến trúc cho hệ thống, kiến trúc cơ sở dữ liệu và thiết kế giao diện người dùng

Chương 6: Hướng dẫn triển khai và cài đặt hệ thống

Chương 7: Kết luận: đưa ra ý kiến về khóa luận

Chương 6: Hướng phát triển: nêu ra hướng phát triển của ứng dụng sau khi kết thúc khóa luận và tương lai của ứng dụng

Chương 1 MỞ ĐẦU

Ngày nay việc sở hữu cho mình một loại thú cưng là sở thích của rất nhiều người Sau những giờ làm việc mệt mỏi, việc tiếp xúc hay thậm chí ngắm nhìn hình ảnh của chúng thôi cũng mang lại nhiều lợi ích cho sức khỏe, đồng thời giúp cho ta giảm đi muộn phiền trong cuộc sống, khó khăn trong công việc Việc sở hữu thú cưng giúp những người già bớt cô đơn, tăng tuổi thọ và cải thiện chất lượng cuộc sống Những người trẻ ngày nay có xu hướng kết hôn muộn, họ lựa chọn nuôi thú cưng (chó hoặc mèo) để có người bầu bạn, tâm tình sau những giờ làm việc căng thẳng Chăm sóc thú cưng cũng là một cách rất tốt để trẻ nhỏ học biết cách chăm sóc, bồi dưỡng tình cảm Vì vậy, nhiều gia đình cũng lựa chọn nuôi thú cưng như những thành viên trong nhà

Trong thời điểm 2021 hiện tại, với sự phát triển mạnh của internet và cơ sở hạ tầng viễn thông, mạng xã hội phát triển một cách bùng nổ và ngày càng thể hiện được vị thế, vai trò của mình Facebook, TikTok, Youtube, Instagram, Twitter, LinkedIn, Reddit, là một trong những gã khổng lồ hiện tại trên thế giới, tại Việt Nam thì có Zalo, Mocha, Lotus, Gapo đã khẳng định được chỗ đứng và tầm ảnh hưởng nhất định Cộng đồng những yêu thú cưng tập trung phân tán và rải khắp các mạng xã hội theo kiểu hội, nhóm, kênh, do vậy nhu cầu chia sẻ, trải nghiệm, kết nối giữa những thành viên, giữa những người có cùng đam mê hết sức khó khăn Bên cạnh đó nhu cầu về quản lý, tương tác bài viết, hình ảnh, video, tài nguyên cũng rời rạc, khó kiểm soát Nhu cầu về một mạng xã hội thú cưng là rất thiết yếu trong nhu cầu hiện nay

4Pet ra đời với sứ mệnh là sân chơi chuyên biệt về tất cả mọi thứ liên quan đến thú cưng, hội tụ những người yêu thích thú cưng thành một cộng đồng lớn, chất lượng,

1.2 Mục đích

Học cách phân tích quy mô thị trường, đối thủ là ai, đặc điểm của những đối thủ là

gì, phân khúc, nhu cầu và đặc trưng của khách hàng

Xây dựng kế hoạch, các tính năng phù hợp để phát triển sản phẩm dựa trên thời gian thực hiện, chi phí, nguồn nhân lực

Xây dựng mạng xã hội dành cho những người yêu thú cưng theo phiên bản MVP (Minimum Viable Product) nhằm đánh giá, kiểm tra các giả thuyết đã đặt ra về thị trường, sản phẩm, các phản hồi của người dùng từ đó đưa ra quyết định về chiến lược phát triển sản phẩm tiếp theo

Rèn luyện khả năng phân tích nghiệp vụ, phát triển UI / UX, khả năng quản lý và vận hình quy trình phát triển phần mềm theo Agile / Scrum

Tiếp cận, xây dựng hệ thống back-end hiệu năng cao ứng dụng kiến trúc Microservices, CQRS (Command Query Responsibility Segregation)

Triển khai các giải pháp kỹ thuật và công nghệ như Change Data Capture (Kafka, Debezium), Message Queue (Kafka), Socket, SQL (Postgresql), NoSQL (MongoDB, Redis), Search Engine (Elasticsearch), HTTP2 (Google Protobuf - gRPC), Container (Docker),

Sử dụng Flutter - Dart để phát triển ứng dụng mobile, NodeJS, Kotlin, GraphQL dành cho API

Đóng gói, triển khai, quản lý và mở rộng các microservice bằng Kubernetes

Triển khai CI / CD với GitHub Actions

Sử dụng dịch vụ Google Cloud và Google Play Console

Những người sở hữu thú cưng, những người yêu thích, quan tâm đến thú cưng Tập trung vào những người có độ tuổi từ 15 - 40

Những người đã sử dụng Facebook, Instagram, TikTok hoặc các mạng xã hội tương

tự

Phạm vi địa lý:

● Tập trung chủ yếu vào người dùng ở Việt Nam

● Mở rộng ra các thị trường Philippines và Portugal

Phạm vi chức năng:

● Login with Facebook: đơn giản, nhanh chóng, bảo mật thông qua tài khoản Facebook

● Story: tương tác danh sách story của những người đang theo dõi

● Comment: bình luận story

● Reaction: “thả tim” (react) cho story, comment

● Discover: khám phá các story đang thịnh hành

● Notification: hệ thống thông báo theo thời gian thực, thông báo về hoạt động người dùng, bạn bè, story, comment, reaction

● Chat: hỗ trợ nhắn tin giữa bạn bè hoặc người lạ, cho phép gửi media (ảnh)

● Following: theo dõi bạn bè, người nổi tiếng để cập nhập các story, hoạt động của họ

● Profile: hiển thị thông tin người dùng, story, các hành động follow, unfollow, log out

Phạm vi kỹ thuật:

● Phát triển ứng dụng mobile multiple platform (Android & iOS) sử dụng Flutter

● Nghiên cứu và ứng dụng Message Queue (Kafka), Search Engine (Elasticsearch)

● Cải thiện tốc độ của GraphQL với HTTP2, gRPC

● Sử dụng NodeJS và Kotlin trong việc phát triển API hiệu năng cao

● Ảo hoá ứng dụng bằng Docker và triển khai hệ thống với Kubernetes

● Triển khai CI / CD với GitHub Actions

● Sử dụng dịch vụ Google Cloud và Google Play Console

Chương 2 TỔNG QUAN

Thị trường Việt Nam hiện nay có đến 43,7 triệu người đang sử dụng các thiết bị smartphone trên tổng dân số 97,4 triệu dân, đạt tỷ lệ 44,9% Những con số này cũng giúp Việt Nam lọt vào top 15 thị trường có số lượng người dùng smartphone cao nhất thế giới

72% dân số Việt Nam xài smartphone nhưng 50% trong số đó chỉ nghe gọi nhắn tin

• 72% dân số Việt Nam đang dùng điện thoại thông minh, 68% người Việt xem video và nghe nhạc mỗi ngày trên thiết bị di động, có nhiều người cùng lúc sử dụng hơn 2 chiếc điện thoại với tỷ lệ sở hữu máy trung bình là 1,7 máy/người Nhiều người Việt lên mạng bằng điện thoại nhiều hơn cả máy tính, con số cụ thể là 68%

• Về ứng dụng, thống kê có thấy người Việt thích trải nghiệm ứng dụng mới, trung bình mỗi người cài 5 ứng dụng mới mỗi tháng, nhưng cũng hay gỡ cài đặt, trung bình xóa 3 ứng dụng mỗi tháng, tỷ lệ cao nhất châu Á Thái Bình Dương

• Hiện nay, tại Việt Nam có 70% các thuê bao di động đang sử dụng Internet

từ 3G hoặc 4G với tốc độ trung bình là 14,6 Mbps

Người Việt Nam dành 4 giờ 30 phút cho các nền tảng mạng xã hội Số liệu cho thấy 1/5 dân số (19%) dành hơn 7 giờ mỗi ngày để kiểm tra tài khoản mạng xã hội,

so với 2% những người lên mạng dưới 30 phút

Nghiên cứu của cho thấy rằng Facebook là nền tảng được dùng nhiều nhất ở Việt Nam, với trên 8/10 (86%) số người sử dụng ứng dụng này ít nhất một lần mỗi tuần

2.2 Tổng quan thị trường thú cưng

Theo số liệu thống kê của cục thú y, từ năm 2019 đến nay trên cả nước có trên 5 triệu hộ dân nuôi chó, mèo Đạt 18.58 % trên tổng số hộ dân Cho thấy thị trường thú cưng ở việt nam rất tiềm năng

Như chúng ta thấy, hiện tại các mặt hàng cho thú cưng như đồ ăn, thức uống, đồ chơi cho thú cưng ngày càng phổ biến và đa dạng hơn Các cửa hàng spa cho thú cưng cũng xuất hiện, cùng với các dịch vụ khác cho thú cưng đang tăng mạnh Đây là dấu hiệu tốt báo hiệu tốt về một thị trường thú cưng đầy tiềm năng

Tại Việt Nam, các ý tưởng ứng dụng mạng xã hội cho thú cưng còn khá là non trẻ, chưa thể khai phá hết tiềm năng của thị trường, nhu cầu của người dùng, tuổi đời của các dự án này khá là trẻ Theo 4Pet điều tra, có thể phân loại theo mô hình kinh doanh như sau:

• B2B: tập trung vào việc liên kết càng nhiều dịch vụ bên thứ ba dành cho thú cưng bao gồm y tế, làm đẹp, giả trí, ăn uống Việc liên kết ồ ạt các dịch

vụ mà không thu hút đủ số lượng khách hàng khiến cho việc mở rộng, bao quát thị trường khó khăn Bởi lẽ, nhu cầu chủ yếu của người dùng là tập trung vào giải trí thay vì là sử dụng dịch vụ thường xuyên

• B2C: ưu tiên tiếp cận người dùng cuối, tập trung vào câu chuyện nâng cao

và cải thiện trải nhiệm và nhu cầu người dùng để thực hiện đồng thời hai nhiệm vụ là tìm kiếm khách hàng mới và giữ chân khách hàng cũ Hướng tiếp cận này, có thể giải thích nôm na là tìm kiếm và xây dựng một lượng khách hàng ổn định Sau đó, mới triển khai khai thác dịch vụ Do vậy, dự

án cần một thời gian dài và chi phí lớn để xây dựng tập khách hàng Tuy nhiên, khi bước vào giai đoạn khai thác và triển khai dịch vụ, hướng đi này thể hiện ưu thế về sự am hiểu tập khách hàng, dễ dàng thử nghiệm, tích hợp dịch vụ mới

Cả B2B và B2C đều có những ưu và khuyết điểm riêng, 4Pet cho rằng nếu có một chiến lược tiếp cận thị trường và khai thác người dùng đúng đắn thì cả hai sẽ đạt được những thành công nhất định 4Pet chọn cách tiếp cận theo hướng B2C, bởi

lẽ một số vấn đề về nguồn lực tài chính, nhân sự, chiến lược 4Pet tập trung vào câu chuyện xây dựng phiên bản MVP để thực sự chắc chắn ý tưởng, các giả thuyết

về thị trường người dùng là đúng hay sai, từ đó, đưa ra được những giải pháp để cải tiến, thích nghi với nhu cầu của người dùng

Dự án 4Pet, tiếp cận người dùng với phương châm: “4Pet yêu thú cưng, thú cưng yêu 4Pet”

Định hướng phát triển của 4Pet trong tương lai bao gồm các giai đoạn:

• Giai đoạn 1: Phát triển phiên bản MVP

• Giai đoạn 2: Triển khai B2C

• Giai đoạn 3: Triển khai B2B

Nhóm tập trung giải quyết hai vấn đề chính:

• Xây dựng phiên bản MVP đáp ứng các nhu cầu cơ bản của một mạng xã hội giải trí dành cho thú cưng

• Xây dựng hệ thống hiệu năng cao, tốc độ, ổn định, dễ mở rộng, tích hợp, triển khai 4Pet cần đi xa hơn sau khoá luận nên yêu cầu về hệ thống rất nghiêm ngặt, khắt khe nhằm đảm đảo hệ thống dễ dàng mở rộng, phát triển sau này

2.5.1 Xây dựng phiên bản MVP

Các tính năng cơ bản của một mạng xã hội giải trí như: tạo và tương tác Story, Comment, Reaction, tính năng Chat, Notification, Profile, Following, Discover, Trending, Report, Block,

Các yêu cầu cần đáp ứng như: tốc độ upload image, video, hỗ trợ CDN cho media(image, video), realtime cho Notification và Chat, giao diện đơn giản, dễ sử dụng,

2.5.2 Xây dựng hệ thống hiệu năng cao, dễ dàng mở rộng

4Pet chỉ xây dựng phiên bản MVP về mặt tính năng, về mặt hệ thống 4Pet muốn xây dựng một nền móng vững chắc để phục vụ nhu cầu nâng cao, khắc nghiệt trong tương lai

Các vấn đề cần nghiên cứu và áp dụng bao gồm:

• Hệ thống Microservices hiệu năng cao với NodeJS, gRPC, GraphQL

• Áp dụng Kafka vào hệ thống realtime

• Ứng dụng giải pháp Change Data Capture

• Sử dụng Elasticsearch nhằm cải thiện tốc độ và hiệu suất search data

• Cải thiện tốc độ search của Elasticsearch với Kafka Stream

• Triển khai hệ thống lên cloud với Kubernetes

• Hoàn thiện quy trình CI/CD

Chương 3 CƠ SỞ LÝ THUYẾT

Tuy nhiên một MVP chất lượng cần phải có đầy đủ tính năng tối thiểu, đáp ứng được hiệu quả nhu cầu của người dùng, khiến cho người dùng muốn mua sản phẩm chính thức của bạn khi ra mắt

Có thể hình dung MVP qua hình minh họa bên dưới

Với mục đích cung cấp thiết bị với tính năng di chuyển, MVP không phải

là việc phát hành từng bộ phận của một chiếc ô tô cho người dùng

MVP cần là thiết bị cung cấp tính năng di chuyển với thiết kế tối thiểu nhất, như trong ví dụ trên là chiếc ván trượt

3.1.1.2 Ý nghĩa của MVP

MVP sẽ giúp bạn nghiên cứu nhu cầu thị trường, kiểm tra các giả thiết bạn đặt ra Nếu thành công bạn có thể bắt đầu các bước tiếp theo của dự án, bổ sung nhân lực cho các thử nghiệm tiên tiến hơn, cao cấp hơn Cứ như vậy sản phẩm của bạn sẽ liên tục được nâng cấp, cải tiến và có thêm người dùng

Với một MVP, bạn có thể khẳng định ý tưởng của bạn, hợp lệ hóa sản phẩm của bạn, mọi người sẽ biết bạn là người đầu tiên nghĩ ra nó

MVP giúp bạn nhận được phản hồi từ người dùng Khi bạn theo dõi và phân tích các dữ liệu này, bạn có thể sửa lỗi, thêm các tính năng, cải thiện sản phẩm cuối cùng cũng như xây dựng một cơ sở người dùng trung thành sau này cho sản phẩm

3.1.2 Agile và Scrum

3.1.2.1 Tổng quan về Agile

Agile là một phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt càng sớm càng tốt

“Tuyên ngôn Phát triển phần mềm linh hoạt” (“Manifesto for Agile Software Development” – gọi tắt là “Tuyên ngôn Agile”) đưa ra các giá trị cốt lõi nhất mà toàn bộ các nhà lý thuyết cũng như những người thực hành Agile phải tuân thủ Toàn văn Tuyên ngôn Agile như sau:

● Cá nhân và sự tương hỗ quan trọng hơn quy trình và công cụ

● Sản phẩm dùng được quan trọng hơn tài liệu về sản phẩm

● Cộng tác với khách hàng quan trọng hơn đàm phán hợp đồng

● Phản hồi với sự thay đổi quan trọng hơn bám theo kế hoạch

Tính lặp (Iterative) Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary) Tính thích ứng (hay thích nghi – adaptive)

Nhóm tự tổ chức và liên chức năng Quản lý tiến trình thực nghiệm (Empirical Process Control) Giao tiếp trực diện (face-to-face communication)

Phát triển dựa trên giá trị (value-based development)

3.1.2.2 Tổng quan về Scrum

Scrum là một khung làm việc trong đó con người có thể xác định các vấn

đề thích nghi phức hợp, trong khi vẫn giữ được năng suất và sáng tạo để chuyển giao các sản phẩm có giá trị cao nhất

Scrum được xây dựng dựa trên lý thuyết quản lý tiến trình thực nghiệm

(iterative), tăng trưởng (incremental) để tối ưu hóa tính khả đoán (predictability) và kiểm soát rủi ro

Ba yếu tố nòng cốt tạo thành một mô hình quản lý tiến trình thực nghiệm gồm: sự minh bạch (transparency), thanh tra (inspection) và thích nghi (adaptation)

Nhóm Scrum bao gồm Product Owner (Chủ Sản phẩm), Nhóm phát triển (Development Team) và Scrum Master Các Nhóm Scrum là các nhóm tự quản (self-organizing) và liên chức năng (cross-functional) Các nhóm tự quản tự mình chọn cách thức tốt nhất để hoàn thành công việc của họ, chứ không bị chỉ đạo bởi ai đó bên ngoài nhóm Các nhóm liên chức năng có đủ kỹ năng cần thiết để hoàn thành công việc mà không phụ thuộc vào bất kì người ngoài nào khác Mô hình nhóm trong Scrum được thiết kế để tối ưu hóa sự linh hoạt, sáng tạo và năng suất

Các sự kiện trong Scrum tạo ra thói quen và để giảm thiểu những buổi họp hành vốn không được định nghĩa trong Scrum Scrum dùng các sự kiện được đóng khung thời gian (time-boxed), nghĩa là mỗi sự kiện có giới hạn thời gian tối đa Điều này đảm bảo thời lượng vừa đủ để tránh lãng phí thời gian không cần thiết cho sự kiện

Bao gồm cả bản thân Sprint vốn chứa tất cả các sự kiện khác, mỗi sự kiện trong Scrum là một cơ hội chính thức để thực hiện cơ chế thanh tra và thích nghi Các sự kiện này được thiết kế đặc biệt để đảm bảo sự minh bạch và thanh tra Nếu không thực hiện được các điều này có thể dẫn đến giảm thiểu tính minh bạch và đánh mất cơ hội để thanh tra và thích nghi

3.1.2.2.4 Tạo tác Scrum

Các tạo tác Scrum (artifact) hiển thị các công việc hoặc các giá trị bằng nhiều cách hữu ích để cung cấp tính minh bạch cũng như các cơ hội cho việc thanh tra và thích nghi Các tạo tác Scrum được thiết kế để tối

đa hóa tính minh bạch và thông suốt của các thông tin chính yếu nhằm đảm bảo mọi người có cùng cách hiểu thống nhất

Khi một hạng mục Product Backlog hoặc một Gói tăng trưởng được cho là “Hoàn thành”, mọi người phải hiểu rõ “Hoàn thành” như thế nghĩa là thế nào Mặc dù việc xác định rõ định nghĩa này hoàn toàn phụ thuộc vào từng Nhóm Scrum, nhưng mọi thành viên phải chia sẻ chung một cách hiểu về việc hoàn thành một công việc, để đảm bảo tính minh bạch và thông suốt Đây chính là “Định nghĩa Hoàn thành” (Definition

of Done) cho Nhóm Scrum nó được dùng để đánh giá khi nào công việc thực sự hoàn thành trên mỗi gói tăng trưởng của sản phẩm

3.1.3 Quản lý dự án với Trello

Trello là một trong những ứng dụng quản lý dự án nổi tiếng và được sử dụng nhiều nhất Nó có cả tài khoản miễn phí và cao cấp mang đến cho bạn cơ hội tuyệt vời để sử dụng hầu hết các chức năng phổ biến

Cấu trúc của Trello dựa trên phương pháp kanban Tất cả các dự án được đại diện bởi các bảng, có chứa danh sách Mọi danh sách đều có các thẻ lũy tiến

mà bạn được tạo dưới dạng kéo và thả Người dùng có liên quan đến bảng, có thể được gán cho thẻ

Tóm lại, nó có nhiều tính năng hay, nhỏ nhưng không kém phần hữu ích: viết bình luận, chèn tệp đính kèm, ghi chú, ngày đáo hạn, danh sách kiểm tra, nhãn màu, tích hợp với các ứng dụng khác, Ngoài ra, Trello được hỗ trợ bởi tất cả các nền tảng di động Trello là công cụ có thể được sử dụng cho cả công việc

3.2.2 Google Play Console

Cũng giống như AppStore, thì Google Play Store là market chính thống và có

nhiều người dùng nhất trên Android Do đó để ứng dụng của bạn được nhiều

người biết đến và có thể kiếm được thu nhập thì bạn cần đưa ứng dụng lên chợ

CHPlay Google play console là bản điều khiển dành cho các nhà phát triển,

giúp cho nhà phát triển dễ dàng quản lý liên quan tới việc phân phối ứng dụng

Hình 3.3: Kiến trúc Monolithic

3.3.1.1.2 Ưu điểm

Có cách phát triển đơn giản: Dự án theo kiểu monolithic thì mọi thứ đều tập trung tại một chỗ, việc setup môi trường để code cũng như code thêm cho dự án sẽ diễn ra nhanh chóng và đơn giản Đơn giản ở đây là đơn giản hơn kiến trúc microservice mà mình sắp giới thiệu ở phần dưới, chứ chúng ta đều biết rằng phát triển phần mềm là công việc chẳng hề đơn giản cho dù sử dụng kiến trúc nào đi nữa

Dễ dàng deploy: Với monolithic dự án được đóng gói thành một cục gọn gàng, nhờ đó mà quá trình deploy cũng dễ dàng Nhưng cũng như tiêu chí trước, nó chỉ đơn giản hơn microservice thôi

Hệ thống được xây dựng dựa trên một công nghệ: Do kiến trúc nguyên khối, nên phần mềm triển khai theo cấu trúc này sẽ chỉ giới hạn trong một số công nghệ nhất định, bạn không cần phải hiểu biết quá nhiều để làm việc với phần mềm tuân theo kiến trúc này Tiêu chí này đôi khi cũng là nhược điểm, cụ thể mình sẽ trình bày ở phần nhược điểm bên dưới

Một tính năng thay đổi là coi như cả thống thay đổi: Theo kiến trúc monolithic thì dự án của bạn được chia thành bao nhiêu module, có cấu trúc linh hoạt đến mấy thì bản chất nó vẫn là nguyên khối Nên khi một tính năng thay đổi thì coi như là cả hệ thống thay đổi, hay nói cách khác

là phần mềm triển khai theo kiến trúc monolithic sẽ thường xuyên bị thay đổi Việc thường xuyên thay đổi sẽ khiến bạn phải deploy lại nhiều lần, trong lúc deploy ít nhiều gì hệ thống cũng sẽ bị tạm dừng Vậy nếu

Càng lâu thì dự án càng cồng kềnh: Theo thời gian, các tính năng sẽ

“tích tiểu thành đại” gây khó khăn trong việc nắm bắt business logic, khó khăn trong việc bảo trì

Giới hạn công nghệ: Vì chỉ được xây dựng trong một số công nghệ nhất định, nên các tính năng sẽ bị giới hạn trong phạm vi công nghệ đó Ví

dụ bạn có một sản phẩm làm bằng PHP, thì sẽ khó làm các tính năng realtime (thời gian thực) hay bất đồng bộ

3.3.1.2 Kiến trúc Microservice

Microservice là kiến trúc có triết lý thiết kế ngược lại hoàn toàn so với kiến trúc monolithic nêu trên Thay vì gom tất tần tật tính năng vào trong một dự án, microservice chia dự án thành nhiều service nhỏ Các service trong kiến trúc microservice là độc lập với nhau, chúng có thể có kiến trúc khác nhau, sử dụng công nghệ khác nhau hoặc thậm chí có database riêng Chúng trao đổi thông tin với nhau thông qua môi trường mạng (có thể bằng endpoint Restful API hoặc các Message Queue)

Một trong những điều cực kỳ quan trọng giữa các service trong kiến trúc microservice là chúng phải hiểu nhau đang “nói” gì Để làm được điều này, buộc các developer phải thống nhất trước cách mà chúng sẽ giao tiếp với nhau như: giao tiếp qua phương thức nào (restful API hay message queue), kiểu dữ liệu nào (JSON hay XML), cấu trúc dữ liệu ra sao…