CloudFly Helpdesk

Hệ thống gồm những gì

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.

Xem .mdMở llms.txt

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

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.IOKhông đọc thẳng cơ sở dữ liệu
api-engineNhận mọi yêu cầu REST và là nơi duy nhất ghi vào cơ sở dữ liệuKhông tự đẩy dữ liệu xuống trình duyệt
ws-enginePhát lại sự kiện xuống các trình duyệt đang mở đúng hội thoạiKhô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

  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

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".

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ì

Thành phần ngừng chạyĐiều bạn quan sát được
ws-engine hoặc RedisTin 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-engineKhông gửi được tin, không mở được hàng đợi: mọi yêu cầu REST đều đi qua đây
PostgresKhô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

On this page