全解:將 2 到 2^16 臺(tái)機(jī)器編排為單一 Sandstorm 實(shí)例的托管平臺(tái)路線圖)
后端容器運(yùn)行時(shí)安全云原生【免費(fèi)下載鏈接】sandstormSandstorm is a self-hostable web productivity suite. Its implemented as a security-hardened web app package manager. | Actively sponsored by our friends at TestMu AI項(xiàng)目地址https://gitcode.com/gh_mirrors/sa/sandstorm點(diǎn)擊查看免費(fèi)下載Blackrock 是 Sandstorm 項(xiàng)目為托管服務(wù)與企業(yè)級部署設(shè)計(jì)的集群管理技術(shù)它讓一整個(gè)數(shù)據(jù)中心內(nèi) 2 到約 2^16 臺(tái)同地協(xié)作的機(jī)器或虛擬機(jī)實(shí)例對外呈現(xiàn)為一個(gè)Sandstorm 實(shí)例用戶界面與單機(jī)版幾乎無差別。本文以 roadmap/blackrock/README.md 為骨架結(jié)合倉庫內(nèi)src/sandstorm/與shell/下的真實(shí)實(shí)現(xiàn)系統(tǒng)講解 Blackrock 的設(shè)計(jì)目標(biāo)、七大機(jī)器角色、基于 Capn Proto 的自定義網(wǎng)絡(luò)協(xié)議與 SturdyRef 持久化能力模型并逐條標(biāo)注哪些設(shè)計(jì)已實(shí)現(xiàn)、哪些仍停留在路線圖階段幫助讀者完整理解 Sandstorm 從單機(jī)走向橫向擴(kuò)展集群的演進(jìn)思路。Blackrock 在 Sandstorm 生態(tài)中的定位在 roadmap/README.md 中Blackrock 被明確定義為 the cluster management technology underlying managed hosting and our eventual enterprise product托管服務(wù)與企業(yè)級產(chǎn)品底層的集群管理技術(shù)。也就是說它是 Sandstorm 平臺(tái)三大技術(shù)方向之一與平臺(tái)核心功能Platform、自托管體驗(yàn)Self-hosting并列。從運(yùn)維視角看Sandstorm 默認(rèn)架構(gòu)是單機(jī)部署docs/administering/hosting-provider.md 明確指出 Sandstorm runs on a single server, due to its architecture單機(jī)模式下提升用戶數(shù)的主要手段是縱向擴(kuò)容內(nèi)存RAM is the primary bottleneck。而當(dāng)托管商需要服務(wù)成千上萬用戶時(shí)就需要橫向擴(kuò)展方案——Sandstorm.io 團(tuán)隊(duì)運(yùn)營的 oasis.sandstorm.io 正是使用代號(hào) Blackrock 的這套 scale-out 軟件棧。該文檔同時(shí)提醒Blackrock 遠(yuǎn)不如標(biāo)準(zhǔn) Sandstorm 開箱即用far less turn-key托管商若采用它通常需要與 Sandstorm 開發(fā)者緊密協(xié)作并自行編寫額外代碼更好的路徑是先跑單機(jī)需要時(shí)再遷移到 Blackrock。Blackrock 的設(shè)計(jì)目標(biāo)Goals完整列舉如下將 2 到約 2^16 臺(tái)同地協(xié)作的機(jī)器或 VM 實(shí)例視為一個(gè)Sandstorm 實(shí)例用戶界面與單機(jī) Sandstorm 基本一致強(qiáng)制實(shí)施按用戶或許還按應(yīng)用的存儲(chǔ)空間與內(nèi)存配額支持機(jī)器動(dòng)態(tài)加入或移出集群機(jī)器角色由集群自動(dòng)分配并隨需更新任何一臺(tái)機(jī)器宕機(jī)都不造成用戶中斷或數(shù)據(jù)丟失在機(jī)器之間遷移 grains沙箱化應(yīng)用實(shí)例以平衡負(fù)載、優(yōu)化資源共享例如共享應(yīng)用二進(jìn)制文件通過避免可疑應(yīng)用與高價(jià)值目標(biāo)同機(jī)部署、監(jiān)控主機(jī)可疑行為、定期清空并重啟單臺(tái)機(jī)器緩解沙箱逃逸風(fēng)險(xiǎn)在可用時(shí)利用廉價(jià)的對象存儲(chǔ)。同時(shí)文檔明確劃定了非目標(biāo)不支持地理位置分散的機(jī)器組成單實(shí)例——Blackrock 針對的是同一數(shù)據(jù)中心、同一 LAN 內(nèi)的機(jī)器跨集群移動(dòng)應(yīng)用應(yīng)使用 Sandstorm 常規(guī)的聯(lián)邦federation能力。機(jī)器角色體系同一鏡像、多角色分配Blackrock 集群中的所有機(jī)器都啟動(dòng)同一份只讀操作系統(tǒng)鏡像鏡像內(nèi)包含全部 Blackrock 平臺(tái)軟件機(jī)器啟動(dòng)后由集群主控master為其分配一個(gè)或多個(gè)角色。這種統(tǒng)一鏡像 動(dòng)態(tài)角色的設(shè)計(jì)直接支撐了機(jī)器動(dòng)態(tài)加入/移出、角色自動(dòng)調(diào)整的目標(biāo)——沒有角色固化在鏡像里一切以運(yùn)行時(shí)分配為準(zhǔn)。整個(gè)角色體系分為八類Master主控、Storage存儲(chǔ)、Workers工作機(jī)、Coordinators協(xié)調(diào)器TODO、Shells又名 Front-ends前端、Mongo數(shù)據(jù)庫、Gateways網(wǎng)關(guān)、Log sink日志匯聚TODO。Master集群的角色分配與拓?fù)渲袠忻總€(gè)集群有且僅有一臺(tái) master。其職責(zé)包括為所有其他機(jī)器分配角色監(jiān)控全集群資源使用情況動(dòng)態(tài)決策資源分配去向當(dāng)機(jī)器規(guī)格異構(gòu)時(shí)依據(jù)硬件特性分配合適角色——例如內(nèi)存巨大的機(jī)器應(yīng)做 worker磁盤巨大的機(jī)器應(yīng)做 storage負(fù)責(zé)向所有其他機(jī)器通報(bào)應(yīng)該與哪些對端通信的拓?fù)湫畔ⅰ缧略鲆慌_(tái)存儲(chǔ)節(jié)點(diǎn)后master 會(huì)更新所有可能用到存儲(chǔ)的機(jī)器使它們把新節(jié)點(diǎn)加入各自的負(fù)載均衡池。關(guān)鍵可靠性設(shè)計(jì)是master 不在任何單次請求的服務(wù)關(guān)鍵路徑上。若 master 宕機(jī)集群其余部分可以按照最近一次分配的角色繼續(xù)運(yùn)行等待 master 恢復(fù)。這與單臺(tái)機(jī)器死亡不造成用戶中斷的目標(biāo)直接呼應(yīng)。Storage對象存儲(chǔ)之上的能力化加密代理存儲(chǔ)節(jié)點(diǎn)對外提供所有持久化存儲(chǔ)的接口。文檔特別強(qiáng)調(diào)術(shù)語區(qū)分存儲(chǔ)節(jié)點(diǎn)storage node通常并不直接操作磁盤而是充當(dāng)某個(gè)傳統(tǒng)對象存儲(chǔ)系統(tǒng)如 S3的代理真正的物理存儲(chǔ)應(yīng)稱為disks磁盤。引入這層代理而非讓其他機(jī)器直連磁盤目的有三實(shí)現(xiàn)基于 Capn Proto 持久化層的能力化capability-based對象圖存儲(chǔ)接口——存儲(chǔ)的不是扁平文件而是相互引用、可沿對象圖遍歷的能力對象實(shí)現(xiàn)逐對象加密每個(gè)對象擁有獨(dú)立加密密鑰這些密鑰本身作為訪問對象所需的 SturdyRef 的一部分保存。由于 SturdyRef 通常又存儲(chǔ)在其它已加密的對象中因此不沿對象圖從用戶持有的某個(gè)基礎(chǔ)能力出發(fā)就無法訪問任何對象。理論上這些基礎(chǔ)能力甚至可以用用戶的 GPG 密鑰加密保存實(shí)現(xiàn)完美加密存儲(chǔ)保護(hù)訪問磁盤所需的憑據(jù)如 S3 憑據(jù)使磁盤端無需被信任即可保證隱私。文檔給出的候選后端disk 層包括Amazon S3、Google Cloud Storage、Tahoe-LAFS以及一種利用本地集群所有磁盤的分布式文件系統(tǒng)。文檔還保留了項(xiàng)目自注的 TODO截至文檔記錄時(shí)當(dāng)前存儲(chǔ)實(shí)現(xiàn)仍是單機(jī)寫本地磁盤依賴底層磁盤實(shí)現(xiàn)提供完整性、可靠性與備份Oasis 托管在 Google Compute Engine利用其持久磁盤與快照能力單機(jī)存儲(chǔ)層之所以能扛住大量負(fù)載是因?yàn)槠涔ぷ骰局皇亲x寫塊。但存儲(chǔ)層應(yīng)該被重寫以支持更好的可擴(kuò)展性并在可用時(shí)利用廉價(jià)對象存儲(chǔ)。Workers運(yùn)行 grain 的可疑機(jī)器與 nbd 塊設(shè)備worker 機(jī)器按照協(xié)調(diào)器coordinator見下文的指令運(yùn)行 grains。由于存在沙箱逃逸的可能worker 機(jī)器應(yīng)始終被懷疑對待整個(gè) Blackrock 集群使用 Capn Proto 能力安全模型保證一臺(tái)被攻破的 worker 無法訪問除恰好運(yùn)行在它上面的 grains 之外的任何東西worker 應(yīng)定期輪換出勤、清空wipe防止惡意進(jìn)程長期駐留worker 還應(yīng)接受統(tǒng)計(jì)意義上的可疑活動(dòng)監(jiān)控一旦發(fā)現(xiàn)立即移出輪換。worker 的關(guān)鍵存儲(chǔ)機(jī)制是每個(gè) grain 的存儲(chǔ)通過nbdNetwork Block Device驅(qū)動(dòng)掛載自一個(gè)用戶態(tài)實(shí)現(xiàn)的塊設(shè)備該用戶態(tài)守護(hù)進(jìn)程把塊同步回存儲(chǔ)層。這套設(shè)計(jì)帶來兩個(gè)直接收益數(shù)據(jù)量大的 grain例如音樂庫可以從冷狀態(tài)快速啟動(dòng)——按需on-demand拉取塊即可長期存儲(chǔ)可以保持接近最新狀態(tài)從而讓 worker 機(jī)器故障不至于造成過多數(shù)據(jù)丟失。與此同時(shí)內(nèi)核在塊設(shè)備之上實(shí)現(xiàn)了久經(jīng)考驗(yàn)的緩存層頁面一旦緩存就能把運(yùn)行時(shí)開銷降到最低。文檔還留下一個(gè) TODO(feature)可以探索優(yōu)化初始加載時(shí)間的啟發(fā)式策略例如跟蹤啟動(dòng)時(shí)常加載的塊并提前開始讀取并且 nbd 實(shí)現(xiàn)了 trim 命令可以用來跟蹤文件系統(tǒng)實(shí)際使用的塊、避免存儲(chǔ)無用數(shù)據(jù)。CoordinatorsTODO(feature)尚未實(shí)現(xiàn)的調(diào)度層截至文檔記錄2017 年 2 月協(xié)調(diào)器尚未實(shí)現(xiàn)——Currently frontends simply round-robin to workers當(dāng)前前端只是對 worker 做輪詢。文檔中的協(xié)調(diào)器設(shè)計(jì)如下協(xié)調(diào)器告訴 worker 做什么要啟動(dòng)新 grain 或啟動(dòng)一個(gè)當(dāng)前未運(yùn)行的 grain必須先聯(lián)系協(xié)調(diào)器由它挑選合適的 worker 委派任務(wù)每個(gè)協(xié)調(diào)器維護(hù)一組 worker這些集合可以重疊也可以不重疊——可以是兩個(gè)協(xié)調(diào)器各監(jiān)控全部 worker也可以各監(jiān)控一半啟動(dòng) grain 的請求可交給任意協(xié)調(diào)器調(diào)用方應(yīng)在它們之間做負(fù)載均衡協(xié)調(diào)器監(jiān)控其 worker 上的資源使用并在需要時(shí)下達(dá) grain 遷移指令它應(yīng)當(dāng)考慮每個(gè)應(yīng)用的典型資源占用以及該應(yīng)用的可疑程度——可疑應(yīng)用應(yīng)與安全關(guān)鍵型應(yīng)用隔離以緩解沙箱逃逸的影響。文檔評價(jià)該模塊有大量算法與啟發(fā)式策略的開發(fā)空間屬于路線圖中留白最多的領(lǐng)域。Shells又名 Front-endsMeteor 前端Shell 機(jī)器運(yùn)行 Sandstorm shell UI——一個(gè) Meteor 應(yīng)用。代碼中這些機(jī)器被稱為 frontends前端文檔認(rèn)為這個(gè)叫法其實(shí)并不準(zhǔn)確an arguably incorrect name。在倉庫中shell/目錄正是這套 Meteor 應(yīng)用其服務(wù)端入口位于 shell/server/main.ts客戶端入口在 shell/client/main.ts而 Blackrock 多副本場景下的能力路由基礎(chǔ)設(shè)施可見于 shell/imports/server/frontend-ref.js 與 shell/imports/server/core.js。后者實(shí)現(xiàn)了FrontendRefRegistry前端能力引用注冊表并圍繞frontendRef字段把前端提供的 Capn Proto 能力保存為可恢復(fù)的持久引用——例如 core.js 通過globalFrontendRefRegistry.restore(db, saveTemplate, token.frontendRef)恢復(fù)能力這正是多 shell 副本場景下路由能力所依賴的機(jī)制。另外 shell/imports/server/accounts/saml/saml-server.js 中還有一條注釋提醒某些狀態(tài)可能需要在 Blackrock 下改用 Mongo collection 才能在多前端場景工作。Mongo當(dāng)前依賴與長期替換計(jì)劃由于 Sandstorm shell 當(dāng)前依賴 Mongo 作為數(shù)據(jù)庫Blackrock 集群需要專門的 Mongo 機(jī)器運(yùn)行該數(shù)據(jù)庫其中一臺(tái)為主master、其余為從slave。文檔列出兩項(xiàng) TODOTODO(feature)數(shù)據(jù)庫也應(yīng)同步回對象存儲(chǔ)TODO(project)長期來看應(yīng)當(dāng)用自有存儲(chǔ)接口替換 Mongo。這條依賴在倉庫中同樣可證shell/imports/server/core.js 有一段注釋專門處理 Fix Mongo converting Buffers to Uint8Arrays說明 shell 與 Mongo 的數(shù)據(jù)交互是實(shí)打?qū)嵉漠?dāng)前實(shí)現(xiàn)細(xì)節(jié)。Gateways連接公網(wǎng)與集群內(nèi)部的橋網(wǎng)關(guān)gateway負(fù)責(zé)橋接公網(wǎng)或 Sandstorm 集群之外的更廣企業(yè)網(wǎng)絡(luò)工作拆分為幾塊接收入站 HTTP 請求、終結(jié) SSL、轉(zhuǎn)發(fā)給 shell 或直接轉(zhuǎn)發(fā)給 grains——這是已實(shí)現(xiàn)的核心職責(zé)TODO(feature)實(shí)現(xiàn)一套 Capn Proto 接口用于對外建立/接受 TCP 連接以及參與 UDP 流量這類連接將被禁止連到集群內(nèi)其他機(jī)器能力可交給設(shè)備驅(qū)動(dòng)從而在不授予任何內(nèi)網(wǎng)訪問權(quán)限的情況下授予其外部網(wǎng)絡(luò)訪問TODO(feature)把 Capn Proto 本身代理到外部世界——內(nèi)部網(wǎng)絡(luò)與公網(wǎng)使用不同參數(shù)化的 Capn Proto 協(xié)議因此能力跨越邊界時(shí)必須被主動(dòng)代理這同時(shí)也讓系統(tǒng)有機(jī)會(huì)把外部能力與內(nèi)部能力分開追蹤并向外部隱藏內(nèi)部 SturdyRef 表示作為額外一層安全。倉庫中網(wǎng)關(guān)的實(shí)現(xiàn)證據(jù)非常充分src/sandstorm/gateway.c 中的GatewayService是直接處理 HTTP 等流量的 C 代碼而路由決策通過 src/sandstorm/backend.capnp 定義的GatewayRouter接口回到 Sandstorm 業(yè)務(wù)邏輯Node.js 進(jìn)程網(wǎng)關(guān)先連接 backend 獲得作為引導(dǎo)能力的GatewayRouter再通過openUiSession根據(jù) sandstorm-sid cookie 換取 WebSession、openApiSession根據(jù) Authorization 頭中的 token 換取 ApiSession等方法完成會(huì)話路由。backend.capnp中還明確注釋了 Blackrock 場景in Blackrock, where multiple instances of the shell might be running, all GatewayRouters are equivalent, regardless of which shell replica在 Blackrock 中即使運(yùn)行多個(gè) shell 副本所有 GatewayRouter 也都等價(jià)無論連到哪個(gè)副本——這是網(wǎng)關(guān)層與多副本 shell 解耦的直接依據(jù)。此外 src/sandstorm/config.c 中有一條配置日志 Gateway is no longer experimental. Disabling EXPERIMENTAL_GATEWAY is ...說明網(wǎng)關(guān)模塊已經(jīng)走出實(shí)驗(yàn)階段。Log sinkTODO(feature)尚未實(shí)現(xiàn)的日志匯聚所有其他機(jī)器應(yīng)向日志匯聚節(jié)點(diǎn)log sink匯聚日志以供分析。截至文檔記錄該功能尚未實(shí)現(xiàn)——Currently logs are collected and written to disk on the master machine當(dāng)前日志由 master 機(jī)器收集并寫到本地磁盤。網(wǎng)絡(luò)與 Capn Proto 設(shè)計(jì)面向 LAN 的自定義協(xié)議Blackrock 集群使用一套為特定用例定制參數(shù)化的 Capn Proto RPC 協(xié)議。文檔先給出實(shí)現(xiàn)現(xiàn)狀注記截至 2017 年 2 月Capn Proto 仍運(yùn)行在 TCP 之上且由于 3-party handoff三方交接尚未實(shí)現(xiàn)所有通信實(shí)際上都經(jīng) master 機(jī)器代理轉(zhuǎn)發(fā)——這顯然會(huì)在規(guī)模增長時(shí)成為瓶頸但當(dāng)時(shí)運(yùn)行平穩(wěn)。傳輸層TransportUDP 優(yōu)于 TCP 的理由Blackrock 假設(shè)內(nèi)部通信是近乎全連通的網(wǎng)狀fully-connected mesh——幾乎每臺(tái)機(jī)器都會(huì)向其他每臺(tái)機(jī)器偶發(fā)發(fā)消息。既然假定在同一 LAN 內(nèi)可以為此優(yōu)化使用UDP 而非 TCP丟包在 LAN 中很罕見UDP 可以避免每次想跟一臺(tái)尚未建立連接的機(jī)器通信都要做 TCP 握手該模型對臨時(shí)網(wǎng)絡(luò)抖動(dòng)更魯棒對 Capn Proto 軟件來說斷連相當(dāng)有破壞性因?yàn)樗形闯志没哪芰Χ紩?huì)丟失而基于 UDP 可以輕松設(shè)計(jì)等待網(wǎng)絡(luò)恢復(fù)一段時(shí)間的策略。加密Cryptovat ID 與免握手的密鑰交換每個(gè) vat能力網(wǎng)絡(luò)中的對等體/機(jī)器由唯一的vat ID標(biāo)識(shí)。vat ID 實(shí)際上就是該 vat 自己生成的ed25519 公鑰——對應(yīng)的私鑰絕不應(yīng)離開生成它的機(jī)器且每當(dāng)整機(jī)被清空時(shí)應(yīng)一并丟棄。vat 可以通過對 challenge 簽名來證明自己擁有某個(gè) vat ID。在多數(shù)情況下Blackrock 實(shí)例的內(nèi)部網(wǎng)絡(luò)可能不需要分組加密因?yàn)楦叨司W(wǎng)絡(luò)硬件通??杀恍湃螢橹话寻哆f給正確目的地。但如果需要加密最直接的方式是curve25519 密鑰交換兩個(gè) vat 僅憑彼此知道對方的 vat ID以及各自的私鑰就能協(xié)商出共享秘密從而無需任何握手即可開始互發(fā)流量——這與 UDP 傳輸?shù)脑O(shè)計(jì)天然契合。持久能力SturdyRefs能力網(wǎng)絡(luò)的持久化基石在 Blackrock 網(wǎng)絡(luò)內(nèi)SturdyRef持久能力引用分為有限幾種類型Storage refs直接指向存儲(chǔ)中的對象由存儲(chǔ)節(jié)點(diǎn)恢復(fù)restoreGrain refs指向特定 grain 內(nèi)托管的 capability由協(xié)調(diào)器恢復(fù)External refs指向公網(wǎng)上的 capability由網(wǎng)關(guān)恢復(fù)Ephemeral refs指向某個(gè)特定 vat 上托管的 capability只能由該 vat 恢復(fù)這類 cap 天生短命因?yàn)?vat 本身短命頻繁輪換但它們能挺過重啟與進(jìn)程崩潰比 live refs 更穩(wěn)固。每個(gè) SturdyRef 都被密封sealed到請求創(chuàng)建它的 vat 所屬的trust zone信任區(qū)域并且只能由同一 trust zone 恢復(fù)——這防止了跨信任邊界泄漏的比特bits被利用。每個(gè) vat 自身是一個(gè) trust zone此外還有四個(gè)特殊區(qū)域storage、gateways、coordinators、shells。這四個(gè)分組內(nèi)的 vat 都能保存 SturdyRef使組內(nèi)任意其他成員之后可以恢復(fù)它們。SturdyRef 在倉庫源碼中有大量印證。在 src/sandstorm/supervisor.capnp 中注釋了 In the Sandstorm internal realm, the type of SturdyRefs themselves is simplyData并多處描述save()與restore()語義src/sandstorm/supervisor.c 中實(shí)現(xiàn)了把 token 設(shè)為 SturdyRef如setSturdyRef(args.getToken())、按SystemPersistent語義保存/恢復(fù)能力含sealFor信任區(qū)域邏輯等關(guān)鍵路徑src/sandstorm/sandstorm-http-bridge.c 中也能看到應(yīng)用側(cè)尚未落盤、需要保存一個(gè) SturdyRef的注釋。在 src/sandstorm/grain.capnp 中則詳細(xì)對比了授權(quán)碼authorization code與 SturdyRef 的區(qū)別并解釋為何避免讓應(yīng)用直接拿到新鑄造的 SturdyRef——因?yàn)?SturdyRef 泄漏更危險(xiǎn)攻擊者可能拿它發(fā)起偽造的 powerbox 請求。這些注釋共同表明SturdyRef 不是簡單的對象 ID而是密碼學(xué)安全、按信任區(qū)域密封的持久能力憑證這正是 Blackrock 對象圖存儲(chǔ)與 worker 不可信假設(shè)的安全基石。從路線圖到現(xiàn)狀實(shí)現(xiàn)狀態(tài)總覽原文檔以 TODO 標(biāo)注的形式記錄了各模塊的實(shí)現(xiàn)進(jìn)度。下表匯總各角色/功能的文檔標(biāo)注狀態(tài)與倉庫中的佐證位置方便讀者對照模塊文檔標(biāo)注狀態(tài)倉庫佐證Master已設(shè)計(jì)每集群單臺(tái)不在請求關(guān)鍵路徑見本文第 3 節(jié)Storage已實(shí)現(xiàn)為單機(jī)本地磁盤重寫為對象存儲(chǔ)代理屬 TODOsrc/sandstorm/backend.capnp配額/存儲(chǔ)接口Workers已實(shí)現(xiàn)nbd 塊設(shè)備 用戶態(tài)同步守護(hù)進(jìn)程src/sandstorm/沙箱與橋接代碼Coordinators未實(shí)現(xiàn)前端輪詢 worker無對應(yīng)實(shí)現(xiàn)Shells/Front-ends已實(shí)現(xiàn)Meteor 應(yīng)用shell/client/main.ts、shell/imports/server/frontend-ref.jsMongo已實(shí)現(xiàn)一主多從替換為自有存儲(chǔ)屬 TODO(project)shell/imports/server/core.jsGatewaysHTTP/SSL 終結(jié)已實(shí)現(xiàn)TCP/UDP 接口與 Capn Proto 外部代理屬 TODO(feature)src/sandstorm/gateway.c、src/sandstorm/backend.capnpLog sink未實(shí)現(xiàn)日志暫寫 master 磁盤無對應(yīng)實(shí)現(xiàn)傳輸層未實(shí)現(xiàn)當(dāng)前 Capn Proto 走 TCP經(jīng) master 代理無 UDP 實(shí)現(xiàn)加密設(shè)計(jì)完成ed25519 vat ID curve25519 協(xié)商文檔為唯一來源SturdyRefs已實(shí)現(xiàn)save/restore、trust zone 密封src/sandstorm/supervisor.c、src/sandstorm/supervisor.capnp、src/sandstorm/grain.capnp需要強(qiáng)調(diào)的是roadmap/blackrock/README.md本身是技術(shù)路線圖文檔而非實(shí)現(xiàn)說明其中 Coordinators、Log sink、UDP 傳輸、外部 TCP/UDP 能力、Capn Proto 外部代理等條目均明確標(biāo)注為 TODO讀者不應(yīng)將之當(dāng)作當(dāng)前可用功能。而 Storage 的對象存儲(chǔ)代理 逐對象加密、SturdyRef 的 trust zone 模型等則在src/sandstorm/的 Capn Proto 模式與 C 實(shí)現(xiàn)中留下了可追溯的設(shè)計(jì)證據(jù)是理解 Sandstorm 能力安全模型從單機(jī)延伸到集群的關(guān)鍵。延伸閱讀roadmap/blackrock/README.md本文核心來源——Blackrock 完整路線圖原文roadmap/README.mdSandstorm 整體技術(shù)路線圖說明 Blackrock 與 Platform、Self-hosting 的關(guān)系及 TODO 分類約定project / feature / roadmapdocs/administering/hosting-provider.md托管商視角的 Blackrock 定位與部署建議單機(jī)起步、需要時(shí)遷移src/sandstorm/backend.capnpGatewayRouter接口定義及 Blackrock 多 shell 副本等價(jià)性注釋src/sandstorm/supervisor.capnp 與 src/sandstorm/grain.capnpSturdyRef 語義與授權(quán)碼/持久能力對比的權(quán)威注釋shell/imports/server/core.js 與 shell/imports/server/frontend-ref.js前端能力引用注冊表與 Mongo 依賴的實(shí)際代碼。贊分享后端容器運(yùn)行時(shí)安全云原生【免費(fèi)下載鏈接】sandstormSandstorm is a self-hostable web productivity suite. Its implemented as a security-hardened web app package manager. | Actively sponsored by our friends at TestMu AI項(xiàng)目地址https://gitcode.com/gh_mirrors/sa/sandstorm點(diǎn)擊查看免費(fèi)下載相關(guān)推薦Sandstorm 技術(shù)路線圖全景解讀平臺(tái)功能、Blackrock 集群與自托管生態(tài)Sandstorm 技術(shù)路線圖全景解讀平臺(tái)功能、Blackrock 集群與自托管生態(tài) Sandstorm 是一個(gè)可自托管的 Web 生產(chǎn)力套件本質(zhì)上是安全后端容器運(yùn)行時(shí)安全云原生Sandstorm 平臺(tái)功能路線圖全解賬戶、應(yīng)用、谷物與能力安全架構(gòu)Sandstorm 平臺(tái)功能路線圖全解賬戶、應(yīng)用、谷物與能力安全架構(gòu) 本文以 Sandstorm 官方技術(shù)路線圖 roadmap/platform/READM后端容器運(yùn)行時(shí)安全云原生Sandstorm 平臺(tái)級跨 Grain 全文搜索從安全索引架構(gòu)到 Lucene/Lucy 實(shí)現(xiàn)路線Sandstorm 平臺(tái)級跨 Grain 全文搜索從安全索引架構(gòu)到 Lucene/Lucy 實(shí)現(xiàn)路線 Sandstorm 是一個(gè)以安全隔離為核心的自托管 We后端容器運(yùn)行時(shí)安全云原生上一篇Open edX Platform MFE 配置端點(diǎn)治理ADR 0035 確立 /api/frontend_site_config/v1/ 為規(guī)范端點(diǎn)下一篇企業(yè)法務(wù)智能化的架構(gòu)革新從模型選型到能力沉淀的范式重構(gòu)創(chuàng)作聲明:本文部分內(nèi)容由AI輔助生成(AIGC),僅供參考