服務器關停也不怕：開發(fā)者用AT協(xié)議打造抗崩潰應用

Jake Lazaroff 在休假時做過一個旅行規(guī)劃應用，用 YJS 加上托管同步服務實現(xiàn)了多端協(xié)作。不到一年，那家同步服務提供商被收購并關停了服務。應用雖然還能在本地跑，但跨設備同步徹底失效，只剩下手動傳文件這條路。這個例子戳破了一個讓開發(fā)者不安的事實：那個幫你打通多設備的服務器，同時也成了整個協(xié)作鏈路里最脆弱的依賴項。Lazaroff 把這件事當作演講的開場，不是為了抱怨某個供應商，而是想引出一個更根本的問題——我們能不能把應用最核心的協(xié)作能力，從隨時可能消失的專用后端里抽離出來？

他的答案是 AT 協(xié)議（Authenticated Transfer Protocol）。過去大家談論它，更多是把它看作支撐社交網(wǎng)絡的底層設施，但 Lazaroff 認為，它同樣可以充當分布式應用的底座，而且是一種本地優(yōu)先的架構。在這種模式下，每個用戶的數(shù)據(jù)存放在自己的個人數(shù)據(jù)服務器（PDS）里，應用只是獲得授權去讀寫這些數(shù)據(jù)。PDS 包攬了存儲、細粒度認證和推送更新這些臟活累活，而應用本身不必再自建一套獨立的后端。標準的 AT 協(xié)議架構里還有一個按應用定制的“應用視圖”（App View）服務器，Lazaroff 卻直言它屬于可選項，而且是整個技術棧里偏脆弱的環(huán)節(jié)。他隨即拋出一個大膽的思路：干脆把 App View 也扔掉，只用靜態(tài)應用、PDS 和中繼（relay）能做出什么東西？

演講的主體就是三個去掉 App View 的實驗。

第一個實驗是協(xié)作文本編輯器，用 YJS 和 ProseMirror 搭起來。每一條 YJS 更新都作為一條記錄寫入用戶自己的 PDS，協(xié)作者則通過一條元數(shù)據(jù)記錄串在一起。不同用戶通過中繼幾乎實時地抓取并復制彼此的更新，這本是同步服務器的活，現(xiàn)在由 AT 協(xié)議全盤接管。Lazaroff 的說法很直白：這相當于把 AT 協(xié)議當成了 YJS 的同步服務器。但問題也隨之暴露——文檔狀態(tài)散落在大量記錄當中，別的應用想拿來互通就會變得很麻煩。

第二個實驗轉向協(xié)作待辦清單，用的是 AT 協(xié)議原生的 CRDT（無沖突復制數(shù)據(jù)類型）記錄。每條記錄就是樸素的 JSON 對象，包含類型、清單 ID、文本、完成狀態(tài)、創(chuàng)建時間等字段，CRDT 的元數(shù)據(jù)另外附加，不攪亂結構。這么一來，即使某個應用壓根不認 CRDT 元數(shù)據(jù)，照樣能讀懂記錄內(nèi)容。沖突處理上，每個字段采用最后寫入獲勝的寄存器邏輯，并發(fā)編輯不同字段時互不打擾。棘手的情況發(fā)生在并發(fā)寫入同一條記錄時：比較并交換邏輯會直接拒絕寫入，客戶端接著拉取最新狀態(tài)，在本地合并后再重試。這個設計要解決的核心難題，是如何在不丟更新、不破壞 CRDT 模型的前提下，處理對同一條記錄的并發(fā)寫入。

第三個實驗同樣拒絕了 App View，只依賴靜態(tài)應用、PDS 和中繼。Lazaroff 原本想演示 AT 協(xié)議在另一種協(xié)作場景中的表現(xiàn)，不過這一部分的細節(jié)在演講里沒有完全展開。盡管如此，前兩個實驗已經(jīng)足夠勾勒出一幅圖景：把協(xié)作所需的基本能力下沉到協(xié)議層，并且由用戶自己的數(shù)據(jù)倉庫來承擔持久化和認證的責任，應用的后端就可以一直薄下去。

回到開頭那個旅行規(guī)劃應用的遭遇。如果當初它把同步能力建立在 AT 協(xié)議之上，那個被收購關停的同步服務就不再是命門，因為同步已經(jīng)變成了中繼服務的一部分，而中繼是可以由任何人來運行的。Lazaroff 所說的“減少對專用后端的依賴”，落到實處就是讓應用中那些最容易產(chǎn)生強綁定的模塊，拆解成一批可替換、可自托管的基礎組件。這樣拼出來的應用，即使某個組件下線，也壞不到根基。