Azure Fluid Relay：利用 Azure Blob 存储扩展 Git
内容提要
本文介绍了如何使用Git作为Azure Fluid Relay（AFR）服务的存储机制，通过将Azure Blob Storage作为文件系统解决了长期数据存储和性能挑战。同时，使用内存计算Git摘要树减少了存储访问请求，降低了存储成本。总体上减少了Azure Fluid Relay服务的存储费用。
延伸解读
从本地文件系统到 Azure Blob：可扩展性突破
早期 AFR 将 Git 摘要存储在 Kubernetes 的持久卷中，导致容器与集群绑定，无法全球扩展，且扩容可能引发停机。迁移到 Azure Blob 存储作为文件系统后，利用其全球可用性和弹性，解决了可靠性和灾难恢复问题，同时保持了 Git 的版本控制优势。
网络延迟如何拖慢 Git 摘要写入
使用远程文件系统时，isomorphic-git 需自底向上写入树对象，每个子树的 SHA 计算都依赖存储写入。若网络延迟为 70ms，高度为 10 的树需 700ms 完成，性能随树高和集群与数据中心的距离线性下降。这解释了为何直接使用 Azure Blob 存储会导致写入缓慢。
低 IO 写入模式：以空间换请求量
为应对 Azure Blob 存储的访问限制，AFR 采用内存计算整个 Git 摘要，生成单个 JSON 文件系统负载，仅写入 ref、commit、tree 和 memfs blob 四个对象。这大幅减少了存储请求，但代价是存储效率降低和内存使用增加，因为无法复用未更改的 blob。
成本权衡：请求减少胜过容量增加
低 IO 写入模式虽增加了存储容量和内存成本，但显著降低了存储访问请求量。由于请求费用远高于容量费用，整体存储成本反而下降，同时提升了可扩展性。这一权衡表明，在特定场景下，优化请求模式比单纯节省容量更有效。
Q&A
Azure Fluid Relay如何利用Git进行存储？
Azure Fluid Relay使用Git作为存储机制，通过将Fluid摘要存储为Git树，利用Git的版本控制和不可变性来管理协作状态。
使用Azure Blob Storage作为文件系统的好处是什么？
使用Azure Blob Storage作为文件系统可以提高可扩展性、可靠性，并降低存储成本，同时保持Git的版本控制特性。
在使用Git进行长期数据存储时面临哪些挑战？
主要挑战包括可扩展性和可靠性，尤其是在数据量大时，Git存储会导致性能瓶颈和存储成本快速增加。
如何解决Azure Fluid Relay的网络开销问题？
通过在本地计算整个Git摘要并使用memfs，减少对Azure Blob Storage的存储访问请求，从而降低网络开销。
Low-IO写入模式的主要优点是什么？
Low-IO写入模式通过在内存中计算Git摘要，显著减少了写入Azure Blob Storage的blob数量，从而降低存储访问请求。
未来Azure Fluid Relay的改进方向是什么？
未来希望找到更好的解决方案来解决性能和成本挑战，同时继续利用当前解决方案的可扩展性。
