多人協(xié)作在線文檔的概念，最早由Google Docs帶入中國。但實際上，在日常工作中，與團隊的其他人進(jìn)行協(xié)作是一種在常見不過的工作方式。

由于工作分工、工作進(jìn)展的不同，團隊內(nèi)部的信息往往需要及時同步，然而伴隨著團隊經(jīng)營規(guī)模的不斷擴大，在線協(xié)同、多人協(xié)作，以及軟件項目管理等問題將會接踵而至，成為制約企業(yè)高效發(fā)展的瓶頸。

這些問題，通常表現(xiàn)為：

跨部門、地區(qū)協(xié)作不便

過度依賴文件夾共享的形式，不能確保文檔的安全性

沒法紀(jì)錄和體現(xiàn)職工對文本文檔的意見和評價

文檔記錄發(fā)生變更時，無法及時通知到相關(guān)部門和員工

文檔無法在線協(xié)同編輯，缺失必要的流程管控

多人共同編輯一個文檔，無法留存修改記錄和歷史版本

針對上述問題，目前最佳的解決方案是：使用一款可多人在線協(xié)同辦公的軟件或工具。市面上，這類軟件有很多，比如國外的Google Docs、Office365，以及國內(nèi)的騰訊文檔、石墨文檔、有道云協(xié)作等。

本文將不再過多贅述這類成品軟件，而是深入?yún)f(xié)同辦公系統(tǒng)的實現(xiàn)原理，從企業(yè)IT管理者的角度出發(fā)，深入研究多人協(xié)作的形式、基礎(chǔ)和難點，分析一款開發(fā)工具應(yīng)具備怎樣的特點，才是實現(xiàn)多人協(xié)作“在線excel”系統(tǒng)的關(guān)鍵。

以下內(nèi)容，節(jié)選自葡萄城公開課《如何實現(xiàn)可多人協(xié)作的“在線excel”系統(tǒng)？》，歡迎大家提前預(yù)約。

多人協(xié)作的形式：歷史與發(fā)展

多人協(xié)作的歷史十分悠久，起源于靜態(tài)的多人協(xié)作模式，即每個人先完成自己的工作，然后再進(jìn)行匯總。

靜態(tài)的多人協(xié)作模式

• 遞增式協(xié)作
• 郵件：你來我往
• 論壇：跟帖回復(fù)
• 獨占式協(xié)作
• 文檔傳遞
• 微軟VSS
• 合并式協(xié)作
• SVN
• Git
• diff，patch，merge指令

常見的靜態(tài)多人協(xié)作方式

從靜態(tài)到動態(tài)

靜態(tài)協(xié)作的比喻

• 拼接畫
• 積木

靜態(tài)協(xié)作的特點

• 多版本
• 塊操作
• 有協(xié)作動作

靜態(tài)協(xié)作的缺點

• 版本碎片化
• 缺乏時效性
• 協(xié)作動作成本高

靜態(tài)多人協(xié)作的成本，會隨著加入人數(shù)和項目的復(fù)雜度呈幾何級數(shù)的增長。因此，對于企業(yè)來說，急需一種無協(xié)作動作、唯一版本、版本可控的無協(xié)作成本模式，即動態(tài)多人協(xié)作模式。

動態(tài)的多人協(xié)作

動態(tài)協(xié)作的比喻

• 一起畫黑板

動態(tài)協(xié)作的特點

• 唯一版本
• 原子操作
• 無協(xié)作動作

動態(tài)協(xié)作的優(yōu)點

• 版本可控
• 實時
• 無協(xié)作成本

典型產(chǎn)品

• Office Online
• 石墨
• OnlyOffice

多人協(xié)作的基礎(chǔ)：原理與架構(gòu)

任何信息，無論其是什么展現(xiàn)形式，如果要做到多人實時編輯與展現(xiàn)，只需要實現(xiàn)以下三步而已：

操作化

可傳輸

可還原

舉例說明多人協(xié)作的實現(xiàn)方式

操作化

操作化，指任何信息都可以轉(zhuǎn)換為一組操作的集合。很容易理解，但它仍有不少值得思考的點：

1. 分割與組合

· 如何保證：信息的所有變化都可以分解為操作的集合？反之，操作如何覆蓋出信息的所有變化？

· 分割的顆粒度如何決定？

? 粗一點？

? 細(xì)一點？

? 如何兼顧解釋性與擴展性？

2. 絕對操作與相對操作

· 絕對操作

? 針孔打印機的完美世界

? 打印機時代的編輯噩夢

相對操作

? 4K電視不是夢

? 為什么數(shù)字電視穩(wěn)定性不如模擬電視

絕對操作與相對操作比喻：時間與空間的互換

使用一款開發(fā)工具：SpreadJS，實現(xiàn)操作化的優(yōu)勢：

好用的指令集，保證覆蓋信息的全部變化與操作的集合

經(jīng)過實踐驗證的顆粒度，完美兼顧解釋性與擴展性平衡

可傳輸

可傳輸，就是指操作有辦法通過網(wǎng)絡(luò)傳輸給其他終端。實現(xiàn)動態(tài)多人協(xié)作，需要考慮以下幾點：

傳輸內(nèi)容

原始文本

? 清晰

? 冗余

壓縮技術(shù)

? 邏輯壓縮

? 協(xié)議壓縮

? 手動壓縮

網(wǎng)絡(luò)協(xié)議

Socket

? TCP

? UDP

HTTP

WebSocket

QoS(Quality of Service，服務(wù)質(zhì)量)

快速失敗

自動回滾

自動重連

自動恢復(fù)

可還原

可還原，就是指接收到來自網(wǎng)絡(luò)的操作消息后，可以在本地完全一致地再次執(zhí)行該操作。可還原包括了：

絕對操作的還原

控制體積

合理的提示

相對操作的還原

嚴(yán)格的順序性

從源頭保障順序性

順序性的補救

本地操作的還原

過濾收到的操作集合

從源頭細(xì)化操作顆粒

本地保存本地執(zhí)行

無入侵的還原

定義入侵

排除入侵

千人千面

多人協(xié)作的難點：亂序與沖突

亂序

亂序的表現(xiàn)形式如下圖，小明在客戶端執(zhí)行了一系列操作，傳遞到服務(wù)器時發(fā)生亂序，導(dǎo)致小花看到了截然不同的信息：

為了解決亂序問題，可以嘗試以下方法：

1. 用性能換取順序正確——基于協(xié)議

2. 用性能換取順序正確——基于回執(zhí)

兩種方法的優(yōu)缺點

基于協(xié)議

? 優(yōu)點

· 可靠，歷經(jīng)考驗

· 簡單，無需開發(fā)

? 缺點

· 資源開銷高

· 必須整套使用

基于回執(zhí)

? 優(yōu)點

· 自主可控，按需開發(fā)

· 資源開銷可控

? 缺點

· 需要自己投入開發(fā)

· 應(yīng)用層邏輯控制使得網(wǎng)絡(luò)復(fù)雜度向外蔓延

· 復(fù)雜度帶來維護(hù)成本

基于亂序處理方法的總結(jié)

網(wǎng)絡(luò)不是絕對可靠的，為了實現(xiàn)相對可靠，需要付出一定的代價，企業(yè)需要考慮的是：如何衡量所付出的代價與產(chǎn)出成正比。

沖突

比亂序更高級的一種表現(xiàn)形式，存在多向、多維度等問題。

如何避免錯誤的蔓延？

原則：任何一次不一致，都會導(dǎo)致后續(xù)的操作基于錯誤的信息進(jìn)行，從而不斷擴大錯誤，造成無法收拾的結(jié)果。因此，不一致是不能被容忍的。

解決辦法：

嚴(yán)格一致性：獨占

最終一致性：檢查與修復(fù)

非技術(shù)手段：設(shè)計與提示

嚴(yán)格的一致性

獨占就是同一時間同一范圍只能由一人操作。

范圍(以SpreadJS為例)

整個表格，類似VSS

工作表

單元格范圍

排他性

獨占沖突時，必有一方被彈開

直到占有者解開，不然無法占用

占用前無法操作

原理和鎖基本一致

優(yōu)點

可以確保嚴(yán)格一致性，不會產(chǎn)生多版本的錯誤累積

比起修復(fù)恢復(fù)這類彌補手段，一開始就不出錯的成本最低

邏輯清楚簡單，開發(fā)維護(hù)成本低

缺點

靜態(tài)協(xié)作的味道

獨占動作嚴(yán)重影響體驗

大幅降低協(xié)作效率

SpreadJS提供的支持

鎖定工作表

鎖定單元格

最終一致性

基于唯一正確順序，察覺客戶端的錯誤，撤銷錯誤操作后重新執(zhí)行正確的操作。

唯一正確

服務(wù)器到達(dá)順序

協(xié)作邊界分流

P2P+選舉算法

察覺錯誤

服務(wù)器回執(zhí)id

服務(wù)器回執(zhí)操作，MS

撤銷錯誤

撤銷到錯誤發(fā)生前的一步操作的結(jié)果

利用SpreadJS的撤銷功能

利用操作版本快照

重新執(zhí)行

操作隊列需保存

區(qū)分好無感知執(zhí)行與顯式執(zhí)行

非技術(shù)手段

技術(shù)手段追求錯誤0發(fā)生，而非技術(shù)手段則可以降低錯誤發(fā)生的可能性。

選中框

非常重要但不顯眼

人性化的獨占

操作的預(yù)期

協(xié)作感

SpreadJS提供高度可自定義的邊框

協(xié)作設(shè)計

設(shè)計協(xié)作區(qū)域與合并手段

設(shè)置權(quán)限

SpreadJS提供幾乎Excel的所有公式

SpreadJS提供了工作表和單元格鎖定功能

單向協(xié)作

區(qū)分單向與雙向協(xié)作的場景

對單向協(xié)作盡量放開

對雙向協(xié)作嚴(yán)謹(jǐn)設(shè)計

針對多人協(xié)作難點的總結(jié)

首先，可以明確一點：SpreadJS完全可以用作多人協(xié)作系統(tǒng)開發(fā)的組件。原因在于：

? SpreadJS的產(chǎn)品質(zhì)量是毋庸置疑的

? SpreadJS在設(shè)計之初，便考慮到了多人協(xié)作的可能，而除此之外，絕大多數(shù)的前端產(chǎn)品都不是為了多人協(xié)作而設(shè)計的

? 多人協(xié)作需要中心系統(tǒng)的支持，SpreadJS基于純前端的體系架構(gòu)可以很容易的嵌入系統(tǒng)開發(fā)，而無需過多考慮與原生系統(tǒng)的兼容性，這是常規(guī)組件是無法做到的

? 要實現(xiàn)多人協(xié)作，需要投入一定的開發(fā)成本，SpreadJS作為一款開發(fā)工具，可以有效幫助開發(fā)人員減輕代碼量

多人協(xié)作表格的本質(zhì)：

? Server – Clients 中心系統(tǒng)，類似數(shù)值敏感的小型網(wǎng)游

? 任何這類系統(tǒng)都是在體驗和正確性中尋求平衡

多人協(xié)作表格的特點：

? 表格的數(shù)值敏感性高于網(wǎng)游，數(shù)據(jù)操作和存儲的挑戰(zhàn)更大

? 表格的計算復(fù)雜度更高，尤其涉及復(fù)雜公式嵌套與全量統(tǒng)計篩選

? Web存在天花板，所以復(fù)雜的頁游并不多見，端游較多

對SpreadJS這類開發(fā)工具/組件的展望與期待

1. SpreadJS 已經(jīng)可以很好地支持多人協(xié)作的最終一致性。如果能支持多人多撤銷隊列，或者撤銷重做自定義，那么就可以給用戶提供更加易用且多樣化的體驗效果，從此絲般順滑不是夢。

2. SpreadJS的絕大部分功能是支持命令的，這使得操作化變得更簡單。如果SpreadJS能開放命令自定義，便可以讓自主控制顆粒度成為可能，用戶可以針對具體的業(yè)務(wù)邏輯做出更加精細(xì)化的操作轉(zhuǎn)換，大幅提高協(xié)作效率。

3. SpreadJS不僅在數(shù)據(jù)錄入、數(shù)據(jù)填報等方面表現(xiàn)出強大的功能，其各類統(tǒng)計分析與圖形化手段也是一個不少，一旦明年的透視表功能上線，使用SpreadJS開發(fā)在線協(xié)同系統(tǒng)的數(shù)據(jù)商業(yè)價值將更易體現(xiàn)，用戶將體驗到“表格”無限的魅力與威力。

4. 表格在多人協(xié)作中的數(shù)據(jù)量增長速度比單人使用時快得多，希望SpreadJS可以支持更大的數(shù)據(jù)量，尤其是在大數(shù)據(jù)量情況下仍舊保持操作的性能與體驗。

以上就是本期公開課《如何實現(xiàn)可多人協(xié)作的“在線excel”系統(tǒng)？》的部分摘要，如果您對在線協(xié)作系統(tǒng)的開發(fā)感興趣，點擊文末了解更多，預(yù)約課程。

總結(jié)

以上是生活随笔為你收集整理的如何多人共同编辑_如何实现可多人协作的“在线excel”系统？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。