本文档概述了IPFS集群架构。

模块化

IPFS集群架构尝试尽可能模块化，其模块（组件）之间的接口明确定义，这样可以实现：

• 可以实现单独交换替代，实现改进，而不会影响系统的其余部分
• 易于单独测试

组件

IPFS集群包括：

• 组件及其接口和相关类型的定义（ipfscluster.go）
• 所述 集群 主要组分结合在一起的整个系统，并提供转到API（ cluster.go）。该组件采用任意方式：
  • API：提供面向公众的API的组件。默认： RESTAPI
  • IPFSConnector：与IPFS守护程序通信并为其提供代理的组件。默认： ipfshttp
  • State：保留Pins列表的组件（由Consensus组件维护）。默认： mapstate
  • PinTracker：跟踪引脚集的组件，确保IPFS守护程序按预期保留它。默认： maptracker
  • PeerMonitor：记录指标和检测对等故障的组件。默认： pubsubmon
  • PinAllocator：一个组件，用于决定哪些对等体应根据某些指标固定CID。默认： descendalloc
  • 举报人：收集PinAllocator和使用的指标的组件  PeerMonitor。默认： disk
• 共识 的组成部分。共识组件使用  go-libp2p-raft via  go-libp2p-consensus。虽然它试图从潜在的共识实施中不可知，但并非在所有地方都是如此。然而，这些地方标记得很好（所有调用的地方 Leader()）。默认值：  raft。

组件执行许多功能，需要能够与每个人通信：即：

• API需要使用主要组件提供的功能
• PinTracker需要使用IPFSConnector提供的功能
• 主要组件需要使用不同对等节点的主要组件提供的功能

RPC API

组件之间的通信通过RPC API进行：一组函数，用于确定组件可用的功能（rpc_api.go）。

RPC API使用  go-libp2p-gorpc。主集群组件运行RPC服务器。为所有组件提供RPC客户端来供其使用。此设置的主要功能是 组件可以使用  go-libp2p-gorpc 在本地集群和任何远程集群节点中使用相同商的API执行操作。

这使广播业务和集群引导联系变得非常容易。它还允许考虑未来组件可能完全随意并从不同应用程序运行。本地RPC调用，不会受到任何惩罚，因为执行是直接短接到集群的对应组件，没有网络干预。

在不利方面，RPC API涉及“反射”魔术，并且要验证调用是否发生在RPC服务器上注册的方法并不容易。应该测试每个基于RPC的功能。错误的操作会导致错误，因此很容易在测试中捕获。

代码布局

组件组织在不同的子模块中（ pintracker/maptracker 表示组件  PinTracker 和实现  MapPinTracker）。所有组件的接口都在基本模块上。可执行文件（ipfs-cluster-service 和  ipfs-cluster-ctl 也为子模块到基部模块）。

组态

一个config 模块通过提供支持ComponentConfig 接口的配置对象来支持中央配置文件，其提供由每个部件定义的配置部分。