我想明白了fabric的主要工作原理和consens是如何达成的。我在文档中仍然缺少的是在docker容器的fabric内部发生的参与通信过程的部分。
因此，从客户端（例如一个应用程序）开始的通信是在对等体和命令器之间使用gRPC消息进行的。
但容器内部会发生什么呢？
我把它想象成一个进程，它只是接收gRPC消息，并在peerorderer的后台使用函数进行回复，然后把它的响应交给另一个单元（如客户端）进一步处理，以收集智能合约中多个peer的响应。
但是，在一个容器内部到底发生了什么？我的意思是，一个容器产生了，当docker镜像文件被yaml配置文件加载和启动时。但是，在它的内部有什么被启动（是否只有一个单一的peer二进制文件被启动，例如，像命令 "peer节点启动"）--我的意思是编译后的go二进制文件 "peer "而已？什么在监听？是什么在响应？我发现每个容器只有一个端口暴露出来。在我看来，这似乎是gRPC的门（因为它经常被用作端口ID：**51）。
同样的问题也适用于命令器、链码和cli。它们之间是如何对话的，还是gRPC是唯一的通信和处理方式（不包括发现服务和gossip，容器内部是如何启动的（只使用lauchun的yaml文件，还是有进一步的内部配置或图像文件中的启动脚本（因为我无法查看图像内部，只能在运行时登录正在运行的容器）。
当你的客户端发送请求到一个对等体，对等体实例检查，如果要求的链码(CC)上安装。如果没有安装CC: 很明显，你会得到一个错误。
如果安装了CC: 对等体检查是否已经为给定的CC和相应的版本启动了专用容器。如果容器已经启动，对等体向该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 属性。
关于你的最后一个问题；节点之间的通信是用gRPC，也是用客户端。如果启用了TLS，那么肯定是安全通信。订购者了解对等体和对等体了解其他组织的对等体的切入点是在通道创建时定义的锚对等体。发现服务运行在对等节点中，因此可以对对等节点举行近似实时的网络布局。Discovery服务还提供了对等体的身份识别，当背书策略需要多个组织的背书策略时，客户端就可以检测到其他组织的对等体（例如，如果策略看起来像是 AND(Org1MSP.member, Org2MSP.member)).