--- title: "Hệ thống gồm những gì" description: "Ba dịch vụ đứng sau console CloudFly Helpdesk, đường đi của một tin nhắn qua chúng, và vì sao mất kết nối realtime không có nghĩa là mất tin nhắn." updated: "2026-08-28" audience: [agent, administrator] source: "https://helpdesk-docs.svr1.feedapp.click/khai-niem/kien-truc-tong-quan" --- Console bạn mở mỗi sáng là một trong ba dịch vụ chạy độc lập với nhau. Biết ba dịch vụ đó chia việc thế nào là đủ để đọc đúng hai tình huống quen thuộc. Một là tin của đồng nghiệp hiện ra ngay khi họ vừa gửi. Hai là thanh trạng thái báo mất kết nối. Trang này mô tả hình dạng hệ thống ở mức người dùng console cần, không phải ở mức người triển khai. Cổng mạng, biến môi trường và cách dựng nằm trong tệp `README.md` của mã nguồn. ## Ba dịch vụ, ba việc khác nhau [#ba-dịch-vụ-ba-việc-khác-nhau] | Dịch vụ | Việc của nó | Thứ nó không làm | | ----------------------- | ------------------------------------------------------------------ | --------------------------------------- | | Console (giao diện web) | Vẽ hàng đợi, gửi yêu cầu REST, giữ một kết nối Socket.IO | Không đọc thẳng cơ sở dữ liệu | | `api-engine` | Nhận mọi yêu cầu REST và là nơi **duy nhất** ghi vào cơ sở dữ liệu | Không tự đẩy dữ liệu xuống trình duyệt | | `ws-engine` | Phát lại sự kiện xuống các trình duyệt đang mở đúng hội thoại | **Không bao giờ** ghi vào cơ sở dữ liệu | Ba dịch vụ không dùng chung mã nguồn. Chúng gặp nhau ở đúng hai chỗ: Postgres, nơi mọi thứ được lưu, và Redis, đường truyền tin nội bộ giữa hai engine. Khung chat của khách trên website cũng nói chuyện với `api-engine`, nhưng qua cửa riêng của widget và bằng token riêng. Cùng một dữ liệu, hai lối vào khác nhau, và mỗi lối vào có phạm vi đọc của nó. ## Đường đi của một tin nhắn [#đường-đi-của-một-tin-nhắn] 1. Khách hoặc bạn gửi một tin. Yêu cầu đi tới `api-engine` bằng REST. 2. `api-engine` ghi tin vào Postgres và đợi ghi xong. 3. Ghi xong, nó phát sự kiện `message.created` lên kênh `chat_events` của Redis. 4. `ws-engine` đang nghe kênh đó, đổi thành sự kiện `new_message` và đẩy vào phòng của đúng hội thoại. 5. Mọi trình duyệt đang mở hội thoại đó chèn tin vào khung chat, không tải lại trang. Đó là lý do một tin nhắn xuất hiện gần như tức thì trong cửa sổ của đồng nghiệp: nó không đợi ai bấm làm mới, nó đi theo đường Redis xuống socket. ## Ghi trước, phát sau [#ghi-trước-phát-sau] Thứ tự ở bước 2 và bước 3 là một cam kết của hệ thống, không phải chuyện tình cờ. Sự kiện realtime ra đời **sau** khi bản ghi đã nằm trong cơ sở dữ liệu. Hai hệ quả đáng nhớ. Thứ nhất: tin nào bạn thấy nhảy vào khung chat thì tin đó đã được lưu, tải lại trang vẫn còn. Thứ hai: chiều ngược lại không tồn tại, vì `ws-engine` không có quyền ghi, nên không có tin nào "chỉ sống trên socket". > **Lưu ý:** Rớt kết nối realtime là mất dòng cập nhật tức thì, không phải mất dữ liệu. > Tin vẫn được ghi như thường và vẫn hiện đủ khi bạn mở lại hội thoại, vì lần > mở đó đọc qua REST chứ không đọc từ socket. ## Cái gì ngừng chạy thì bạn thấy gì [#cái-gì-ngừng-chạy-thì-bạn-thấy-gì] | Thành phần ngừng chạy | Điều bạn quan sát được | | ---------------------- | ----------------------------------------------------------------------------------------- | | `ws-engine` hoặc Redis | Tin vẫn gửi và vẫn lưu; các cửa sổ đang mở thôi tự cập nhật, phải tải lại để thấy tin mới | | `api-engine` | Không gửi được tin, không mở được hàng đợi: mọi yêu cầu REST đều đi qua đây | | Postgres | Không dịch vụ nào làm việc được, vì đây là nơi giữ toàn bộ dữ liệu | Bảng này cho bạn cách mô tả sự cố mà người vận hành dùng được ngay. "Gửi được nhưng không thấy tin của người khác" và "không gửi được" là hai vùng hỏng khác nhau. ## Đọc tiếp [#đọc-tiếp] * [Vai trò và quyền theo tính năng](/khai-niem/vai-tro-va-quyen) * [Hộp thư chung và kênh kết nối](/khai-niem/inbox-va-kenh) * [Bảng thuật ngữ](/khai-niem/thuat-ngu)