BinoLink 系统介绍
返回工作台

BinoLink 系统介绍

面向企业独立站的实时在线客服系统 · 部署形态：独立子域 chat.binobie.com

BinoLink 基于 Workerman 事件驱动常驻内存架构 构建：PHP 进程常驻、非阻塞 IO、单进程即可承载万级并发连接。 挂起的会话记录几乎不占用任何运行资源——真正的压力只来自「同时在线」的活跃连接，而这也正是本系统最游刃有余的地方。
2C2G实测部署规格（腾讯轻量）
5000-10000估算同时在线连接数
10-30KB单条 WebSocket 连接内存开销
<100ms常驻内存消息响应（无进程冷启）
架构核心：事件驱动，而不是「每个请求起一个进程」
  • Workerman 常驻进程：PHP 服务启动后一直驻留内存，消息收发走事件回调，没有传统 PHP-FPM「请求来→起进程→销毁」的开销；实测单 worker 常驻内存约 12MB。
  • WebSocket 全双工：客服与访客消息实时双向推送（wss 2346，Nginx 反向代理），配合 30s 心跳保活，无轮询浪费。
  • MySQL 仅做落盘：消息、会话、评分只写数据库，不在内存长期缓存；连接池复用，单条连接零驻留。
  • 广播成本可控：客服端在线推送（presence）、消息广播均定向分发，不做全连接无差别广播。
容量模型：挂起 500 个会话，和挂起 5 个，压力几乎一样
成本类型是否随会话数增长说明
挂起会话（DB 记录）几乎不增长会话列表 LIMIT 30、无连接不驻留内存、30s 轮询固定开销——500 条「没人在聊」的记录对服务零压力
在线连接（WS 连接）线性增长每条连接约 10-30KB 内存，这是唯一实质成本
消息广播 / SQL 写入按活跃度增长只在真有消息时产生，与历史挂起数无关
结论：真正决定承载量的是「同时在线」而非「累计会话」。按 2C2G + PHP memory_limit 128M 估算，理论可同时支撑 5000-10000 在线连接；企业独立站同时在线几十~一两百人，余量 100 倍以上。
扩容路径：三件套（当前用不到，预留）
  • memory_limit 128M → 512M：单进程内存上限 ×4，在线承载量直接翻倍。
  • WORKER_COUNT 1 → 2：多进程 + 连接亲和，连接横向拆分。
  • MAX_TOTAL_CONNECTIONS：全局连接数上限，配合 Nginx 做容量熔断。
特色功能
Widget 一键嵌入

shadow DOM 注入式聊天挂件，一段 script 嵌入任意页面；断线自动重连（5 次退避 + 30s 上限 + 切前台立即重连），访客无感。

自动分配 + 在线状态

新会话自动分给在线客服；客服在线状态实时同步（presence API），访客端优先连到「有人值守」的会话。

会话评分 + 回复模板

会话结束访客五星评价（可选留言）；客服常用话术模板一键插入，提升响应效率。

统计看板

会话量 / 消息量 / 首次响应时长 / 平均评分，7 天与 30 天双维度趋势，客服排行与渠道分布。

三层防滥用

单 IP 每小时 50 请求限流 + 单 IP 最多 5 条 WS 连接 + IP 黑名单（支持 CIDR，上限 200 条），后台可视化维护。

消息增强

图片 / 文件消息、离线消息补推、会话结束邮件归档（CSV 导出，UTF-8 BOM 兼容 Excel）。

稳定性设计：自愈 + 热配置 + 无感升级
  • 服务自愈：/api/health 健康检查 + watchdog 守护脚本，进程异常自动拉起；MySQL 连接健康检查 + 60s 心跳，死连接自动重连。
  • 热配置：业务配置存 chat_settings KV，DB 优先 + 10s 缓存——改客服上限、开关、限流阈值即时生效，无需重启。
  • 无感升级：SCHEMA_UPGRADES 版本化 + upgrade.html 一键执行；服务端改动仅需 restart -d，静态资源即传即生效。
  • 权限体系：admin / agent 两级角色，超管专属菜单裁剪；会话认领制，agent 只能看自己的会话。
技术栈
  • 服务端：PHP 7.4 + Workerman（WebSocket + HTTP API 单进程双协议）+ MySQL
  • 前端：原生 JS（零框架，白卡 + 统一侧边栏骨架，≤600px 全站抽屉化）+ shadow DOM Widget
  • 通信：wss 2346（Nginx 反代 /ws）+ REST API（Bearer Token 鉴权）
  • 部署：Nginx 静态 + 常驻进程守护；宝塔面板管理，SSH 免密一键重启