了解 Hyperledger Fabric 中的 Docker 容器内部结构

Question

我想了解面料的主要工作原理以及如何达成共识。我在文档中仍然缺少的是在 docker 容器内发生的部分，以参与通信过程。

因此，从客户端（例如应用程序）开始的通信是在对等方和排序者之间使用 gRPC 消息进行的。

但是容器内部会发生什么？

我把它想象成一个进程，它只接收 gRPC 消息并在 peer/orderer 的后台使用函数来回答它们，分发它的响应以在另一个单元（如客户端）中进一步处理以收集响应一个智能合约的多个对等点。

但是在容器内真正发生了什么？我的意思是，当 docker 映像文件由 yaml 配置文件加载和启动时，就会产生一个容器。但是它里面开始的是什么（是否只启动了一个对等二进制文件，例如命令“peer node start”） - 我的意思是编译后的二进制文件“peer”？什么是听？那里有什么反应？我发现每个暴露的容器只有一个端口。这对我来说似乎是 gRPC 的大门（因为它经常用作端口 ID：**51）。

同样的问题也适用于排序器、链码和 cli。他们是如何相互交谈的，或者 gRPC 是唯一的通信和处理方式（不包括发现服务和 gossip，它是如何在容器内部启动的（仅将 yaml 文件用于 lauchun 或者是否有进一步的内部配置或图像文件中的启动脚本（因为我无法查看图像内部，只能在运行时登录正在运行的容器）。

Answer 1

当您的客户端向其中一个节点发送请求时，节点实例会检查其上是否安装了请求的链代码 (CC)。 如果没有安装 CC：显然你会得到一个错误。

如果安装了 CC：Peer 检查是否已经为给定的 CC 和相应版本启动了专用容器。 如果容器已启动，peer 会向该 CC 实例发送事务请求，并在签署事务后将响应返回给您的客户端。签名保证响应确实是由该对等方发送的。

如果容器未启动： 它构建一个 docker 映像并启动该实例（docker 容器）。新图像将基于超级账本图像之一。也就是说，如果你的 CC 是 GO，那么将使用 hyperledger/baseos，这是非常基本的 linux 操作系统。这个新图像还包含 CC 二进制和 META-DATA。

该对等实例正在使用底层（您的）机器的 docker 服务器来执行所有这些操作。这就是为什么我们需要将/var/run:/host/var/run 传递给卷映射并将CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock 传递给环境变量的原因。

一旦 CC 容器启动，它就会连接到它的父对等节点，该对等节点定义为 CORE_PEER_CHAINCODEADDRESS 属性。同伴指示孩子（可能在图像创建期间）使用这个地址，所以他们服从。对等节点使用CORE_PEER_CHAINCODELISTENADDRESS 属性定义自己的监听 URL。

关于你的最后一个问题；节点之间的 gRPC 也与客户端进行通信。如果启用了 TLS，那么它肯定是安全的通信。订购者了解对等点和对等点了解其他组织的对等点的入口点是在通道创建期间定义的锚点对等点的定义。发现服务在对等节点中运行，因此它们可以保持接近实时的网络布局。发现服务还提供对等方的身份，当背书策略需要多个组织的背书策略时（即，如果策略看起来像 AND(Org1MSP.member, Org2MSP.member)），客户端可以通过这种方式检测其他组织的对等方。