联邦式架构中的协议抉择：从 Mastodon 的设计看分布式系统的技术权衡

Gossip 、 WebFinger 都是去中心化的网络协议，但是其设计理念却有不小的差别，我想从两者的设计理念和产品对这两者的需求出发，去探讨这两者是否存在想通和可借鉴的地方。

一、分布式系统中的资源发现与同步

WebFinger其实更适合一种联邦式架构（如 Mastodon），每个实例都是一个自治的服务器，负责管理自身用户的数据。这种架构更强调强调按需查询，而非全网持续状态同步。

Mastodon 用户的资料查找通常是用户在发起交互时的即时请求。例如，当你输入 @user@domain 时，客户端只需要查询目标实例的 WebFinger 接口来获取该用户的 ActivityPub 资料。

对于 Mastodon 来说，账户的元数据（例如个人主页、头像、链接等）并不需要在全网中不断地广播同步，而是在查询时从目标实例获取最新数据即可。

Gossip 的设计目的主要是去达成去中心化系统中的状态同步，也就是全网数据最终一致，这就意味着需要在各个节点间不断传播和更新状态，会产生大量持续的网络流量。

使用 Gossip 的去中心化架构中的节点需要通过类似 Gossip 的协议在所有节点间持续传播状态信息，以确保全网数据的一致性和最新状态。这种方式适用于那些没有明显"中心"节点、需要全局信息同步的场景，但会带来额外的网络流量和延迟。

Gossip 协议的基本思想就是，一个节点想要分享一些信息给网络中的其他一些节点，于是周期性的随机选择 k 节点，并把信息传递给节点。这些收到信息的节点接下来会做同样的事情，下一个周期传递消息给非消息来源的相邻 k 个节点传递信息。

Gossip 对网络节点的连通性和稳定性几乎没有任何要求，它一开始就将网络某些节点只能与一部分节点部分连通 而不是以 全连通网络作为前提；能够容忍网络上节点的随意地增加或者减少，随意地宕机或者重启，新增加或者重启的节点的状态最终会与其他节点同步达成一致。

WebFinger 就相对简单了，的旨在通过电子邮件地址（如user@domain.com）查询用户的公开元数据信息。

其原理就是：用户向目标域名发起HTTP GET请求，路径为/.well-known/webfinger?resource=acct:user@domain.com，服务器返回包含元数据的JSON对象。

WebFinger严格遵循RFC 7033标准，仅用于身份解析，不涉及实际内容传输。

用户动态、关注关系等数据通过ActivityPub协议 传输，而ActivityPub的底层通信依赖HTTP协议（如POST发送帖子、GET获取时间线）

WebFinger 相较于普通的 HTTP 请求有什么优势？为什么不直接用HTPP协议，而是采用WebFinger？

WebFinger通过固定路径（/.well-known/webfinger）和标准参数（如resource=acct:user@domain）实现用户身份发现，确保不同实例间的协议一致性。

若使用简单HTTP请求，每个实例可能自定义不同端点（如/user_profile或/find_user），导致跨平台交互复杂化。