服务发现
为什么我们需要服务发现？
为了在peer节点上执行链码，向orderer节点提交交易，并且更新交易的状态，应用程序通过SDK链接公开的API。
但是，SDK需要大量信息才能允许应用程序链接到相关的网络节点。除了通道orderer节点和peer节点的CA以及TLS证书，以及orderer节点和peer节点的IP地址和端口号以外，还必须知道相关的背书策略以及哪些peer节点安装了链码(这样应用程序才能知道哪些peer节点可以发送链码提案)。
在v1.2版本之前，这些信息是静态编码的。但是，此实现不会对网络更改产生动态响应(例如，已安装相应链码的新增peer节点，或临时离线的peer节点)。静态配置也不允许应用程序对背书策略本身的更改做出响应(可能在新组织加入通道时发生)。
此外，客户端应用程序无法知道哪些peer节点更新了账本数据，哪些没有更新。因此，应用程序可能会向那些没有向网络中其他peer节点同步账本数据的peer节点发送交易提案，从而导致交易在提交时失效并因此浪费资源。
发现服务通过让peer节点动态计算所需信息并以可消费方式将其呈现给SDK来改进此过程。
发现服务是如何在fabric中运作
被应用程序开发人员/管理员信任的一组peer节点，提供对发现查询的真实响应，从而引导应用程序。客户端应用程序使用同一组织中的好的候选peer节点。
应用程序向发现服务发出配置查询，并获取与网络的其余节点通信所需的所有静态信息。通过向peer节点的发现服务发送后续查询，可以在任何时候刷新该信息。
在peer节点上运行的服务(并不是运行在应用程序上)，并且使用由gossip通讯层维护的网络元数据信息来找出哪些peer节点在线。它还从peer节点的状态数据库中提取信息，例如任意相关的背书策略。
通过发现服务，应用程序不再需要指定他们需要背书的peer节点。SDK可以简单地向发现服务发送查询，询问给定通道和链码ID需要哪些peer节点。然后，发现服务将计算由两个对象组成的描述符：
- Layouts: peer节点组列表和从每组中选择相应数量的peer节点个数
- Group to peer mapping: �Layouts中peer节点组与通道节点的映射关系。在实践中，每个组很可能是代表单个组织中的peer节点，但由于服务API是通用的而且对组织一无所知，因此这只是一个“组”。
以下是策略(AND(Org1,Org2))的示例，其中每个组织中有两个peer节点。
Layouts: [
QuantitiesByGroup: {
“Org1”: 1,
“Org2”: 1,
}
],
EndorsersByGroups: {
“Org1”: [peer0.org1, peer1.org1],
“Org2”: [peer0.org2, peer1.org2]
}
换句话说，背书策略需要来自Org1的peer节点以及Org2的peer节点的签名。并且它提供了那些组织中可以背书的可用peer节点的名称(Org1和 Org2中的peer0和peer1节点)。
然后SDK从列表中选择随机layout。在上面的示例中，背书策略是Org1以及Org2。如果它是一个OR策略，SDK将随机选择Org1或Org2，因此来自任一Org的peer节点的签名将满足该策略。
SDK选择layout后，它会根据客户端指定的条件从layout中的peer节点进行选择(SDK可以这样做，是因为他可以访问像账本高度这样的元数据)。例如，它可能更喜欢拥有更高账本高度的peer节点，或者排斥那些应用程序发现已经离线的peer节点，根据layout中定义的每组中peer节点的数量。如果基于标准没有一个peer可供选择，则SDK将从最符合标准的peer节点中随机选择。
发现服务的功能
发现服务可以响应一下的请求：
- Configuration query(配置查询)：返回所有组织的MSPConfig以及通道的orderer端点。
- Peer membership query(peer节点关系查询)：返回已经加入通道的peer节点
- Endorsement query(背书策略查询)：返回通道中给定链码的背书策略描述符
- Local peer membership query(本地peer节点关系查询)：返回响应查询的peer节点的本地成员关系信息。 默认情况下，客户端需要是有管理员权限的peer节点才能响应此查询。
特殊要求
当peer节点启用了TLS认证，那么客户端链接peer节点的时候必须提供相应的TLS证书。如果peer 节点没有配置验证客户端的证书(core.yaml中的配置项clientAuthRequired设置为false)，此TLS证书可以自签名。
