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

Question

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

因此，从客户端(例如应用程序)开始的通信发生在对等方和排序方之间使用 gRPC 消息的过程中。

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

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

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

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

Answer 1

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

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

如果容器未启动:
它构建一个 docker 镜像并启动该实例(docker 容器)。新图像将基于 super 账本图像之一。即如果你的 CC 是 GO，那么 hyperledger/baseos ，这是一个非常基础的linux os，会用到。这个新图像还包含 CC 二进制和 META-DATA。

该对等实例正在使用底层(您的)机器的 docker 服务器来完成所有这些工作。这就是为什么我们需要通过 /var/run:/host/var/run卷映射和CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock进入环境变量。

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

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