開發在線文檔時,這個技術難點你解決了嗎?
“時勢造英雄”,是亙古不變的真理。在當前的時代背景下,在線文檔可以稱得上是這樣的“英雄” 。
新一代信息技術的迅猛發展,深刻影響著我們的工作生活方式。近年,遠程辦公徹底顛覆了傳統的企業管理模式,在線文檔作為遠程辦公軟件的重要組成部分也同樣迎來了高速發展。
如今,即便市場中已經有了騰訊文檔、石墨文檔、飛書、語雀和靈犀文檔等在線辦公產品,但在線文檔本身仍面臨功能、技術、數據安全、服務、生態等多方面的考驗,如數據處理效率、多人協作、二次擴展、系統集成、框架兼容性問題等。
從技術角度來看,在線、數據處理和多人協作是開發在線文檔系統最關鍵的技術指標。不過,在線和數據處理均已有較成熟的技術方案,實現難度不大。因此,多人協作才是影響在線文檔系統易用性的核心要素。
什么是多人協作?
多人協作,即多人同時對同一份文檔進行編輯,用戶無需刷新即可看到其他人所做的修改。Google Docs、騰訊文檔、石墨文檔、Quip 等都具備多人協作功能。
那么,多人協作是如何實現的呢?
任何信息如要做到多人實時編輯與展現,需要實現以下三步:
- 操作化
- 可傳輸
- 可還原
這三步,類似于編解碼過程:首先將信息轉換為一組操作集合,然后將操作通過網絡傳輸給其他終端,最后在本地終端將操作還原為信息。
這些步驟看起來簡單,但每一步都涉及很多細節處理,比如:操作化過程中,在對信息進行分割與組合時,如何確保信息的所有變化都可以分解為操作的集合?如何令操作覆蓋信息的所有變化?如何決定分割的顆粒度?
可傳輸需要考慮以下幾點:
1、傳輸內容
- 原始文本
Ⅰ.清晰
Ⅱ.冗余
- 壓縮技術
Ⅰ.邏輯壓縮
Ⅱ.協議壓縮
Ⅲ.手動壓縮
2、網絡協議
- Socket
Ⅰ.TCP
Ⅱ.UDP
- HTTP
- WebSocket
3、QoS(Quality of Service,服務質量)
- 快速失敗
- 自動回滾
- 自動重連
- 自動恢復
可還原主要涉及:
1、絕對操作的還原
- 控制體積
- 合理的提示
2、相對操作的還原
- 嚴格的順序性
- 從源頭保障順序性
- 順序性的補救
3、本地操作的還原
- 過濾收到的操作集合
- 從源頭細化操作顆粒
- 本地保存本地執行
4、無入侵的還原
- 定義入侵
- 排除入侵
- 千人千面
在了解了多人協作的基本原理之后,我們來研究一下它的技術難點。
多人協作有哪些技術難點?
多人協作,本質是分布式系統中的 Multiple Leader Replication,即任何一個用戶端都可被視為 Data Leader,這些 Leader 之間同步數據必然會遇到亂序和沖突問題。這就是多人協作的主要難點。
對于 Multiple Leader Replication 的沖突問題,有如下解決方法:
- 避免產生沖突,即不讓多個用戶同時編輯同一處地方。該解決方法簡單粗暴,使用時需具體查看產品形態是否適合該方案。
- 把沖突暴露給用戶,讓用戶自己解決。目前大多數專業的版本控制軟件采用了該方法,但它不適用于擁有大量非專業用戶的產品,如在線文檔。
- 給寫入操作打上全局 index,可以是時間戳或序列號,該 index 必須是全局的且遞增。在任何沖突的地方,都選擇 index 較高的那個寫入。該方法的優勢在于沖突的解決是完全自動化的,不需要用戶參與。缺點就是如果遇到同步間隔很長的情況,會丟失很多用戶的輸入。
在實際開發在線文檔系統的過程中,Operational Transformation(OT)算法技術是解決多人協作沖突問題較為常用的方法。這項技術誕生于 1989 年,其原理是將文本內容統一為以下 3 種類型的操作方式,目的是為用戶提供最終一致性實現:
- retain(n):保持 n 個字符
- insert(str):插入字符 str
- delete(str):刪除字符 str
在完成上述操作后,OT 算法將正在并發的操作合并轉換,以形成新的操作流,并應用在歷史版本上,實現無鎖化同步編輯。
(OT 算法技術中的操作轉換過程)
OT 算法背后的思想其實非常簡單,就是在特定的條件下進行相應的操作轉換,因此,OT 主要用于文本,通常很復雜且不可擴展。對于富文本編輯等更高級的結構,OT 用復雜性換來了對用戶預期的實現,不會給系統性能造成過多的負面影響。因此,如今大多數實時協同編輯邏輯都是基于 OT 算法來實現的。
正因如此,OT 算法成為了解決當前協同沖突處理最主要的方案之一。然而,即便它已經誕生了 30 余年,控制算法相關的理論早已百花齊放,卻仍無法很好地處理分布式實現問題,且開發一個支持多人實時協同編輯的系統也遠比想象中的更加復雜。
實現多人協作的突破口在哪里?
由此可見,實現一款復雜的多人實時協同編輯系統僅僅依靠算法邏輯是不夠的,還需要根據不同的業務場景(如項目看板、純文本編輯、undo/redo 等),投入大量的研發成本和時間,并在不斷摸索中,尋找到產品性能和易用性之間的平衡點。
那么,是否存在一條更為簡單快捷的解決方法呢?
通過對市面上多款在線協同辦公產品的示例代碼進行分析,我們發現這些產品除了運用到前文提到的 OT 算法之外,基本都會借助第三方表格組件。通過嵌入組件,在線文檔系統很好地支持了多人協作的最終一致性,給用戶提供了更加易用且多樣化的體驗效果,在減少研發成本的同時,實現了更高密度的計算復雜度,大幅提高了多人協作效率。
用于多人協作的表格組件需要具備哪些功能?
首先,是對于表格的功能支持。
由于表格的數值敏感性遠高于其他數據類型,用作多人協作文檔時可以實現更為細膩的操作顆粒度和計算復雜度。因此,所選用的組件必須具備強大的表格功能支持,不僅要在數據錄入、數據填報等方面展現出強大的能力,還要具備各類統計、計算匯總、透視分析,以及圖形化手段。
其次,需要具備開放的 API 接口,滿足更多定制化選項。
這類組件需要提供豐富的事件和應用程序接口,用于控制單元格狀態、表單保護、數據傳輸等邏輯,對于多人協作而言,還需限制用戶對同一處內容進行編輯,以及插入時間戳(序列化)等功能。
出于好奇,筆者下載試用了網上多款表格組件,發現能滿足上述需求的屈指可數,而 SpreadJS 無疑是最為亮眼的一款。這款組件主打可嵌入系統的“在線 Excel”,純前端的體系架構可以很容易的嵌入系統開發,而無需考慮與原生系統的兼容性。值得一提的是,SpreadJS 采用了稀疏數組 (Sparse Array) 作為存儲模型,相較于傳統的鏈式存儲或數組存儲,稀疏數組只會對非空數據進行存儲,而不需要對空數據開辟額外的內存空間。
除了節省內存空間外,對于表格這類布局松散的數據類型,稀疏數組也更易于構建基于行索引的數據字典,以便隨時替換或恢復整個存儲結構中的任何一個級別的節點,借助這一特性,SpreadJS 在多人協同中實現了高效的數據回滾和數據恢復 (Redo/Undo)。
(SpreadJS 的稀疏矩陣存儲模型 (Sparse Array))
結語
企業協同辦公的需求將伴隨數字化轉型的深化而日益劇增。未來企業協同辦公將朝著產品易用性提升、可集成與二次擴展能力、與原系統/業務的高度契合、滿足最終用戶的使用習慣等方向發展。
如何打破技術壁壘,開發出既能滿足不同場景下的用戶需求,又具備市場競爭力和差異化的在線文檔產品,是 SaaS 企業和系統供應商們首要考慮的問題。
“好風憑借力,送我上青云。”在如今競爭激烈的在線文檔領域,除了耗費大量精力自主研發,學會借力打力滿足不同的業務場景和客戶需求,或許也是一個不錯的選擇。