本文档概述了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
- API:提供面向公众的API的组件。默认:
- 共识 的组成部分。共识组件使用
go-libp2p-raft
viago-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
接口的配置对象来支持中央配置文件,其提供由每个部件定义的配置部分。