Hệ thống xây dựng Chatbot theo kịch bản

Trong thời đại bùng nổ về mạng internet và thông tin như ngày nay, nhu cầu giao tiếp giữa người với người ngày càng gia tăng, mô hình bán hàng trực tuyến ngày càng cho thấy sự hiệu quả và vượt trội so với hình thức bán hàng truyền thống là: người mua phải đến tận nơi cửa hàng để mua hàng. Đây chính điều kiện thuận lợi cho lĩnh vực thương mại điện tử ngày càng phát triển hơn. Hiện nay, Thương mại điện tử đã trở thành một phương tiện giao dịch quen thuộc của các công ty thương mại lớn trên thế giới. Thương mại điện tử có khả năng giúp ích rất nhiều cho những doanh nghiệp cả lớn lẫn nhỏ và người hưởng lợi nhất thường là khách hàng. Khách hàng sẽ mua được sản phẩm rẻ hơn, nhanh hơn, hiệu quả hơn và thuận lợi hơn, còn doanh nghiệp có thể đưa sản phẩm của mình đến với thị trường một cách nhanh nhất, thuận lợi hơn và tiết kiệm chi phí cho marketing hay mặt bằng

VẤN ĐỀ VÀ ĐỊNH HƯỚNG GIẢI PHÁP

Đặt vấn đề

1.1.1 Xu thế của doanh nghiệp trong thời đại công nghệ

Trong thời đại bùng nổ về mạng internet và thông tin như ngày nay, nhu cầu giao tiếp giữa người với người ngày càng gia tăng, mô hình bán hàng trực tuyến ngày càng cho thấy sự hiệu quả và vượt trội so với hình thức bán hàng truyền thống là: người mua phải đến tận nơi cửa hàng để mua hàng Đây chính điều kiện thuận lợi cho lĩnh vực thương mại điện tử ngày càng phát triển hơn Hiện nay, Thương mại điện tử đã trở thành một phương tiện giao dịch quen thuộc của các công ty thương mại lớn trên thế giới Thương mại điện tử có khả năng giúp ích rất nhiều cho những doanh nghiệp cả lớn lẫn nhỏ và người hưởng lợi nhất thường là khách hàng Khách hàng sẽ mua được sản phẩm rẻ hơn, nhanh hơn, hiệu quả hơn và thuận lợi hơn, còn doanh nghiệp có thể đưa sản phẩm của mình đến với thị trường một cách nhanh nhất, thuận lợi hơn và tiết kiệm chi phí cho marketing hay mặt bằng.

Từ những xu hướng đó, khả năng chăm sóc khách hàng của chủ doanh nghiệp trên website là rất quan trọng Thông qua quá trình chăm sóc khách hàng này, doanh nghiệp có thể thu thập được những khách hàng tiềm năng, hiểu được thị hiếu khách hàng và thông qua đó nắm bắt xu thế thị trường Chatbot ra đời như một xu thế tất yếu để giúp doanh nghiệp tự động hóa công việc chăm sóc khách hàng, thay thế một phần sức lao động con người Trong đó, Chatbot là các ứng dụng (application) hay nền tảng (platform) được thiết kế để giao tiếp với người dùng Internet bằng giọng nói hoặc văn bản như người thật.

Nhiệm vụ của đồ án này là xây dựng một hệ thống xây dựng chatbot cho phép người chủ doanh nghiệp thiết kế, quản lý và xây dựng bot để tăng khả năng chăm sóc khánh hàng, thu thập được nhiều khách hàng tiềm năng mà vẫn giảm được sức lao động của con người.

Chatbot là các ứng dụng hay nền tảng được thiết kế để giao tiếp với người dùng Internet bằng giọng nói hoặc văn bản như người thật Chatbot thường được tích hợp vào các trang web, mạng xã hội, ứng dụng di động, hay tài khoản nhắn tin v.v.

Trong ngành dịch vụ khách hàng, hay cụ thể hơn trong việc hỗ trợ quyết định của người mua, việc sử dụng chatbot đã thay đổi mạnh mẽ trải nghiệm của khách hàng Mục đích của việc sử dụng Chatbot trong kinh doanh là hỗ trợ doanh nghiệp kết giao được với không chỉ khách hàng hiện tại, mà còn cả những khách hàng tiềm năng Khách hàng có thể đưa ra yêu cầu về sản phẩm và dịch vụ của bạn ngay cả những thời điểm bạn không có mặt trực tuyến Chatbot có thể thay bạn thu thập thông tin khách hàng, quảng cáo sản phẩm Có thể nói rằng Chatbot đã trở thành một dịch vụ không còn lạ lẫm gì với các doanh nghiệp Chỉ bắt đầu từ thiết lập dựa trên các câu lệnh đơn giản, Chatbot nay đã được phát triển "thông minh" hơn rất nhiều Các công ty ở nhiều ngành nghề, điển hình như ngành thương mại điện tử, khách sạn, dịch vụ khách hàng, hay các tổng đài chăm sóc khách hàng đều đã cải thiện dịch vụ của họ và tăng doanh thu nhờ việc tích hợp các Chatbot Nhờ Chatbot, các thương hiệu đã gia tăng tỷ lệ khách hàng trung thành của mình

Có thể phân loại Chatbot dựa theo dịch vụ khách hàng gồm Chatbot bán hàng và Chatbot chăm sóc khách hàng nhưng nếu phân loại dựa trên chất lượng trải nghiệm người dùng thì có thể chia Chatbot làm ba loại: Chatbot theo kịch bản, Chatbot nhận dạng từ khóa và Chatbot theo ngữ cảnh [1]:

 Chatbot theo kịch bản: Trong hầu hết các trường hợp, các Chatbot này là các hệ thống phân cấp cây quyết định được trình bày cho người dùng dưới dạng các nút (node) Tương tự như một menu với các lựa chọn hay như một chiếc điều khiển tivi, các chatbot này yêu cầu người dùng thực hiện một số lựa chọn để đào sâu hơn về phía câu trả lời cuối cùng.

 Chatbot nhận dạng từ khóa : các Chatbot dựa trên nhận dạng từ khóa có thể lắng nghe những gì người dùng gõ và trả lời một cách thích hợp.Những Chatbot sử dụng các từ khóa tùy biến và AI để xác định làm thế nào để đưa ra câu trả lời thích hợp cho người dùng. hiểu và phát triển theo thời gian Không giống như các chatbot nhận dạng từ khóa, các Chatbot trò chuyện theo ngữ cảnh đủ thông minh để tự cải thiện dựa trên những gì người dùng yêu cầu và cách họ yêu cầu

Mục tiêu của đồ án này là xây dựng một hệ thống cho phép người dùng có thể thiết kế, quản lý và xây dựng Chatbot theo kịch bản Cụ thể các mục tiêu chính của đề tài:

1 Tìm hiểu công nghệ Docker, tìm hiểu công nghệ vận hành các Docker Container là Kubernetes (k8s).

2 Tìm hiểu về hệ quản trị cơ sở dữ liệu phân tán Cassandra, công nghệ dùng cho MessageQueue là Apache Kafka, giao thức gRPC.

3 Thiết kế, xây dựng, cài đặt môi trường chạy bot.

4 Thiết kế, xây dựng, cài đặt các hành động (action) cho Chatbot.

5 Thử nghiệm và đánh giá hiệu năng hệ thống.

Xây dựng một hệ thống cho phép người dùng thiết kế, quản lý và xây dựng Chatbot theo kịch bản trong đó người dùng xây dựng kịch bản và điều kiện kích hoạt Bot

Khi người dùng vào website, hệ thống sẽ kiểm tra các điều kiện kích hoạt của tất cả Bot Khi điều kiện kích hoạt của một kịch bản bot nào đó khớp thì cửa sổ chat trên website sẽ bật lên, đồng thời gửi request đến service Chatbot để kích hoạt bot Từ đối tượng Bot sẽ khởi chạy Bot thực thi, Bot thực thi là một thể hiện (instance) của đối tượng Bot Bot thực thi sẽ tiến hành khởi chạy cây hành động từ Bot, từ cây hành động sẽ thực thi lần lượt các hành động (action) của Bot.

1.1.6 Một số hệ thống xây dựng Chatbot theo kịch bản a NovaonX

NovaonX [20] là một đơn vị cung cấp dịch vụ chat trực tuyến dựa trên nền tảng Saas (Software as a Service) Chatbot của NovaonX cung cấp cho người dùng khả năng xây dựng, quản lý Chatbot theo kịch bản với mục đích hỗ trợ doanh nghiệp bán hàng tự động, tự động hóa quá trình chăm sóc khách hàng.Tuy nhiên Chatbot của NovaonX còn một số hạn chế như: chỉ tích hợp được trên kênh fanpage của Facebook, giao diện rườm rà không thân thiện với người dùng Người dùng phải mất một khoảng thời gian lớn để có thể làm quen hệ thống và tự thiết lập cho mình một kịch bản Bot hoàn chỉnh. b Tidio

Không giống như NovaonX là một đơn vị của Việt Nam, Tidio [21] là một đơn vị cung cấp dịch vụ chat trực tuyến đa kênh của nước ngoài Ngoài việc cung cấp dịch vụ chat trực tuyến, Tidio còn cung cấp tính năng quản lý và xây dựng Chatbot theo kịch bản Chatbot của Tidio là một tính năng thân thiện với người sử dụng với giao diện đẹp mắt, người dùng có thể dễ dàng thiết lập một kịch bản Bot mà không phải tốn quá nhiều công sức Ngoài ra Tidio còn cung cấp tính năng thử kịch bản Bot để người dùng dễ dàng kiểm tra và tinh chỉnh kịch bản Bot phù hợp với trải nghiệm khách hàng Tuy nhiên, khi người dùng sử dụng tính năng này, hệ thống sẽ bật lên một trình duyệt mới chỉ với mục đích cho người dùng thử kịch bản Bot Điều này là không cần thiết và làm giảm trải nghiệm của khách hàng Đồ án tập trung vào việc xây dựng một hệ thống Chatbot có hiệu năng lớn,vận hành bền bỉ, cũng như đảm bảo trải nghiệm tốt cho người dùng, kế thừa những điểm tốt và khắc phục những điểm chưa tốt của các hệ thống đi trước.

Giải pháp thực hiện

1.2.1 Giới thiệu nền tảng chat trực tuyến Subiz

Subiz là đơn vị cung cấp dịch vụ chat trực tuyến đa kênh (cửa sổ chat trên website, facebook, zalo) dựa trên nền tảng SaaS (Software as a Service) Trong đó mỗi đơn vị tương ứng là chủ doanh nghiệp, chủ website sử dụng dịch vụ thông qua một tài khoản (gọi là account) Trong mỗi account có một chủ tài khoản (gọi là account owner), chủ tài khoản có quyền quản lý, thêm, sửa, xóa tư vấn viên trực chat (gọi là agent) Agent là thành phần chính của hệ thống, là người quản lý các cuộc chat (conversation) của người dùng (user) đổ về trang quản trị (dashboard) User là những người cung cấp cuộc chat với tư vấn viên thông qua cửa sổ chat, chỉ những đã tương tác với cửa sổ chat mới được gọi là user.

(agent) trong việc chăm sóc khách hàng, tiếp cận khách hàng tiềm năng, thu thập thông tin khách hàng, giảm sức lao động của con người Hệ thống Chatbot được mong đợi sẽ vận hành liên tục và bền bỉ để đáp ứng trên một triệu user mỗi ngày (> 1.000.000 users/day) và 10000 request trong lúc cao điểm (> 10.000 requests/s).

1.2.2 Giới thiệu Chatbot a Giới thiệu Chatbot theo kịch bản

Chatbot theo kịch bản là các hệ thống phân cấp cây quyết định được trình bày cho người dùng dưới dạng các nốt (nodes) Tương tự như một menu với các lựa chọn hay như một chiếc điều khiển tivi, các Chatbot này yêu cầu người dùng thực hiện một số lựa chọn để đào sâu hơn về phía câu trả lời cuối cùng Trong đó, câu trả lời hay phản hồi cho hành động trên sẽ dẫn tới quyết định hành động nào tiếp theo được thực thi Càng đào sâu hơn kịch bản của Chatbot, người bán càng thu thập được nhiều thông tin của khách hàng Do đó, việc thiết kế kịch bản Chatbot là công việc rất quan trọng ảnh hưởng tới hiệu quả của Chatbot Kịch bản phải được thiết kế sao cho phù hợp với hai tiêu chí: thân thiện với khách hàng để không gây cảm giác khó chịu, làm phiền hay mất lịch sự với khách hàng, hai là thu thập được tối đa thông tin hoặc thông tin phù hợp với yêu cầu đặt ra của doanh nghiệp Cài đặt điều kiện kích hoạt Chatbot cũng rất quan trọng trong việc tiếp cận đối tượng khách hàng phù hợp.

Các tư vấn viên (agent) là người triển khai kịch bản hoạt động cũng như điều kiện kích hoạt Chatbot Tư vấn viên có thể sử dụng template kịch bản được dựng sẵn theo đặc thù từng ngành nghề: ví dụ Tư vấn xe hơi, tư vấn công nghệ, tư vấn mỹ phẩm v.v hoặc tự thiết kế kịch bản để phù hợp với đặc thù, yêu cầu của doanh nghiệp.

Hình 1.1: Hệ thống cây phân cấp quyết định

Trên hình 1.1 là hệ thống cây phân cấp quyết định của Chatbot Trong đó mỗi hành động là một nút (node) của cây Mỗi cạnh của cây có thể chứa điều kiện (condition), câu trả lời hay phản hồi của hành động trên nếu khớp với điều kiện nào sẽ quyết định hành động tiếp theo được thực thi Nếu không khớp với bất kì điều kiện nào của các nút con, nút con trái nhất phù hợp sẽ được chọn là hành động tiếp theo b Một số thuật ngữ được sử dụng

 Bot: người máy, có nhiệm vụ cũng như khả năng trả lời tin nhắn của khách hàng và thực hiện các công việc khác (gửi câu hỏi, gửi email, gắn nhãn cuộc hội thoại, đóng cuộc hội thoại, ).

 Trigger: điểm bắt đầu kích hoạt của bot Khi thỏa mãn các điều kiện trigger, bot sẽ xuất hiện và thực hiện công việc của mình.

 Condition: điều kiện kích hoạt hành động tiếp theo Mỗi hành động có thể có điều kiện kích hoạt, phản hồi của hành động phía trên sẽ là tín hiệu để bắt đầu hành động kế tiếp của nó c Điều kiện trigger

Trigger là điều kiện kích hoạt của Chatbot, khi đáp ứng đủ điều kiện của một Bot nhất định, nếu Bot đó đang trong trạng thái hoạt động, lập tức Bot được kích hoạt và tham gia cuộc hội thoại với người dùng.

 Trigger vào thời điểm nào

+ Khách xem trang (website): Bot thực hiện cuộc chat ngay thời điểm khách hàng truy cập vào website.

+ Khách gửi tin nhắn: Bot thực hiện trả lời cuộc chat khi khách hàng gửi tin nhắn vào cửa sổ chat trên website.

+ Khách có ý định thoát web: khi khách hàng kéo chuột chéo màn hình từ góc trái sang góc phải màn hình, hệ thống sẽ nhận định rằng khách hàng có định nhấn vào biểu tượng tắt trang, khi đó cửa sổ chat sẽ bật lên và Chatbot sẽ gửi tin nhắn cho khách hàng.

+ Khi click vào một vị trí cụ thể trên website: khi khách hàng click vào một thẻ html cụ thể trên website.

+ Sau khi cuộn chuột x% trên website: sau khi khách hàng vào website và cuộn chuột x% trên độ dài trang web.

+ Sau thời gian x giây trên trang: sau khi khách hàng vào website một khoảng thời gian nhất định trên website.

+ Sau x giây trên website nhưng không hoạt động: sau khi khách hàng vào website nhưng không có hoạt động gì trong một khoảng thời gian nhất định

 Trigger với đối tượng nào:

+ Khách mới vào website: khách hàng lần đầu vào trang là khi session không ghi nhận thấy có lần truy cập trước.

+ Khách quay lại website: khách hàng quay lại website là khi session có ghi nhận thấy lần truy cập trước.

+ Vị trí địa lý của khách: có thể cài đặt điều kiện kích hoạt quốc gia, thành phố nhất định hoặc loại trừ quốc gia, thành phố nào đó Cài đặt mặc định là kích hoạt với tất cả quốc gia, lãnh thổ trên thế giới.

+ Thiết bị của khách: có thể là máy tính, điện thoại hay tablet.

+ Trình duyệt web của của khách hàng: có thể là Google chrome, Mozilla Firefox, Internet Explorer, Safari hoặc Microsoft Edge.

+ Thông tin khách hàng (user): bot kích hoạt với người dùng có thông tin nhất định như email, số điện thoại, tên, v.v.v

+ Ngày trong tuần: bot kích hoạt với ngày cụ thể trong tuần

VD: Kích hoạt vào thứ bảy, chủ nhật, không kích hoạt trong các ngày còn lại.

+ Giờ trong ngày: bot kích hoạt với giờ cụ thể trong ngày.

VD: Kích hoạt vào ban đêm từ 19h đến 7h sáng hôm sau.

+ Ngày cụ thể: kích hoạt với ngày được chỉ định cụ thể. d Các hành động (action) trong Chatbot

 Hành động gửi tin nhắn:

+ Mô tả hành động: Gửi 1 tin nhắn bất kì đến user.

+ Tính năng của hành động : o Có thể gửi nhiều tin nhắn. o Có thể đính kèm ảnh, video, file âm thanh, file văn bản. o Đính kèm biến thuộc tính của user trong tin nhắn.

VD: Chúng tôi sẽ liên hệ với bạn qua địa chỉ email {user.email} => Chúng tôi sẽ liên hệ với bạn qua địa chỉ email nhthong.268@gmail.com. o Chờ khách phản hồi: có thể chờ phản hồi của user để bắt đầu hành động tiếp theo, nếu trường này bỏ trống thì sau khi thực hiện gửi tin nhắn sẽ bắt đầu hành động kế tiếp.

Hình 1.2: Hành động gửi tin nhắn

 Hành động hỏi câu hỏi:

+ Mô tả hành động: Gửi 1 câu hỏi bất kì đến người dùng, nhận tin nhắn phản hồi của người dùng và lưu trường thông tin cần thiết vào hệ thống.

+ Tính năng của hành động: o Có thể gửi nhiều tin nhắn. o Có thể gửi kèm ảnh, video, file âm thanh, file văn bản. o Định dạng phản hồi : thực hiện xác nhận các trường thông tin trong phản hồi của người dùng (theo email, số điện thoại, theo ngày, theo số, theo link url, ). o Lưu thông tin thu được vào biến user: Sau khi bóc tách và lấy được các thông tin cần thiết của người dùng (user), hệ thống cập nhật những thông tin này vào thông tin người dùng. o Bỏ qua hành động nếu đã có thông tin: Nếu trường thông tin được hỏi đã tồn tại trong dữ liệu thông tin user thì bỏ qua hành động hỏi này, chuyển sang hành động tiếp theo. o Gửi tin nhắn hỏi lại khi phát hiện phản hồi người dùng không hợp lệ, phản hồi không phù hợp định dạng phản hồi.

VD: Phản hồi của bạn không đúng định dạng email, bạn gửi lại cho mình nhé. o Rẽ nhánh khi phản hồi không hợp lệ: khi phản hồi của người dùng không hợp lệ nhưng vẫn nhảy sang hành động tiếp theo để tránh gây ra phiền toái cho khách hàng. o Nhắn tin nhắn tiếp tục khi user không trả lời sau 1 khoảng thời gian: khi Bot đã phản hồi tới người dùng nhưng người dùng sau một khoảng thời gian người dùng không trả lời thì Bot tiếp tục gửi tin nhắn tiếp theo. o Thử lại mãi mãi đến khi nào lấy được thông tin user mong muốn. VD: sau khi Bot đã phản hồi người dùng nhưng sau một khoảng. o Đính kèm biến user trong tin nhắn hay trong câu hỏi. o Bỏ qua việc gửi tin nhắn hỏi lại nếu người dùng từ chối cho thông tin.

VD: Tin nhắn phản hồi đầu tiên của người dùng chứa từ "no",

CÔNG NGHỆ SỬ DỤNG

Cassandra

Cassandra là một hệ thống quản lý cơ sở dữ liệu được phát triển bởi Facebook vào năm 2007 Sau đó được tặng cho quỹ Apache vào 2/2010 và được nâng cấp lên dự án hàng đầu của Apache Cassandra là hệ cơ sở dữ liệu phân tán, dữ liệu được lưu trữ trên nhiều node của nhiều máy khác nhau, theo cơ chế P2P Ngôn ngữ phát triển Cassandra là Java Cassandra được thiết kế có thể chạy trong phần cứng giá rẻ, và cung cấp write throughput khá là cao (latency tầm 0.5ms), trong khi read throughput thì thấp hơn (latency tầm 2.5ms)[5].

2.1.2 Cơ chế lưu dữ liệu

Cassandra thực hiện lưu dữ liệu thông qua hai nơi : Không gian bộ nhớ (Memtable) và không gian đĩa (SSTable) Khi đọc và ghi dữ liệu thì sẽ ưu tiên trên memtable trước, sau đó mới đến SSTable Dữ liệu được lưu trên memory nên việc truy vấn dữ liệu trên cassandra diễn ra nhanh chóng Dữ liệu được lưu trữ trong DB của Cassandra thuộc dạng key-value store (KVS) Có thể có nhiều table trong database, giữa các table sẽ không có mối quan hệ nào Nhiều table được tổng hợp lại thành keyspace Trước khi insert dữ liệu vào cassandra thì cần phải tạo keyspace và schema của table Có thể thực hiện 1 số câu query như select, update, insert, delete, drop.

 Tốc độ truy vấn dữ liệu nhanh

 Tính chịu lỗi khá cao, cho dù node bị chết đi chăng nữa thì khi truy vấn sẽ được chuyển hướng đến node khác

 Dễ dàng backup, restore dữ liệu

 Dễ dàng scale database theo chiều ngang

 Phù hợp với các hệ thống messaging (ứng dụng hay service về chat)

Apache Kafka

Apache Kafka là một nền tảng truyền giữ liệu phân tán (distributed streaming platform) được phát triển ban đầu bởi LinkedIn và sau đó trở thành dự án Apache nguồn mở từ năm 2011 Kafka được viết bằng ngôn ngữ Scala và Java theo mô hình Publish – Subscribe trong đó bên Publish dữ liệu gọi là Producer còn bên nhận dữ liệu là Consumer Kafka quản lý dữ liệu theo từng Topic và mỗi Topic có thể có nhiều Subscriber.

2.2.2 Kiến trúc hệ thống Đối tượng tương tác chính trong hệ thống Kafka là các message Messages đơn thuần là byte array và developer có thể sử dụng chúng để lưu bất kì object với bất kì format nào: thông thường là String, JSON và Avro Các message sẽ được publish vào các topic, topic là một kho chứa các bản ghi message được publish vào Kafka Các topic lại được chia nhỏ thành các đơn vị nhỏ hơn gọi Partition

Hình 2.9: Mô hình cấu trúc hệ thống của Apache Kafka [16]

Hình 2.1 mô tả kiến trúc hệ thống của Apache Kafka [16] Hệ thống Kafka có

4 thành phần chính bao gồm Producer, Broker, Consumer và Zookeeper. Producer là chương trình hay ứng dụng tạo ra messages, đẩy message publish vào Topic còn Consumer ngược lại là chương trình/ứng dụng có chức năng subscribe vào một Topic để tiêu thụ, xử lý các message đó Một chương trình có thể vừa là một Producer vừa là một Consumer Kafka cluster là một set các server, mỗi một set này được gọi là 1 broker Và cuối cùng Zookeeper được dùng để quản lý và bố trí các broker.

 Kafka là một hệ thống nhắn tin pub-sub nhanh, có thể mở rộng, khả năng chịu lỗi cao, do đó được sử dụng trong những trường hợp xử lý khối lượng lớn dữ liệu đến và đáp ứng khả năng phản hồi ngay lập tức.

 Kafka có các đặc tính thông lượng, độ tin cậy và sao chép cao hơn, có thể áp dụng cho những thứ như theo dõi các cuộc gọi dịch vụ (theo dõi mọi cuộc gọi).

 Hiệu suất Kafka nhanh chóng và ổn định, cung cấp độ bền đáng tin cậy, có lượng public-subscribe linh hoạt phù hợp với số lượng Consumer Group của người tiêu dùng.

 Kafka hoạt động tốt với các hệ thống có luồng dữ liệu để xử lý và cho phép các hệ thống đó tổng hợp, chuyển đổi & tải vào các store khác.

Docker

Docker là một nền tảng cho developers và sysadmin để phát triển, deploy và chạy ứng dụng với container Nó cho phép tạo các môi trường độc lập và tách biệt để khởi chạy và phát triển ứng dụng và môi trường này được gọi là container Docker cho phép ứng dụng chạy dễ dàng trên tầng ảo hóa "build once, run anywhere", xây dựng một lần chạy đúng ở mọi nơi.

2.3.2 Các khái niệm trong Docker

Có ba khái niệm cơ bản cần nắm được về Docker đó là Images, Container và Dockerfile 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 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 Và Dockerfile là một tập tin bao gồm các chỉ dẫn để build một image, Dockerfile sẽ quy định Docker Image được khởi tạo từ đâu, gồm những gì trong đó.

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ủaDockerfile.

Hình 2.10: Các khái niệm trong Docker [9]

Hình 2.2 mô tả quy trình tạo ra một Docker Container Dockerfile quy định Docker Image sẽ được khởi tạo từ đâu và chứa những thành phần gì trong image đó Từ dockerfile có thể build Docker Image là khuôn mẫu của Container Từ khuôn mẫu của Container có thể tạo ra một Container với chương trình phần mềm chạy trong Container đó.

2.3.3 Kiến trúc hệ thống Docker

Hình 2.2 mô tả kiến trúc hệ thống Docker, gồm 3 thành phần chính gồm Docker Client, Docker Host và Docker Registry [10], trong đó: Docker Registry (Docker Hub) là một kho chứa các Image được publish bởi cộng đồng Docker.

Nó giống như GitHub và bạn có thể tìm những Image cần thiết và pull về sử dụng Docker Host: 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 Các Docker Daemon cũng giao tiếp với nhau để quản lý các Docker Service Docker Client: là một công cụ giúp người dùng giao tiếp với Docker host.

Ví dụ khi người dùng gõ lệnh docker run image ABC tức là người dùng sử dụng CLI và gửi request đến docker thông qua api, và sau đó Docker daemon sẽ xử lý tiếp Docker client có thể giao tiếp và gửi request đến nhiều Docker daemon.

 Tiện lợi và dễ dàng sử dụng cho mọi người từ developers, system admin, architects, build và test ứng dụng nhanh chóng.

 Tốc độ: Docker container rất nhẹ và nhanh, bạn có thể tạo và chạy docker container trong vài giây nhanh hơn rất nhiều mới máy ảo (virtual machine).

 Khả năng di động: môi trường develop được dựng lên bằng docker có thể chuyển từ người này sang người khác mà không làm thay đổi cấu hình ở trong.

 Khả năng chia sẻ giữa cộng đồng sử dụng thông qua DockerHub

 Dễ dàng scale để triển khai kiến trúc Microservices.

 Khi bạn cần build 1 lần và chạy ở nhiều máy khác nhau mà không cần quan tâm đến config.

 Khi bạn cần một cách tiếp cận mới về building, shipping, running ứng dụng một cách nhanh chóng dễ dàng.

Kubernetes

Kubernetes, hoặc k8s là một nền tảng mã nguồn mở tự động hóa việc quản lý,scaling và triển khai ứng dụng dưới dạng container hay còn gọi là Container orchestration engine Kubernetes orchestration cho phép bạn xây dựng các dịch vụ ứng dụng mở rộng nhiều containers Nó lên lịch các containers đó trên một cụm, mở rộng các containers và quản lý tình trạng của các containers theo thời gian.

Hình 2.12: Kiến trúc hệ thống của Kubernetes

Hình 2.4 mô tả kiến trúc hệ thống của Kubernetes [11] Hệ thống Kubernetes gồm 3 thành phần chính: API Server, Master Node và Worker Node Trong đó API Server là thành phần giúp các thành phần khác liên lạc nói chuyện với nhau. Lập trình viên khi triển khai ứng dụng sẽ gọi API Server này qua hai con đường giao diện người dùng (User interface) hoặc giao diện dòng lệnh (Command line interface) Master Node là server điều khiển các máy Worker chạy ứng dụng. Còn lại Worker Node là một máy ảo hoặc máy vật lý chạy kubernetes, server chạy ứng dụng trên đó.

Có hai khái niệm cơ bản và quan trọng nhất trong Kubernetes đó là Pods và Image Pods là khái niệm cơ bản và quan trọng nhất của Kubernetes Pod chính là nơi ứng dụng được chạy trong đó Bản thân Pod có thể chứa 1 hoặc nhiều hơn

1 container Pod là các tiến trình nằm trên các Worker Node Bản thân Pod có tài nguyên riêng về file system, cpu, ram, volumes, địa chỉ network Image: Là phần

Kubernetes mang đến rất nhiều lợi ích trong công việc vận hành ứng dụng, kubernetes đảm nhận việc nhân rộng và chuyển đổi dự phòng cho ứng dụng, cung cấp các mẫu deployment và ngoài ra còn có một số tính năng khác:

 Quản lý hàng loạt docker host.

 Container Scheduling (lên lịch cho container).

 Giám sát vòng đời và tình trạng hoạt động của các container.

 Có khả năng phát hiện lỗi và tự correct lỗi.

 Cân bằng tải hệ thống bằng cách điều phối request vào các pod.

 Quản lý log giúp việc phát triển sản phẩm và truy vết lỗi dễ dàng hơn.

2.5 Giao thức gRPC (grpc Remote Procedure Call)

2.5.1 Giới thiệu gRPC là một platform dành cho RPC được phát triển bởi Google gRPC là một giao thức request - response được dùng cho việc giao tiếp giữa các server (server - server) phù hợp cho các kiến trúc Microservice gRPC mặc định sử dụng Protocol Buffers như là một ngôn ngữ để định nghĩa các service và là định dạng để giao tiếp giữa các service với nhau Trong đó, Protocol Buffers là ngôn ngữ để định nghĩa các service và định dạng, kiểu dữ liệu để giao tiếp giữa các service với nhau Mỗi định nghĩa Protocol Buffers được đặt trong một file với đuôi là proto.

- Đơn giản hơn XML và JSON

- Dung lượng gói tin nhỏ

- Tốc độ truyền tin nhanh hơn 20 đến 100 lần so với XML/JSON (nguồn Google)

- Được hỗ trợ trực tiếp bởi nhiều ngôn ngữ lập trình khác nhau

- gRPC được xây dựng trên HTTP/2 , cho phép kết nối HTTP tốt hơn, hiệu quả hơn

- Dữ liệu không phù hợp với con người vì là định dạng binary.

- Chưa được hỗ trợ toàn diện bởi các ông lớn công nghệ , kể cả Google.

- Các tool test API chưa hỗ trợ nhiều.

- Còn nhiều hạn chế khi tương tác với FrontEnd, chỉ phù hợp giao tiếp giữa các server.

KẾT QUẢ ĐẠT ĐƯỢC

Kiến trúc chung hệ thống Chatbot

Hình 3.13: Kiến trúc hệ thống Chatbot

Hình 3.1 mô tả kiến trúc tổng quan của hệ thống gồm có tác nhân là người dùng (user) Hệ thống áp dụng mô hình Microservices trong đó mỗi service đảm nhận một vai trò và nhiệm vụ riêng biệt Thành phần chính trong đồ án này là service Chatbot :

 User: người dùng nhắn tin vào cửa sổ chat trên website.

 API: Service có nhiệm vụ là cổng định tuyến request, chuyển từ request http thành request grpc.

 Conversation: Service có nhiệm vụ thực hiện nhận và gửi tin nhắn cũng như lưu trữ các thông tin cuộc hội thoại.

 ChatBot: Service có nhiệm vụ xử thực hiện các action của bỏ và lưu trữ dữ liệu về bot.

 User: Service có nhiệm xử lý và lưu trữ dữ liệu về user.

 Cassandra: Sử dụng để lưu trữ thông tin của hệ thống.

Kiến trúc lõi hệ thống Chatbot

Hình 3.14: Kiến trúc lõi service Chatbot

Hình 3.2 mô tả kiến trúc service Chatbot trong đó:

 ServeGrpc, ServeHttp, ServeAsync là ba con đường để gửi request đến service Chatbot thông qua ba giao thức tương ứng là gRPC(gRPC Remote Procedure Call), HTTP, MessageQueue (Kafka).

 ChatBot: là đầu nhận API và request vào ChatBot server.

 BotMgr: thực hiện việc quản lý và truy vấn cơ sở dữ liệu.

 Runner: Thực hiện quản lý và chạy Bot thực thi.

 Action: Nơi quản lý và thực hiện các hành động của Chatbot.

 Schedule: là module cho phép hệ thống lập lịch nhằm thực hiện hai tác vụ: Một là lịch tĩnh chạy ngầm để thực hiện các tác vụ LoadJob, hai là lịch động để lên lịch hoạt động cho bot.

 LoadJob: là module định nghĩa các công việc tự động của hệ thống như dọn bộ nhớ, dọn bộ nhớ cache của database và các chức năng chạy nền

Phân tích và thiết kế hệ thống

Phần phân tích chức năng sẽ mô tả đầy đủ, chi tiết về các chức năng mà hệ thống cung cấp. a Các tác nhân tham gia hệ thống

Có hai tác nhân tham gia vào hệ thống: Agent và User.

Bảng 3.1: Các tác nhân trong hệ thống

STT Tên tác nhân Mô tả

1 Agent Người dùng đã đăng nhập vào hệ thống với vai trò là tư vấn viên trực chat

2 User Người dùng tham gia chat vào cửa sổ chat trên website b Danh sách các ca sử dụng

Hệ thống có tám ca sử dụng Chi tiết về các ca sử dụng được mô tả ở bảng dưới.

Bảng 3.2: Danh sách ca sử dụng

ID Tên ca sử dụng Mô tả Các tác nhân tham gia

UC-01 Quản lý danh sách bot

Agent xem và quản lý danh sách tất cả bot trong tài khoản

UC-02 Thêm bot mới Agent tạo kịch bản bot mới Agent

UC-03 Chỉnh sửa bot Agent chỉnh sửa thông tin, kịch bản bot

UC-04 Xóa bot Agent xóa kịch bản bot Agent

UC-05 Xem thống kê hoạt động bot Agent xem thống kê hoạt động của bot Agent

UC-06 Thử kịch bản bot Agent chạy thử kịch bản Bot Agent

UC-07 Thử hành động của Bot Agent chạy thử hành động của Bot Agent UC-08 Tương tác với Bot Người dùng tương tác với Bot User c Đặc tả ca sử dụng

Hình 3.15 : Biểu đồ ca sử dụng tổng quan của hệ thống

Hình 3.3 mô tả biểu đồ ca sử dụng tổng quát của hệ thống Có 3 tác nhân tham gia vào hệ thống : Khách, agent (tư vấn viên trực chat) và user (người dùng). Khách là người chưa đăng nhập vào hệ thống, khách có thể sử dụng các chức năng nhập đăng nhập Agent là tác nhân chính của hệ thống tham gia vào các ca sử dụng như : Quản lý danh sách bot, thêm bot mới, chỉnh sửa Bot, xem thống kê của bot, chạy thử kịch bản bot và cuối cùng là thử action của bot.

 UC-01: Ca sử dụng quản lý danh sách bot

Hình 3.16: Ca sử dụng quản lý danh sách bot

Bảng 3.3 : Đặc tả ca sử dụng quản lý danh sách bot

Tên Use Case Quản lý danh sách Bot

Tạo bởi Nguyễn Hoàng Thông Cập nhật gần nhất bởi: Nguyễn

Ngày tạo 12/12/2020 Ngày cập nhật gần nhất:

Tên ca sử dụng: Quản lý danh sách bot

ID: 01 Mức quan trọng: trung bình

Tác nhân chính: Agent Kiểu ca sử dụng: Chi tiết, thiết yếu Các nhân tố và mối quan tâm: Agent – Quản lý danh sách bot

Mô tả ngắn gọn: mô tả agent thực hiện quản lý danh sách các bot đã được tạo Kích hoạt: Agent chọn biểu tượng bot ở lề trái màn hình

● Bao gồm: Xem bot, sửa bot, xóa bot, thêm bot

1 Người dùng chọn vào biểu tượng bot ở lề trái màn hình

2 Hệ thống hiển thị danh sách các bot đã được khởi tạo (gồm tên bot, kênh tương tác, lần chạy cuối, cập nhật gần nhất, trạng thái và xem thống kê )

S-1 Agent sửa thông tin bot:

● Người quản trị click vào kịch bản bot muốn sửa.

● Hệ thống đưa người quản trị tới trang chi tiết bot.

● Người quản trị sửa thông tin bot, sửa kịch bản bot

● Hệ thống kiểm tra thông tin sửa và trả lại kết quả

● Người quản trị click icon xóa ở mỗi bot.

● Hệ thống tiến hành xóa bot và thông báo kết quả

● Người quản trị click icon thêm bot ở góc phải màn hình

● Hệ thống tiến hành hiển thị các mẫu bot có sẵn để agent chọn

● Agent chọn kịch bản bot muốn thêm mới

● Hệ thống đưa người quản trị đến trang sửa thông tin và kịch bản bot

Luồng sự kiện tương đương/ngoại lệ:

2a Khi sửa hoặc xóa quyết định có lỗi, hệ thống sẽ thông báo lại cho agent

 UC-02: Ca sử dụng Thêm bot mới

Hình 3.17 : Ca sử dụng thêm Bot mới

Bảng 3.4 : Đặc tả chi tiết use case thêm bot mới

Tên Use Case Thêm bot mới

Cao Tác nhân chính: Agent Kiểu ca sử dụng: Chi tiết, thiết yếu Các nhân tố và mối quan tâm: Agent - Thêm bot mới

Mô tả ngắn gọn: mô tả agent thêm kịch bản bot mới

Kích hoạt: Khi Người quản trị chọn vào nút Tạo Bot ở góc phải màn hình

● Bao gồm: Xem trước kịch bản template bot

Các luồng sự kiện chính:

1 Agent vào nút Tạo Bot ở góc phải màn hình

2 Hệ thống tiến hành hiển thị các mẫu bot có sẵn để agent chọn

3 Agent xem trước kịch bản các template mẫu

4 Agent chọn sử dụng kịch bản phù hợp

5 Hệ thống đưa người dùng đến trang giao diện chỉnh sửa bot

6 Agent chỉnh sửa thông tin và kịch bản bot

7 Agent chọn lưu thông tin bot

8 Hệ thống thông báo lưu bot thành công

Các luồng sự kiện con:

S-1 Agent xem thống kê bot:

● Người quản trị click vào phần xem thống kê bot

● Hệ thống đưa người quản trị tới trang thống kê bot

Các luồng sự kiện ngoại lệ/tương đương:

2a Khi thêm bot có lỗi, hệ thống sẽ thông báo lại cho người dùng

 UC-03: Ca sử dụng chỉnh sửa bot

Hình 3.18 : Ca sử dụng chỉnh sửa bot Bảng 3.5 : Đặc tả chi tiết ca sử dụng Chỉnh sửa bot

Tên Use Case Chỉnh sửa bot

Cập nhật gần nhất bởi: Nguyễn Hoàng Thông

Tên ca sử dụng: Chỉnh sửa Bot

ID: 03 Mức quan trọng: Cao Tác nhân chính: Agent Kiểu ca sử dụng: Chi tiết, thiết yếu

Các nhân tố và mối quan tâm: Agent - Chỉnh sửa bot

Mô tả ngắn gọn: mô tả agent chỉnh sửa thông tin và kịch bản của bot

● Bao gồm: Xóa bot và xem thống kê bot

1 Agent vào giao diện quản lý bot

2 Giao diện hiển thị danh sách bot cho agent xem

3 Agent chọn sửa vào bot muốn chỉnh sửa

4 Giao diện hiển thị trang chi tiết của bot để agent chỉnh sửa

5 Agent chỉnh sửa phần cài đặt, thông tin bot và kịch bản bot

6 Agent ấn vào nút cập nhật ở góc phải màn hình

7 Hệ thống thông báo chỉnh sửa bot thành công

● Người quản trị click icon xóa ở mỗi bot.

● Hệ thống tiến hành xóa bớt và thông báo kết quả

2a Khi sửa hoặc xóa bot có lỗi, hệ thống sẽ thông báo lại cho người dùng

 UC-04: Ca sử dụng xóa bot

Hình 3.19 : Ca sử dụng xóa bot

Bảng 3.6 : Đặc tả chi tiết use case xóa bot

Tên Use Case Xóa bot

Tên ca sử dụng: Xóa

ID: 04 Mức quan trọng: Trung bình

Tác nhân chính: Agent Kiểu ca sử dụng: Trung bình

Các nhân tố và mối quan tâm: Agent - Xóa bot

Mô tả ngắn gọn: mô tả agent xóa bot

Kích hoạt: Khi agent chọn vào biểu tượng thùng rác ở mỗi bot

1 Agent vào giao diện quản lý bot

2 Agent chọn vào biểu tượng thùng rác ở mỗi bot

3 Hệ thống hiển thị thông báo bạn có chắc muốn xóa bot

2a Khi xóa bot có lỗi, hệ thống sẽ thông báo lại cho người dùng

 UC-05 : Use case xem thống kê hoạt động của bot

Hình 3.20 : Ca sử dụng Xem thống kê hoạt động của bot

Bảng 3.7 : Đặc tả chi tiết ca sử dụng xem thống kê bot

Tên Use Case Xem thống kê hoạt động của bot

Tên ca sử dụng: Xem thống kê hoạt động của Bot

ID: 05 Mức quan trọng: Trung bình Tác nhân chính: Agent Kiểu ca sử dụng: Trung bình

Các nhân tố và mối quan tâm: Agent - Xem thống kê hoạt động của bot

Mô tả ngắn gọn: mô tả agent chỉnh sửa thông tin và kịch bản của bot

Kích hoạt: Khi Agent chọn vào chữ thống kê ở mỗi bot trong giao diện quản lý bot hoặc chọn vào mục xem thống kê ở lề trái trong giao diện chỉnh sửa bot

● Bao gồm: Chỉnh sửa bot

1 Agent vào chọn vào quản lý danh sách bot

2 Hệ thống đưa agent tới trang quản lý danh sách bot

3 Agent chọn vào chữ thống kê ở mỗi bot

4 Hệ thống đưa người dùng đến trang hiển thị thống kê bot

● Agent chọn vào hiển thị danh sách bot

● Hệ thống đưa agent tới trang quản lý danh sách bot

● Agent chọn vào tên của bot muốn xem thống kê

● Hệ thống đưa agent tới trang chỉnh sửa thông tin bot

● Agent chọn vào phần xem thống kê bot ở lề trái màn hình

● Hệ thống đưa agent tới trang hiển thị thống kê bot

2a Khi vào trang thống kê có lỗi, hệ thống sẽ thông báo lại cho người dùng

 UC-06: Ca sử dụng Thử kịch bản bot

Bảng 3.8 : Đặc tả ca sử dụng Thử kịch bản bot

Tên Use Case Thử kịch bản bot

Cập nhật gần nhất bởi: Nguyễn Hoàng Thông

Tên ca sử dụng: Xem thử kịch bản Bot

Cao Tác nhân chính: Agent Kiểu ca sử dụng: Thiết yếu

Các nhân tố và mối quan tâm: Agent - Thử kich bản bot

Mô tả ngắn gọn: mô tả agent sau khi chỉnh sửa kịch bản bot sẽ chọn vào Xem thử ở góc phải màn hình để chạy thử kịch bản Bot

Kích hoạt: Khi Agent chọn vào chữ Xem thử ở góc phải màn hình trong giao diện chỉnh sửa bot

● Bao gồm: Chỉnh sửa bot, xem thống kê bot

● Mở rộng: Chỉnh sửa bot

1 Agent vào trang quản lý danh sách bot

2 Agent chọn vào tên bot muốn chỉnh sửa hoặc chạy thử

3 Hệ thống đưa người đến giao diện chỉnh sửa bot

4 Agent chỉnh sửa kịch bản bot theo ý muốn

5 Agent chọn vào Xem thử ở góc phải màn hình

6 Hệ thống hiển thị ra cửa sổ chat để tương tác với agent

7 Agent tương tác với cửa sổ chat để đi đến cuối kịch bản bot

8 Bot dừng lại khi chạy hết kịch bản bot

● Agent chọn chạy đến cuối kịch bản bot

● Agent chọn Chạy lại để thử lại kịch bản bot

● Hệ thống làm sạch cửa sổ chat để tương tác với agent

● Agent tương tác với cửa sổ chat để đi đến cuối kịch bản

● Bot dừng lại khi chạy đến hết kịch bản

2a Khi một action nào đó của bot không thành công, kịch bản bot dừng lại

 UC-07: Ca sử dụng Thử action của bot

Hình 3.22 : Ca sử dụng thử hành động của bot

Bảng 3.9 : Đặc tả ca sử dụng chạy thử action bot

Tên Use Case Thử hành động của bot

Xem thử action của bot

ID: 07 Mức quan trọng: Trung bình Tác nhân chính: Agent Kiểu ca sử dụng: Trung bình

Các nhân tố và mối quan tâm: Agent - Thử action của bot

Mô tả ngắn gọn: mô tả agent chạy thử action gửi request http

Kích hoạt: Khi Agent chọn tạo action gửi request http, và chọn chạy thử

● Bao gồm: Chỉnh sửa bot

● Mở rộng: Chỉnh sửa bot

1 Agent vào giao diện chỉnh sửa bot

2 Hệ thống đưa agent vào giao diện chỉnh sửa bot

3 Agent thêm action gửi request http

4 Agent thêm các trường url, header, payload, method phù hợp

 UC-08: Ca sử dụng Tương tác với Chatbot

Hình 3.23 : Ca sử dụng Tương tác với bot

Bảng 3.10 : Đặc tả chi tiết ca sử dụng tương tác với Chatbot

Tên Use Case Tương tác với bot

ID: 08 Mức quan trọng: Cao Tác nhân chính: User Kiểu ca sử dụng: Thiết yếu

Các nhân tố và mối quan tâm: User - Tương tác với Chatbot

Mô tả ngắn gọn: mô tả user sau khi vào website sẽ tương tác với Chatbot thông qua cửa sổ chat trên website

Kích hoạt: Khi Agent chọn vào website vào đáp ứng điều kiện trigger đã cài đặt của Bot thì cửa sổ chat sẽ bật lên và Bot sẽ gửi tin nhắn cho user

● Bao gồm: Chỉnh sửa bot, xem thống kê bot

User truy cập vào website

Hệ thống sẽ kiểm tra các điều kiện trigger của bot, nếu có bot nào thỏa mãn các điều kiện thì cửa sổ chat trên website sẽ bật lên, đồng thời hệ thống sẽ gửi tin nhắn cho người dùng theo kịch bản đã xây dựng sẵn

User sẽ tương tác với bot thông qua cửa sổ chat

Bot sẽ dừng lại khi chạy hết kịch bản bot

S-1 User bỏ dở kịch bản bot, không tương tác với bot

2a Khi một action nào đó của bot không thành công, kịch bản bot dừng lại

Hệ thống được xây dựng dựa trên mô hình 3 lớp (3 -layer) Mô hình này thực hiện tách biệt các phần giao dịch, xử lý dữ liệu, truy cập dữ liệu thành 3 lớp riêng biệt, điều này giúp hệ thống dễ dàng bảo trì và mở rộng

Hình 3.24 : Mô hình ba lớp

Presentation Layer (GUI): Gồm các thành phần giao diện để hiển thị và nhận dữ liệu từ người dùng Lớp này chỉ thực hiện việc giao tiếp với người dùng (nhập, xuất, ) mà không thực hiện việc tính toán, kiểm tra hay các thao tác liên quan đến cơ sở dữ liệu Lớp này sử dụng các chức năng do lớp Business Logic Layer cung cấp.

Business Logic Layer (BLL): Lớp này gồm các thành phần để kiểm tra, xử lý các ràng buộc, cung cấp các chức năng cốt lõi của hệ thống Lớp này sử dụng các chức năng do lớp Data Access Layer phía dưới cung cấp.

Data Access Layer (DAL): Lớp này gồm các thành phần thực hiện kết nối, truy vấn dữ liệu từ cơ sở dữ liệu thực hiện đọc, ghi tệp tin hoặc cũng có thể sử dụng các chức năng của dịch vụ, hệ thống khác: a Các lớp của tầng giao diện (Presentation Layer)

GUI_Login: Giao diện đăng nhập.

GUI_QLDanhsachBot: Giao diện quản lý danh sách bot.

GUI_CreateBot: Giao diện tạo bot mới.

GUI_Report: Giao diện xem thống kê bot.

GUI_Bot: Giao diện chỉnh sửa thông tin, kịch bản của bot.

GUI_Try: Giao diện chạy thử chức năng bot.

GUI_CuasoChat: Giao diện cửa sổ chat, người dùng tương tác với bot thông qua cửa sổ chat. b Các lớp của tầng logic (Business Logic Layer)

BLL_QLDanhsachBot: Logic quản lý danh sách bot Cung cấp các phương thức cho phép thêm, sửa, xóa, lấy thông tin của bot cũng như lấy thông tin tất cả bot trong account.

BLL_StartBot: Cung cấp các Login cho phép chạy kịch bản Bot, dừng kịch bản Bot và nhận Event từ các service khác trong hệ thống.

BLL_Action: Cung cấp các Logic cho phép chạy thử kịch bản Bot và chạy thử hành động của Bot.

BLL_Report: Cung cấp các Logic cho phép xem thống kê chi tiết hoạt động của Bot và danh sách các cuộc hội thoại Bot đã tham gia trong một khoảng thời gian.

BLL_BotRevision: Cung cấp các logic cho phép tạo và lấy thông tin của các phiên bản của kịch bản Bot.

Hình 3.29: BLL_BotRevision c Các lớp của tầng truy cập dữ liệu (Data Access Layer)

Hình 3.30: Tầng data access

Lớp Bot: cung cấp các phương thức lấy accountID, cập nhật Bot, xóa Bot, lấy thông tin của 1 bot trong account, lấy thông tin của toàn bộ Bot trong account,

Và lấy thông tin của tất cả Bot trong hệ thống.

Lớp Exec-Bot: cung cấp các phương thức về các Bot thực thi trong hệ thống gồm cập nhật, xóa Bot thực thi, lấy thông tin Bot thực thi từ BotID, lấy thông tin tất cả Bot thực thi của 1 Bot, lấy thông tin tất cả Bot thực thi từ account, và lấy thông tin tất cả Bot thực thi trong hệ thống, lấy thông tin tất cả Bot thực thi đã dừng hoạt động trong hệ thống.

Hình 3.32: DAL - Lớp ExecBot

Lớp ExecBot-Index: cung cấp các phương thức cập nhật, lấy thông tin thống kê từ Bot thực thi.

Hình 3.33: DAL - Lớp ExecBotIndex

Lớp Bot-Tag: cung cấp các phương thức lấy thông tin các nhãn hành động của bot, mỗi lần Bot thay đổi kịch bản hệ thống sẽ sinh ra 1 tag cho Bot để dễ dàng truy vấn lại kịch bản bot đã thay đổi.

Hình 3.34: DAL - Lớp BotTag

3.3.3 Phân tích hành vi a Biểu đồ trình tự ca sử dụng quản lý danh sách Bot

Hình 3.35: Biểu đồ trình tự ca sử dụng quản lý danh sách Bot

Thiết kế giao diện

Một số hình ảnh giao diện

Hình 3.43 : Giao diện quản lý danh sách Bot

Hình 3.44: Giao diện chức năng thêm Bot lựa chọn template

Hình 3.45: Giao diện chức năng thêm Bot - xem thử template mẫu

Hình 3.46: Giao diện chức năng chỉnh sửa Bot - chỉnh sửa kịch bản

Hình 3.47: Giao diện chức năng chạy thử kịch bản Bot

Hình 3.48: Giao diện chức năng chỉnh sửa Bot - chỉnh sửa thông tin Bot

Hình 3.49: Giao diện chức năng xem thống kê hoạt động Bot

Hình 3.50: Giao diện cuộc chat mà Bot phân chia cho agent

Cài đặt, thử nghiệm và đánh giá hệ thống

3.5.1 Cài đặt a Công cụ sử dụng

Sau khi phân tích thiết kế, em sẽ sử dụng các công cụ như sau để thực hiện triển khai hệ thống:

 Golang: ngôn ngữ lập trình phía backend

 Git: quản lý phiên bản mã nguồn

 Visual Studio Code: IDE được sử dụng trong quá trình triển khai mã nguồn

 Cassandra: hệ quản trị cơ sở dữ liệu sử dụng để lưu trữ dữ liệu cho hệ thống

 Docker: công cụ để triển khai hệ thống và kiểm thử hệ thống

 Kubernetes: công cụ để triển khai hệ thống và deployment

 Apache Bench: công cụ để kiểm thử hiệu năng hệ thống b Phát triển hệ thống

Cấu trúc thư mục backend gồm các thành phần:

 Thư mục action : chứa code golang định nghĩa các action của chatbot

 Thư mục runner: chứa code golang để cấu hình môi trường chạy Bot và cấu hình Bot thực thi.

 Thư mục vendor: chứa các thư viện liên quan, các tài nguyên tĩnh của hệ thống.

 Các file yaml dùng để cấu hình service và cấu hình deployment.

 Dockerfile: là file config cho Docker để build chương trình ra image.

3.5.2 Kiểm thử và đánh giá hệ thống a Môi trường kiểm thử

Hệ thống thử nghiệm được xây dựng với kịch bản như sau: Client sử dụng công cụ Apache Bench (AB) gửi một lượng lớn request HTTP trong cùng một thời gian đến máy chủ và tiến hành ghi lại các thông số kiểm thử Dòng lệnh mà

AB cung cấp gồm 3 thông số -n: tổng số request gửi lên, -c là số request trong cùng một thời điểm và đường dẫn url cần thử nghiệm.

Hình 3.52: Câu lệnh terminal của công cụ ApacheBench

Server gồm một máy chủ chứa mã nguồn của chương trình kết nối với cơ sở dữ liệu cassandra chứa dữ liệu của hệ thống Thử nghiệm sẽ tập trung vào hai request chính là đọc (GET) và ghi (POST) dữ liệu Bot vào cơ sở dữ liệu cassandra Thử nghiệm sẽ tiến hành tại hai môi trường local và server thật.

Kết quả kiểm thử quan tâm đến các thông số như:

 Completed Requests: Số lượng request thành công.

 Failed Requests : Số lượng request thất bại.

 Time per request : thời gian mỗi request trả về.

 Transfer rate: tốc độ đường truyền.

 Percentage of the requests served within a certain time: phần trăm số lượng request thành công trong một khoảng thời gian nhất định.

Hình 3.53: Kiến trúc hệ thống thử nghiệm b Kết quả kiểm thử tại localhost

 Thử nghiệm ghi dữ liệu (POST) với số concurrent (-c) là 1.000 và tổng số request tăng dần.

Bảng 3.16: Thời gian phản hồi mỗi request ứng với số lượng request

Tổng số requests (n) Time per request (ms)

Hình 3.54: Biểu đồ thời gian phản hồi mỗi request ứng với số lượng request

Qua biểu đồ hình 56, ta nhận thấy với số lượng request càng lớn thì thời gian phản hồi mỗi request càng nhỏ: với 1.000 requests thì thời gian phản hồi là 543,192(ms) , với 100.000 requests thì thời gian phản hồi chỉ là 237,770(ms).

 Thử nghiệm đọc dữ liệu (GET) với số concurrent (-c) là 1000 và tổng số request tăng dần.

Bảng 3.17: Thời gian phản hồi mỗi request ứng với số lượng request

Tổng số requests (n) Time per request (ms)

Hình 3.55: Biểu đồ thời gian phản hồi mỗi request ứng với số lượng request(GET)

Qua biểu đồ hình 57, ta thấy số với số lượng request từ 1.000 đến 20.000 thì thời gian phản hồi mỗi request giảm dần từ 242,070(ms) đến 151,382(ms) Với số lượng request từ 20.000 đến 100.000 thì thời gian phản hồi mỗi request gần như không thay đổi và giao động ở mức trên 150 (ms).

 Thử nghiệm phần trăm số lượng request thành công trong một khoảng thời gian nhất định với n = 100.000 (requests).

Bảng 3.18: Phần trăm số lượng request thành công trong một khoảng thời gian (POST)

Qua biểu đồ hình 58, ta thấy hệ thống chỉ cần mất 223 (ms) để hoàn thành 50% số lượng requests và 480(ms) để hoàn thành 99% số lượng requests. Request lâu nhất của hệ thống là 633 (ms).

Bảng 3.19: Phần trăm số lượng request thành công trong một khoảng thời gian (GET)

Hình 3.57 : Biểu đồ phần trăm số request hoàn thành trong một khoảng thời gian nhất định (GET)

Qua biểu đồ hình 59, ta thấy hệ thống chỉ cần mất 147 (ms) để hoàn thành50% số lượng requests và 271 (ms) để hoàn thành 99% số lượng requests.Request lâu nhất của hệ thống là 376 (ms).

Qua quá trình đánh giá hiệu năng hệ thống tại localhost, ta rút ra một số nhận xét: Các thao tác ghi dữ liệu (POST) tốn nhiều thời gian hơn các thao tác đọc ghi dữ liệu (GET) Điều này có thể giải thích là do cơ chế lưu cache của Cassandra, các bản ghi được truy vấn nhiều được lưu vào không gian bộ nhớ (Memory) để tiết kiệm thời gian truy vấn Thứ hai là với tổng số request càng lớn thì thời gian phản hồi mỗi request càng nhỏ. c Thử nghiệm tại máy chủ thật

Bảng 3.20: Tỷ lệ số request thành công

Tổng số request Số request thành công % số request thành công

Hình 3.58 : Biểu đồ % số request thành công

Với thử nghiệm tại máy chủ thật ta thấy, với khoảng từ 1.000 requests đến50.000 request hệ thống hoạt động đảm bảo ổn định với hiệu suất > 99% số request thành công Với mức 100.000 request hệ thống đạt mức phản hồi > 96%.Đây là con số không cao nhưng chấp nhận được và cần cải thiện trong tương lai.

LUẬN VÀ ĐỊNH HƯỚNG PHÁT TRIỂN

Kết luận

Trong thời đại bùng nổ về mạng internet và thông tin như ngày nay, nhu cầu giao tiếp giữa người với người ngày càng gia tăng, mô hình bán hàng trực tuyến ngày càng cho thấy sự hiệu quả và vượt trội so với hình thức bán hàng truyền thống là: người mua phải đến tận nơi cửa hàng để mua hàng Đây chính điều kiện thuận lợi cho lĩnh vực thương mại điện tử ngày càng phát triển hơn Trong xu hướng đó, khả năng chăm sóc khách hàng của chủ doanh nghiệp trên website là rất quan trọng ChatBot ra đời như một xu thế tất yếu để giúp doanh nghiệp tự động hóa công việc chăm sóc khách hàng, thay thế một phần sức lao động con người Trong đó, Chatbot là các ứng dụng (application) hay nền tảng (platform) được thiết kế để giao tiếp với người dùng Internet bằng giọng nói hoặc văn bản như người thật Nhiệm vụ của đồ án này là xây dựng một hệ thống Chatbot cho phép người chủ doanh nghiệp thiết kế, quản lý và xây dựng bot để tăng khả năng chăm sóc khánh hàng, thu thập được nhiều khách hàng tiềm năng mà vẫn giảm được sức lao động của con người

Giải pháp đưa ra: Khi người dùng vào website, hệ thống sẽ kiểm tra các điều kiện kích hoạt của tất cả Bot Khi điều kiện kích hoạt của một kịch bản bot nào đó khớp thì cửa sổ chat trên website sẽ bật lên, đồng thời gửi request đến service chatbot để kích hoạt bot Từ đối tượng Bot sẽ khởi chạy Bot thực thi, Bot thực thi là một thể hiện (instance) của đối tượng Bot Bot thực thi sẽ tiến hành khởi chạy cây hành động từ Bot, từ cây hành động sẽ thực thi lần lượt các hành động (action) của Bot Để thực hiện được giải pháp đưa ra trên thì mục tiêu chính của đề tài:

1 Tìm hiểu công nghệ Docker, tìm hiểu công nghệ vận hành các Docker Container là Kubernetes (k8s)

2 Tìm hiểu về hệ quản trị cơ sở dữ liệu phân tán Cassandra, công nghệ dùng cho MessageQueue là Apache Kafka

3 Thiết kế, xây dựng, cài đặt môi trường chạy bot Đồ án tốt nghiệp đã thực hiện thành công những yêu cầu của bài toán đặt ra. Đó là triển khai thành công hệ thống cho phép người chủ doanh nghiệp thiết kế, quản lý và xây dựng bot để tăng khả năng chăm sóc khánh hàng, thu thập được nhiều khách hàng tiềm năng mà vẫn giảm được sức lao động của con người Qua quá trình thử nghiệm cho thấy hệ thống hoạt động ổn định với khả năng chịu tải cao đáp ứng yêu cầu về một hệ thống lớn có hiệu năng cao đáp ứng trên một triệu người dùng mỗi ngày (>1.000.000 users/day) và trên 50.000 requests tại một thời điểm (>50.000 requests/s)

Qua quá trình thực hiện đồ án và tìm hiểu các công nghệ đã giúp em hiểu hơn về quy trình xây dựng hệ thống microservices hiệu năng cao cũng như cách lắng nghe, tìm hiểu nhu cầu, thị hiếu của khách hàng từ đó hiểu hơn về nghiệp vụ kinh doanh và cách nắm bắt xu hướng thị trường Hơn nữa qua quá trình thực hiện đồ án, em cũng tìm hiểu và nắm bắt được các công nghệ mới đặc biệt là Cassandra, gRPC và Docker Tiếp theo là quá trình xây dựng hệ thống Hệ thống được xây dựng đầy đủ các chức năng để hỗ trợ tác nhân chính của hệ thống là agent trong quá trình xây dựng bot Ngoài ra, việc hoàn thành đồ án còn giúp bản thân nâng cao khả năng đọc, tìm hiểu, nghiên cứu công nghệ và ứng dụng của nó vào bài toán cụ thể Rèn luyện khả năng tổng hợp, tư duy giải quyết vấn đề cũng như kỹ năng trình bày, lập luận, viết một báo cáo đồ án tốt nghiệp hoàn chỉnh. Ưu, nhược điểm của hệ thống

Một số ưu điểm của hệ thống bao gồm: thứ nhất là hướng tiếp cận thân thiện với người dùng Hệ thống được xây dựng lấy trải nghiệm người dùng làm trọng tâm và cải thiện dần dựa trên phản hồi đánh giá của người dùng Thứ hai là giao diện đơn giản giúp người dùng dễ dàng sử dụng nhất có thể Người dùng mới vào không cần mất quá nhiều thời gian để làm quen và tự xây dựng bot cho mình. Thứ ba là mô hình microservices cho phép hệ thống đạt tốc độ cao, hiệu năng tốt đáp ứng nhu cầu về một hệ thống Chatbot mạnh mẽ, ổn định Và cuối cùng hệ thống đã đảm bải giải quyết được bài toán, yêu cầu mà đồ án đã đề ra.

Qua quá trình vận hành thật sự của hệ thống, em rurt ra một vài nhược điểm sau Thứ nhất các hành động của Chatbot chưa nhiều, chưa đa dạng Các hành động hiện tại mới chỉ đáp ứng được một số yêu cầu nhất định cũng như một bộ phận khách hàng nhất định Các hành động cần được mở rộng thêm ví dụ như hành động gửi email tự động, hay tích hợp thêm các ứng dụng thứ ba, …Thứ hai, Chatbot chưa mang lại nhiều lead như mong đợi Lead ở đây được định nghĩa là khách hàng tiềm năng, những người đã cung cấp hoặc điện thoại hoặc email cho hệ thống Các hành động cần giảm bớt sự rườm rà như hỏi quá nhiều, quá cứng nhắc để tăng trải nghiệm khách hàng hơn Và cuối cùng là hệ thống vận hành chưa thực sự ổn định, điều này cần cải thiện tốt hơn trong thời gian tương lai cũng như cần các đoạn log vào code để truy vấn lỗi, tìm ra lý do vì sao hệ thống hoạt động chưa ổn định.

Hướng phát triển

4.2.1 Phát triển thêm các hành động cho Bot

Vấn đề: Hiện nay các action của ChatBot chưa nhiều và chưa đa dạng và chỉ mới đáp ứng được một bộ phận khách hàng nhất định.

Hướng giải quyết: Xây dựng thêm một số action đáp ứng tối đa nhu cầu của người dùng: hành động gửi email, thông báo cho user, tích hợp thêm các ứng dụng thứ ba,

4.2.2 Phát triển sự "thông minh" cho Bot

Vấn đề: ChatBot chưa thông minh, chưa nhận diện được ảnh và chỉ dùng các thuật toán tách chuỗi để lấy thông tin từ text.

Hướng giải quyết: Tích hợp một số module học máy cho phép nhận diện ảnh và text.

4.2.3 Thu hút thêm khách hàng tiềm năng

Vấn đề: chưa lấy được nhiều lead như mong đợi, tỉ lệ chuyển đổi khách hàng tiềm năng còn thấp.

Hướng giải quyết: Bỏ hoặc thay đổi một số hành động rườm rà như hỏi quá nhiều, hỏi lại khi phản hồi không hợp lệ quá nhiều lần,

Tiêu đề	Hệ thống xây dựng Chatbot theo kịch bản
Thể loại	Graduation project