多人協作在線文檔的概念，最早由Google Docs帶入中國。但實際上，在日常工作中，與團隊的其他人進行協作是一種在常見不過的工作方式。
由于工作分工、工作進展的不同，團隊內部的信息往往需要及時同步，然而伴隨著團隊經營規模的不斷擴大，在線協同、多人協作，以及軟件項目管理等問題將會接踵而至，成為制約企業高效發展的瓶頸。
這些問題，通常表現為：
- 跨部門、地區協作不便
- 過度依賴文件夾共享的形式，不能確保文檔的安全性
- 沒法紀錄和體現職工對文本文檔的意見和評價
- 文檔記錄發生變更時，無法及時通知到相關部門和員工
- 文檔無法在線協同編輯，缺失必要的流程管控
- 多人共同編輯一個文檔，無法留存修改記錄和歷史版本
針對上述問題，目前最佳的解決方案是：使用一款可多人在線協同辦公的軟件或工具。市面上，這類軟件有很多，比如國外的Google Docs、Office365，以及國內的騰訊文檔、石墨文檔、有道云協作等。
本文將不再過多贅述這類成品軟件，而是深入協同辦公系統的實現原理，從企業IT管理者的角度出發，深入研究多人協作的形式、基礎和難點，分析一款開發工具應具備怎樣的特點，才是實現多人協作“在線excel”系統的關鍵。
以下內容，節選自葡萄城公開課《如何實現可多人協作的“在線excel”系統？》，歡迎大家提前預約。
多人協作的形式：歷史與發展
多人協作的歷史十分悠久，起源于靜態的多人協作模式，即每個人先完成自己的工作，然后再進行匯總。
靜態的多人協作模式
- 遞增式協作
- 郵件：你來我往
- 論壇：跟帖回復
- 獨占式協作
- 文檔傳遞
- 微軟VSS
- 合并式協作
- SVN
- Git
- diff，patch，merge指令
常見的靜態多人協作方式
從靜態到動態
靜態協作的比喻
- 拼接畫
- 積木
靜態協作的特點
- 多版本
- 塊操作
- 有協作動作
靜態協作的缺點
- 版本碎片化
- 缺乏時效性
- 協作動作成本高
靜態多人協作的成本，會隨著加入人數和項目的復雜度呈幾何級數的增長。因此，對于企業來說，急需一種無協作動作、唯一版本、版本可控的無協作成本模式，即動態多人協作模式。
動態的多人協作
動態協作的比喻
- 一起畫黑板
動態協作的特點
- 唯一版本
- 原子操作
- 無協作動作
動態協作的優點
- 版本可控
- 實時
- 無協作成本
典型產品
- Office Online
- 石墨
- OnlyOffice
多人協作的基礎：原理與架構
任何信息，無論其是什么展現形式，如果要做到多人實時編輯與展現，只需要實現以下三步而已：
- 操作化
- 可傳輸
- 可還原
舉例說明多人協作的實現方式
操作化
操作化，指任何信息都可以轉換為一組操作的集合。很容易理解，但它仍有不少值得思考的點：
1. 分割與組合
· 如何保證：信息的所有變化都可以分解為操作的集合？反之，操作如何覆蓋出信息的所有變化？
· 分割的顆粒度如何決定？
? 粗一點？
? 細一點？
? 如何兼顧解釋性與擴展性？
2. 絕對操作與相對操作
· 絕對操作
? 針孔打印機的完美世界
? 打印機時代的編輯噩夢
- 相對操作
? 4K電視不是夢
? 為什么數字電視穩定性不如模擬電視
- 絕對操作與相對操作比喻：時間與空間的互換
- 使用一款開發工具：SpreadJS，實現操作化的優勢：
- 好用的指令集，保證覆蓋信息的全部變化與操作的集合
- 經過實踐驗證的顆粒度，完美兼顧解釋性與擴展性平衡
可傳輸
可傳輸，就是指操作有辦法通過網絡傳輸給其他終端。實現動態多人協作，需要考慮以下幾點：
- 傳輸內容
- 原始文本
? 清晰
? 冗余
- 壓縮技術
? 邏輯壓縮
? 協議壓縮
? 手動壓縮
- 網絡協議
- Socket
? TCP
? UDP
- HTTP
- WebSocket
- QoS（Quality of Service，服務質量）
- 快速失敗
- 自動回滾
- 自動重連
- 自動恢復
可還原
可還原，就是指接收到來自網絡的操作消息后，可以在本地完全一致地再次執行該操作。可還原包括了：
- 絕對操作的還原
- 控制體積
- 合理的提示
- 相對操作的還原
- 嚴格的順序性
- 從源頭保障順序性
- 順序性的補救
- 本地操作的還原
- 過濾收到的操作集合
- 從源頭細化操作顆粒
- 本地保存本地執行
- 無入侵的還原
- 定義入侵
- 排除入侵
- 千人千面
多人協作的難點：亂序與沖突
亂序
亂序的表現形式如下圖，小明在客戶端執行了一系列操作，傳遞到服務器時發生亂序，導致小花看到了截然不同的信息：
為了解決亂序問題，可以嘗試以下方法：
1. 用性能換取順序正確——基于協議
2. 用性能換取順序正確——基于回執
兩種方法的優缺點
- 基于協議
? 優點
· 可靠，歷經考驗
· 簡單，無需開發
? 缺點
· 資源開銷高
· 必須整套使用
- 基于回執
? 優點
· 自主可控，按需開發
· 資源開銷可控
? 缺點
· 需要自己投入開發
· 應用層邏輯控制使得網絡復雜度向外蔓延
· 復雜度帶來維護成本
基于亂序處理方法的總結
網絡不是絕對可靠的，為了實現相對可靠，需要付出一定的代價，企業需要考慮的是：如何衡量所付出的代價與產出成正比。
沖突
比亂序更高級的一種表現形式，存在多向、多維度等問題。
如何避免錯誤的蔓延？
原則：任何一次不一致，都會導致后續的操作基于錯誤的信息進行，從而不斷擴大錯誤，造成無法收拾的結果。因此，不一致是不能被容忍的。
解決辦法：
- 嚴格一致性：獨占
- 最終一致性：檢查與修復
- 非技術手段：設計與提示
嚴格的一致性
獨占就是同一時間同一范圍只能由一人操作。
- 范圍（以SpreadJS為例）
- 整個表格，類似VSS
- 工作表
- 單元格范圍
- 排他性
- 獨占沖突時，必有一方被彈開
- 直到占有者解開，不然無法占用
- 占用前無法操作
- 原理和鎖基本一致
- 優點
- 可以確保嚴格一致性，不會產生多版本的錯誤累積
- 比起修復恢復這類彌補手段，一開始就不出錯的成本最低
- 邏輯清楚簡單，開發維護成本低
- 缺點
- 靜態協作的味道
- 獨占動作嚴重影響體驗
- 大幅降低協作效率
- SpreadJS提供的支持
- 鎖定工作表
- 鎖定單元格
最終一致性
基于唯一正確順序，察覺客戶端的錯誤，撤銷錯誤操作后重新執行正確的操作。
- 唯一正確
- 服務器到達順序
- 協作邊界分流
- P2P 選舉算法
- 察覺錯誤
- 服務器回執id
- 服務器回執操作，MS
- 撤銷錯誤
- 撤銷到錯誤發生前的一步操作的結果
- 利用SpreadJS的撤銷功能
- 利用操作版本快照
- 重新執行
- 操作隊列需保存
- 區分好無感知執行與顯式執行
非技術手段
技術手段追求錯誤0發生，而非技術手段則可以降低錯誤發生的可能性。
- 選中框
- 非常重要但不顯眼
- 人性化的獨占
- 操作的預期
- 協作感
- SpreadJS提供高度可自定義的邊框
- 協作設計
- 設計協作區域與合并手段
- 設置權限
- SpreadJS提供幾乎Excel的所有公式
- SpreadJS提供了工作表和單元格鎖定功能
- 單向協作
- 區分單向與雙向協作的場景
- 對單向協作盡量放開
- 對雙向協作嚴謹設計
針對多人協作難點的總結
首先，可以明確一點：SpreadJS完全可以用作多人協作系統開發的組件。原因在于：
? SpreadJS的產品質量是毋庸置疑的
? SpreadJS在設計之初，便考慮到了多人協作的可能，而除此之外，絕大多數的前端產品都不是為了多人協作而設計的
? 多人協作需要中心系統的支持，SpreadJS基于純前端的體系架構可以很容易的嵌入系統開發，而無需過多考慮與原生系統的兼容性，這是常規組件是無法做到的
? 要實現多人協作，需要投入一定的開發成本，SpreadJS作為一款開發工具，可以有效幫助開發人員減輕代碼量
多人協作表格的本質：
? Server – Clients 中心系統，類似數值敏感的小型網游
? 任何這類系統都是在體驗和正確性中尋求平衡
多人協作表格的特點：
? 表格的數值敏感性高于網游，數據操作和存儲的挑戰更大
? 表格的計算復雜度更高，尤其涉及復雜公式嵌套與全量統計篩選
? Web存在天花板，所以復雜的頁游并不多見，端游較多
對SpreadJS這類開發工具/組件的展望與期待
1. SpreadJS 已經可以很好地支持多人協作的最終一致性。如果能支持多人多撤銷隊列，或者撤銷重做自定義，那么就可以給用戶提供更加易用且多樣化的體驗效果，從此絲般順滑不是夢。
2. SpreadJS的絕大部分功能是支持命令的，這使得操作化變得更簡單。如果SpreadJS能開放命令自定義，便可以讓自主控制顆粒度成為可能，用戶可以針對具體的業務邏輯做出更加精細化的操作轉換，大幅提高協作效率。
3. SpreadJS不僅在數據錄入、數據填報等方面表現出強大的功能，其各類統計分析與圖形化手段也是一個不少，一旦明年的透視表功能上線，使用SpreadJS開發在線協同系統的數據商業價值將更易體現，用戶將體驗到“表格”無限的魅力與威力。
4. 表格在多人協作中的數據量增長速度比單人使用時快得多，希望SpreadJS可以支持更大的數據量，尤其是在大數據量情況下仍舊保持操作的性能與體驗。
以上就是本期公開課《如何實現可多人協作的“在線excel”系統？》的部分摘要，如果您對在線協作系統的開發感興趣，點擊文末了解更多，預約課程。
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。