Skip to content

Commit

Permalink
Merge pull request #590 from stone-ch/release-2.0
Browse files Browse the repository at this point in the history
merge
  • Loading branch information
greatcyang committed Feb 21, 2020
2 parents 44bddc7 + 3b84e0c commit b53bae4
Show file tree
Hide file tree
Showing 2 changed files with 55 additions and 58 deletions.
44 changes: 23 additions & 21 deletions docs/source/discovery-overview.rst
Original file line number Diff line number Diff line change
Expand Up @@ -4,31 +4,31 @@
为什么我们需要服务发现?
---------------------------------

为了在peer节点上执行链码,将交易提交给orderer节点,并更新交易状态,应用程序需要连接SDK中公开的API
为了在 Peer 节点上执行链码,将交易提交给排序节点,并更新交易状态,应用程序需要连接 SDK 中开放的 API

然而,SDK需要大量信息,以便允许应用程序连接到相关的网络节点。除了通道上orderer节点和peer节点的CA和TLS证书及其IP地址和端口号之外,它还必须知道相关的签名策略以及已安装链码的peer(这样应用程序才能知道将链码提案发送给哪个peer节点)。
然而,为了让应用程序连接到相关的网络节点,SDK 需要大量信息。除了通道上排序节点和 Peer 节点的 CA 证书和 TLS 证书及其 IP 地址和端口号之外,它还必须知道相关的背书策略以及安装了链码的 Peer 节点(这样应用程序才能知道将链码提案发送给哪个 Peer 节点)。

在v1.2之前,这些信息是静态编码的。然而,这种实现对网络更改(例如添加已安装相关链码的peer节点或peer节点宕机)的响应不是动态的。静态配置也不允许应用程序对背书策略本身的更改做出反应(如新组织加入通道时可能发生的情况)。
在 v1.2 之前,这些信息是静态编码的。然而,这种实现不能动态响应网络的更改(例如添加已安装相关链码的 Peer 节点或 Peer 节点临时离线)。静态配置也不能让应用程序对背书策略本身的更改做出反应(比如通道中加入了新的组织)。

此外,客户端应用程序无法知道哪些peer节点已更新账本,哪些未更新。结果是,该应用程序可能向与网络其他节点账本不同步的peer节点提交提案,从而导致事务在提交时失效并浪费资源。
此外,客户端应用程序无法知道哪些 Peer 节点已更新账本,哪些未更新。因此该应用程序可能向网络中尚未同步账本的 Peer 节点提交提案,从而导致事务在提交时失效并浪费资源。

上述的 **服务发现** 通过让peer节点动态地计算所需的信息并以可消耗的方式将其提供给SDK,改进了这个过程
**服务发现** 通过让 Peer 节点动态计算所需信息,并以可消耗的方式将其提供给 SDK,从而改善了此过程

Fabric中服务发现的工作方式
-------------------------------------
Fabric 中的服务发现是如何工作的
---------------------------------------------------

应用程序启动时被引导得知应用程序开发人员/管理员所信任的一组peer节点,以便为发现查询提供可信的响应。客户端应用程序所使用的良好参与节点也是该组织中的peer节点。请注意,为了被服务发现所识别,peer节点必须定义一个 ``EXTERNAL_ENDPOINT`` 。要查看如何执行此操作,请查看我们的文档:doc:`discovery-cli`
应用程序启动时会通过设置得知应用程序开发人员或者管理员所信任的一组 Peer 节点,以便为发现查询提供可信的响应。客户端应用程序所使用的候选节点也在该组织中。请注意,为了被服务发现所识别,Peer 节点必须定义一个 ``EXTERNAL_ENDPOINT`` 。想了解如何执行此操作,请查看我们的文档 :doc:`discovery-cli`

应用程序向服务发现发出配置查询,并获取与网络的其余节点通信所需的所有静态信息。通过向peer节点的服务发现发送后续查询,可以随时刷新此信息
应用程序向发现服务发出配置查询并获取它所拥有的所有静态配置,否则就需要与网络的其余节点通信。继续向 Peer 节点的发现服务发送查询,就可以随时刷新此信息

该服务在peer节点(而不是应用程序)上运行,并使用gossip通信层维护的网络元数据信息来找出哪些peer节点处于联机状态。它还从peer节点的状态数据库中获取信息,例如相关的签名策略等。
该服务在 Peer 节点(而不是应用程序)上运行,并使用 gossip 通信层维护的网络元数据信息来找出哪些 Peer 节点在线。它还从 Peer 节点的状态数据库中获取信息,例如相关的签名策略等。

通过服务发现,应用程序不再需要指定为他们背书的peer节点。SDK可以简单地将查询发送给服务发现,以询问给定通道和链码ID所对应的peer节点。然后,服务发现将计算由两个对象组成的描述符
通过服务发现,应用程序不再需要指定为他们背书的 Peer 节点。给定通道和链码 ID,SDK 就可以通过发现服务查询其所对应的 Peer 节点。然后,发现服务会计算出由两个对象组成的描述符

1. **布局**: peer组的列表,以及每个组中应当选取的peer节点数
2. **组到peer的映射**: 从布局中的组到通道的peer节点。实际上,每个组很可能是代表各个组织的peer节点,但是由于服务API是通用的并且与组织无关,因此这只是一个“组”。
1. **布局(Layouts)**: Peer 组的列表,以及每个组中应当选取的 Peer 节点数
2. **组到 Peer 的映射**: 布局中的组和通道的 Peer 节点的对应。实际上,一个组很可能是代表一个组织的 Peer 节点,但是由于服务 API 是通用的并且与组织无关,因此这只是一个“组”。

下面是一个``AND(Org1, Org2)``策略的描述符示例,其中每个组织中有两个peer节点
下面是一个``AND(Org1, Org2)``策略的描述符示例,其中每个组织中有两个 Peer 节点

.. code-block:: JSON
Expand All @@ -44,23 +44,25 @@ Fabric中服务发现的工作方式
}
换言之,背书策略需要来自Org1中一个peer节点和Org2中一个peer节点的签名。它提供了组织中可以背书的(Org1和Org2中都有``peer0``和 ``peer1``)peer节点的名称
换言之,背书策略需要两个分别来自 Org1 和 Org2 的 Peer 节点的签名。它提供了组织中可以背书的(Org1 和 Org2 中都有 ``peer0`` 和 ``peer1``) Peer 节点的名称

SDK选择布局后,根据客户端指定的标准对布局中的peer节点进行选择(SDK可以这样做是因为它能够可以访问账本高度等元数据)。例如,它可以根据布局中每个组的peer节点的数量,优先选择具有更高的账本高度的peer节点,或者排除应用程序发现的处于脱机状态的peer节点。如果无法根据标准选定一个peer节点, SDK将从最符合标准的peer节点中随机选择。
之后 SDK 会随机从列表中选择一个布局。在上边的例子中的背书策略是 Org1 ``AND`` Org2。如果换成 ``OR`` 策略,SDK 就会随机选择 Org1 或 Org2,因为任意一个节点的签名都可以满足背书策略。

SDK 选择布局后,会根据客户端指定的标准对布局中的 Peer 节点进行选择(SDK 可以这样做是因为它能够访问元数据,比如账本高度)。例如,SDK 可以根据布局中每个组的 Peer 节点的数量,优先选择具有更高的账本高度的 Peer 节点,或者排除应用程序发现的处于脱机状态的 Peer 节点。如果无法根据标准选定一个 Peer 节点, SDK 将从最符合标准的 Peer 节点中随机选择。

发现服务的功能
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

发现服务可以响应以下查询:

* **配置查询**: 返回通道中所有组织和通道中orderer终端的 ``MSPConfig``
* **Peer 成员查询**: 返回已加入通道的Peer节点
* **背书查询**: 返回通道中给定链码的背书描述符。
* **本地peer身份查询**: 返回响应查询的peer节点的本地成员信息。默认情况下,客户端需要是peer节点的管理员才能响应此查询
* **配置查询**: 从通道的排序节点返回通道中所有组织的 ``MSPConfig``
* **Peer 成员查询**: 返回已加入通道的 Peer 节点
* **背书查询** 返回通道中给定链码的背书描述符。
* **本地 Peer 成员查询**: 返回响应查询的 Peer 节点的本地成员信息。默认情况下,客户端需要是 Peer 节点的管理员才能响应此查询

特殊要求
~~~~~~~~~~~~~~~~~~~~~~
当peer节点在启用TLS的情况下运行时,客户端在连接到peer节点时必须提供TLS证书。如果未将peer节点配置为验证客户端证书(clientAuthRequired为false),则此TLS证书可以是自签名的
当 Peer 节点在启用 TLS 的情况下运行时,客户端在连接到 Peer 节点时必须提供 TLS 证书。如果未将 Peer 节点配置为验证客户端证书(clientAuthRequired 为 false),则此 TLS 证书可以是自签名的

.. Licensed under Creative Commons Attribution 4.0 International License
https://creativecommons.org/licenses/by/4.0/

0 comments on commit b53bae4

Please sign in to comment.