作為一名軟件工程師，我曾經堅信“功能為王”。功能夠強，界面夠炫，用戶自然會來。然而，真正上線運營一款客服系統后我才深刻明白：功能可以讓用戶試用，但穩定性和安全性才是讓用戶留下來的根本。

一、前言：為什么穩定與安全如此重要

作為一名軟件工程師，我曾經堅信“功能為王”。功能夠強，界面夠炫，用戶自然會來。然而，真正上線運營一款客服系統后我才深刻明白：

功能可以讓用戶試用，但穩定性和安全性才是讓用戶留下來的根本。

客服系統的特殊性在于：它與客戶業務直接掛鉤，是一線成交和售后的橋梁。你永遠無法預知用戶什么時候打開網頁，發出一句“請問在嗎？”
你也無法承受這種情況下系統突然宕機、消息延遲、甚至數據泄露的代價。

我曾遇到過這樣的真實場景：

• 某次凌晨系統崩潰了，第二天早上一查，客戶錯失了上百條訪客咨詢；
• 有訪客反饋聊天記錄丟失，客服追蹤不到歷史對話；
• 更危險的是，有腳本試圖通過 WebSocket 枚舉接口，嘗試篡改聊天內容。

這些事故帶來的不只是客戶的信任危機，更是我自己作為工程師的羞恥感。那一刻我意識到：

客服系統的“核心競爭力”不在于功能列表，而在于可靠的連接能力與構筑用戶信任的系統安全性。

于是，我開始了漫長的“偏執工程”之路，從通信底層，到系統架構，再到攻擊防護，逐步將這款客服系統打磨成一個能夠支撐海量并發、全年無故障運行的系統。今天的這篇文章，我將拆解我在構建這套系統時的關鍵思路、架構演進與安全防御策略，并分享核心代碼邏輯。

如果你也正在開發客服系統，或任何面向公眾的實時在線系統，我相信這篇文章能為你帶來一些啟發。

---

二、整體架構設計：分布式、模塊化、可私有化部署

在線客服系統的底層復雜度，遠比“頁面上彈個對話框”要高得多。它必須支持高并發訪問、低延遲消息傳輸、實時狀態同步、聊天歷史歸檔、AI協同處理……這些能力若全部耦合在一個服務中，只會變得臃腫不堪、難以維護。

因此，我一開始就以模塊化、可插拔的方式構建整套系統，同時將**“極簡私有化部署”**作為第一優先級考慮。

---

1. 服務劃分與通信機制

系統核心劃分為以下幾個服務模塊：

服務模塊	說明
Gateway 網關服務	統一入口，負責 WebSocket/HTTP 接入與轉發
ChatService	核心會話處理邏輯，消息存儲、分發、狀態維護
AgentService	客服端處理邏輯，身份驗證、消息調度等
AdminService	后臺管理模塊（租戶管理、配置等）
AIService（可選）	智能客服接口（支持對接 GPT、本地模型等）

模塊之間通過 HTTP / gRPC 調用，通信協議清晰分離，便于部署與擴展。

? 每個模塊都可以單獨運行，支持最小部署、增量升級。

---

2. 私有化部署，從未如此簡單

客戶部署的場景千差萬別：有的公司要求內網運行，完全離線，有的則希望運行在自有服務器上并對接內部系統。因此，我在系統設計上做了這些關鍵設計：

? 一鍵安裝腳本

我提供了一個一鍵安裝腳本，客戶只需在一臺干凈的 Ubuntu 服務器上運行以下命令：

curl -sSLO https://files.shengxunwei.com/kf/installscript/install.sh && chmod +x install.sh && bash install.sh

該腳本將自動完成：

• 所有依賴組件安裝（.NET、MySQL、Redis、Nginx 等）
• Web 管理后臺 + 訪客端 + 客服端程序部署
• 數據庫初始化與默認配置
• 啟動服務并輸出訪問地址

????? 無需懂容器、無需配置環境，5分鐘即可在自己服務器跑起來。

? 支持 寶塔面板/aaPanel 部署

為了迎合國內外廣泛使用的運維面板，我還提供了非常詳細的在線部署說明書。

https://docs.shengxunwei.com

---

3. 數據隔離與多租戶支持

我們的系統原生支持多租戶架構，每個租戶（站點）擁有：

• 獨立的訪客數據、聊天記錄、設置項
• 獨立的 API 密鑰與訪問權限
• 獨立的部署入口（支持分域名綁定）

這樣部署出來的系統將自動啟用“僅一個租戶運行”模式，適用于 SaaS 客戶轉為私有部署的遷移場景。

---

4. 數據存儲結構與安全設計

為了確保聊天數據的安全性和可控性，系統采用以下策略：

• 關系型數據庫存儲結構化數據（MySQL/PostgreSQL）
• Redis 緩存在線狀態、聊天室映射等高頻讀寫數據
• 可選啟用 Elasticsearch 存儲全文聊天記錄，支持搜索功能
• 所有聊天記錄、用戶信息默認加密存儲（可選擇開啟透明加解密模塊）

數據庫結構也保持高度解耦，例如：

CREATE TABLE ChatMessage (
    Id BIGINT PRIMARY KEY,
    SessionId BIGINT,
    SenderType ENUM('Visitor', 'Agent', 'AI'),
    Message TEXT,
    Timestamp DATETIME,
    TenantId VARCHAR(64)
);

?? 多租戶隔離，支持單租戶數據導出與遷移。

---

5. 私有部署與SaaS共存：一套代碼，雙模式運行

最后一個關鍵點是，我們的架構支持“SaaS 與私有化統一代碼、統一接口、統一架構”。

只需在配置文件中切換運行模式：

{
  "DeploymentMode": "SelfHosted", // 或 "SaaS"
  "TenantId": "yourcompany"
}

整個系統會自動切換為私有化部署邏輯，例如跳過租戶切換、中控平臺接口等。

---

好的，以下是第三章節：極致穩定性背后的關鍵策略的完整正文草稿，突出工程實踐與技術細節，適合在技術社區中引發共鳴與轉發：

---

三、極致穩定性背后的關鍵策略

系統是否穩定，從不取決于“正常情況下是否運行良好”，而在于 “極端情況下是否還能穩住”。

我們在設計客服系統時，將“極致穩定性”視為第一優先目標，圍繞“消息可靠性、服務可用性、系統自愈能力”三個維度，做了大量工程實踐。

---

1. 斷線重連與會話續接機制

客服系統天然基于WebSocket建立持久連接，而用戶的網絡環境往往并不穩定：

• 4G 網絡頻繁切換基站
• 公司 WiFi 會定期斷流
• 瀏覽器崩潰或刷新頁面

如果處理不好，就會出現：

• 消息丟失
• 會話中斷
• 客服誤以為訪客離開

? 我的設計思路：

• WebSocket 心跳檢測 + 客戶端 reconnect 重連機制
• 每條消息帶唯一 MessageId

?? C# 示例：確認機制簡化代碼

// 接收消息
public async Task OnMessageReceived(string tenantId, string sessionId, string messageId, string content)
{
    SaveToDatabase(sessionId, messageId, content);
    await _messageCache.Cache(sessionId, messageId); // 緩存確認
}

// 客戶端斷線后重連
public async Task ResumeSession(string sessionId, string id)
{
    var messagesToResend = await _messageCache.GetMessages(sessionId, id);
    foreach (var msg in messagesToResend)
    {
        await SendToClient(sessionId, msg);
    }
}

這種機制在極端情況下（如重連10秒后）依然可以精準恢復未讀消息，零丟失。

---

2. 服務節點可水平擴展，支持高并發

我們使用了以下方式支持高并發與動態擴展能力：

• 所有狀態（連接、消息、隊列）都存于 Redis，服務節點無狀態化，支持隨時橫向擴容
• WebSocket連接統一由 Gateway 層接入，轉發至后端節點
• 消息發送支持“推拉結合”：關鍵節點用 Push，非活躍會話用 Pull 延遲拉取，節省資源

高可用架構部署圖（簡圖）：

┌────────────┐
│ Nginx LB   │
└────┬───────┘
     │
 ┌───▼─────┐     ┌──────────┐
 │ Gateway │ --> │ Redis Bus│
 └───┬─────┘     └──────────┘
     │
 ┌───▼────┐  ┌──────────┐  ┌──────────┐
 │ Node A │  │ Node B   │  │ Node C   │
 └────────┘  └──────────┘  └──────────┘

部署上完全支持 Kubernetes自動彈性擴容 或本地服務進程手動部署。

---

3. 灰度發布與無感升級能力

在 SaaS 模式下，任何一次“閃斷”都可能導致客服斷線、用戶投訴。為此，我們設計了多種升級方式：

• 藍綠部署策略：A組節點跑舊版本，B組跑新版，新訪客逐步切流
• 熱更新機制：聊天邏輯支持局部熱加載，不重啟整個服務
• 零停機升級腳本：數據庫結構變更使用 EF Core Migrations + 向后兼容設計

示例：灰度流量控制策略

public bool IsInNewVersionGroup(string visitorId)
{
    // 對訪客哈希值做分組
    return visitorId.GetHashCode() % 100 < CurrentGrayPercent;
}

我們甚至為每個租戶設計了獨立版本配置，允許某些重要客戶暫緩升級，以確保穩定性優先。

---

4. 全鏈路健康檢測與熔斷機制

穩定性從來不是“上線后就不管了”，而是要持續監測與自我修復。

我們的監控體系包含：

• Prometheus 采集：連接數、請求耗時、異常率、WebSocket延遲等
• Grafana 可視化：關鍵KPI預警、趨勢圖
• 熔斷策略：某服務響應異常率連續高于閾值，則從集群中摘除（基于 Polly）
• 自動重啟機制：服務僵死時，Supervisor/NSSM 會自動拉起進程

示例：Polly 熔斷器

var policy = Policy
    .Handle<Exception>()
    .CircuitBreakerAsync(
        handledEventsAllowedBeforeBreaking: 5,
        durationOfBreak: TimeSpan.FromSeconds(30)
    );

通過這些機制，即便某個節點掛掉，系統整體依然可服務；即便出現慢請求，系統也能降級繼續運行。

---

四、安全性設計：從通信到權限的全方位加固

客服系統本質上就是一個“通道”：連接訪客和企業、連接瀏覽器和數據庫、連接公網和內網。而每一個連接，都是潛在的攻擊入口。

在沒有安全設計的系統中，攻擊者可以輕松做到：

• 篡改訪客身份冒充他人
• 攔截并偽造聊天內容
• 掃描接口暴力探測敏感數據
• 越權調用后臺接口，訪問他人數據

我們采取了 端到端全鏈路安全防護策略，從通信加密、簽名驗證、權限管理、到系統隔離，確保客服系統能真正做到“數據不泄露，接口不越權，攻擊不生效”。

---

1. 所有通信必須加密：HTTPS + WSS 強制開啟

我們默認強制啟用 HTTPS 與 WebSocket Secure (WSS)，并在服務端檢測是否通過加密訪問。部署時提供免費 Let's Encrypt 證書自動簽發機制：

certbot --nginx -d chat.example.com

服務端校驗：

if (!context.Request.IsHttps)
{
    context.Response.StatusCode = 403;
    return;
}

? 無論是 API 接口還是 WebSocket 通信，均不允許明文傳輸。

---

2. 接口簽名驗證機制：防篡改、防重放

訪客端初始化連接或提交數據時，必須帶上簽名參數。簽名邏輯如下：

• 使用訪問密鑰 AppSecret 對參數進行 HMAC-SHA256 簽名
• 客戶端提交 timestamp + signature 參數
• 服務端校驗簽名合法性，并拒絕過期/偽造請求

示例：C# 簽名校驗邏輯

public bool VerifySignature(IQueryCollection query, string secret)
{
    var timestamp = query["timestamp"];
    var signature = query["signature"];

    if (string.IsNullOrEmpty(signature) || string.IsNullOrEmpty(timestamp))
        return false;

    var raw = $"timestamp={timestamp}";
    var expected = HmacSha256(raw, secret);

    return expected.Equals(signature, StringComparison.OrdinalIgnoreCase);
}

JavaScript 生成簽名（訪客端）：

const raw = `timestamp=${timestamp}`;
const signature = CryptoJS.HmacSHA256(raw, appSecret).toString();

? 該機制有效阻止了 URL 參數篡改、重放攻擊、偽造請求等問題。

---

3. 多級權限模型：訪客、客服、管理員分權隔離

我們定義了 3 類身份角色：

角色	權限范圍
訪客 Visitor	僅能訪問本人會話、消息發送
客服 Agent	查看/管理其所屬租戶內會話
管理員 Admin	管理租戶信息、配置、系統參數等

所有接口均基于 ClaimsIdentity 進行權限授權。例如：

[Authorize(Roles = "Agent,Admin")]
[HttpPost("/api/message/send")]
public IActionResult SendMessage(MessageDto dto) { ... }

?? 即使知道 API 地址，訪客也無法訪問客服功能；客服也無法訪問非本租戶數據。

---

4. 防御常見攻擊：XSS、CSRF、WebSocket濫用

1）XSS 防護

• 服務端統一對 HTML 內容進行清洗
• 客戶端聊天框內容使用 DOMPurify 或 Vue 插件過濾

2）CSRF 防護

• 所有狀態寫操作必須帶 CSRF Token 或 Authorization Header
• 管理后臺啟用雙 Cookie 簽名機制（防釣魚）

3）WebSocket 濫用防護

攻擊者可能使用爬蟲或腳本持續發起 WebSocket 連接，造成資源耗盡。我們通過以下策略防御：

• 限制每個 IP 每分鐘連接數（如使用 nginx + limit_conn）
• 每個連接建立時必須驗證有效 siteCode 和簽名
• 非法連接直接 context.Response.StatusCode = 400 并關閉

示例代碼片段：

if (!IsValidSiteCode(siteCode) || !VerifySignature(...))
{
    context.Response.StatusCode = 400;
    return;
}
await context.AcceptWebSocketAsync();

---

5. 多租戶數據隔離 + 防橫向越權

系統默認運行于多租戶模式，所有數據訪問邏輯必須攜帶 TenantId，并通過租戶授權驗證。

服務端數據庫層：

SELECT * FROM ChatMessage WHERE TenantId = @TenantId AND SessionId = @SessionId

代碼中使用攔截器強制注入：

public override int SaveChanges()
{
    foreach (var entry in ChangeTracker.Entries())
    {
        if (entry.Entity is ITenantOwned owned)
            owned.TenantId = CurrentTenantId;
    }
    return base.SaveChanges();
}

即使開發者忘記寫 where，也不會跨租戶訪問他人數據。

---

五、實戰部署策略：讓每一個用戶都用得放心

一個優秀的客服系統，不能只停留在“線上跑得好”。它還必須：

• 部署簡單 —— 讓用戶能快速上線使用；
• 運行安全 —— 能長期穩定運行在客戶自己的服務器上；
• 數據可控 —— 所有聊天數據、配置都在客戶手中，企業“可見、可管、可控”。

這也是為什么我們一直堅持把**“私有化部署”作為一等公民支持**。

---

1. 為什么堅持做“真正可控”的私有化部署

市面上很多號稱支持私有部署的系統，實際上：

• 要求公網訪問控制臺或依賴云服務
• 核心模塊仍在云端（如AI、賬號中心等）
• 數據依舊回傳到云服務器，用戶無感知

而我們提供的私有化部署方案，是“純凈離線”的：

? 不依賴任何第三方云服務
? 可部署在 內網服務器、虛擬機、國產主機 上
? 全部數據、日志、配置、密鑰 存儲在本地機器中
? 可選擇 開源部分模塊 供客戶安全審計

?? 對于政企客戶、金融、醫療等對數據安全有高要求的行業，這是基本底線。

---

2. 部署方式：圖形界面 vs 命令行一鍵包

我們提供兩種部署方式，覆蓋不同技術水平的用戶：

?? 方式一：aaPanel 圖形化一鍵部署

適合中小企業或不具備 DevOps 能力的客戶。

• 可通過“插件市場”在線安裝客服系統
• 完整支持服務初始化、數據庫配置、SSL 證書簽發
• 所有運行服務均通過 Supervisor 守護，異常自動重啟

?? 方式二：Shell 腳本一鍵部署（離線包支持）

適合 DevOps/IT 運維團隊，具備腳本部署能力的場景。

curl -sSO https://files.shengxunwei.com/kf/installscript/install.sh
chmod +x install.sh
./install.sh --selfhost --port 8080 --no-cloud

• 離線環境只需提前準備安裝包（或內網鏡像源）
• 支持指定安裝目錄、端口、租戶ID等參數
• 安裝完畢后自動輸出訪問地址和登錄賬號密碼

---

3. 安全隔離策略：保障本地部署不被“污染”

在私有部署環境下，我們額外做了以下安全加固：

? 完全屏蔽公網回傳

• 所有自動上報、升級檢查、遙測邏輯 默認禁用
• 所有 API 調用目標域名均可配置，默認僅限本機訪問
• 部署包內含完整靜態資源，不依賴 CDN

? 進程級隔離 + 網絡分區建議

• 每個服務模塊運行在獨立進程（非子線程）
• 支持使用 Docker / systemd / NSSM 等運行方式
• 強烈建議將服務運行在 獨立 VLAN 或 DMZ 區域，通過反向代理轉發

? 管理員登錄日志 + 訪問審計

• 所有登錄嘗試均記錄 IP、UA、來源信息
• 系統后臺內置“操作審計日志”模塊，支持導出歸檔

示例：登錄日志結構

{
  "username": "admin",
  "ip": "192.168.1.15",
  "success": true,
  "timestamp": "2025-07-09T10:24:31Z",
  "source": "WebAdmin"
}

---

4. 部署后運行保障：自檢機制 + 異常提醒

我們內置了一套輕量級自檢機制，部署后首次運行將自動檢測：

• 數據庫連接是否可用
• Redis 是否正常連接
• WebSocket 接入是否通暢
• 系統關鍵目錄讀寫權限是否正確

此外，提供可選的運行時健康檢查 API：

GET /api/healthz

返回示例：

{
  "redis": "OK",
  "database": "OK",
  "websocket": "OK",
  "version": "2.6.4-selfhost"
}

該接口可對接監控平臺（如 Zabbix、UptimeRobot、Prometheus）實現異常自動告警。

---

5. 數據導出 + 全量備份支持

客戶隨時可以導出：

• 所有會話記錄（JSON / CSV / SQL）
• 客服賬號配置
• 系統參數備份文件

并且提供完整數據遷移腳本，支持：

• SaaS → 私有化
• 私有化 → 新服務器遷移
• 私有化恢復歷史快照

---

獨立者的產品成果

https://kf.shengxunwei.com

可全天候 7 × 24 小時掛機運行，網絡中斷，拔掉網線，手機飛行模式，不掉線不丟消息，歡迎實測。

訪客端：輕量直觀、秒級響應的溝通入口

訪客端是客戶接觸企業的第一窗口，我們精心打磨每一處交互細節，確保用戶無需任何學習成本即可發起對話。無論是嵌入式聊天窗口、懸浮按鈕，還是移動端自適應支持，都實現了真正的“即點即聊”。系統支持智能歡迎語、來源識別、設備類型判斷，可自動記錄訪客路徑并呈現于客服端，幫助企業更好地理解用戶意圖。在性能方面，訪客端采用異步加載與自動重連機制，即使網絡波動也能保障消息順暢送達，真正做到——輕量不失穩定，簡單不失智能。

客服端軟件：為高效率溝通而生

客服端是客服人員的作戰平臺，我們構建了一個專注、高效、響應迅速的桌面級體驗。系統采用多標簽會話設計，讓客服可同時處理多組對話；訪客軌跡、歷史會話、地理位置、設備信息、來源渠道等關鍵信息一目了然，協助客服快速做出判斷。內置快捷回復、常用文件、表情支持和智能推薦功能，大幅降低重復勞動成本。同時，系統還支持智能分配、會話轉接、轉人工、自定義狀態等多種機制，保障團隊協作流暢，讓客服不僅能應對高峰，更能穩定交付滿意度。

Web 管理后臺：

Web 管理后臺是企業對客服系統的“駕駛艙”，從接入配置、坐席管理，到數據統計、權限控制，一切盡在掌握。你可以靈活設置接待策略、工作時間、轉接規則，支持按部門/標簽/渠道精細分配訪客，滿足復雜業務場景。系統還內置訪問監控、聊天記錄檢索、客服績效統計、錯失會話提醒等運營級功能，助力管理者洞察服務瓶頸，持續優化資源配置。支持私有化部署、分權限管理、日志記錄與數據導出，為追求安全性與高可控性的企業，提供真正“掌握在自己手里的客服系統”。

希望能夠打造： 開放、開源、共享。努力打造一款優秀的社區開源產品。

鐘意的話請給個贊支持一下吧，謝謝~