服务发现
使用场景
为什么需要服务发现
为了在peer节点上执行链码，向orderer节点提交交易和更新交易的状态，applicathin需要连接sdk暴露的API。
但是，SDK需要很多信息才能使应用程序连接上相关的peer节点。除了在通道中的orderer节点和peer节点的CA和TLS证书，还包括它们的ip地址、端口以及安装了chaincode的peer节点的背书策略（只有这样application才知道向哪些peer节点发送交易）。
在fabric 1.2之前，这些信息是静态编码的，所以这种方法无法动态适应区块链网络的变化（例如添加已安装chaincode的peer节点，或者peer节点的零时离线）。静态配置也使得application无法适应背书策略的变化（在新的组织加入通道的时候可能会出现这种情况，即背书策略的而变化）。
而且，application也无法了解哪些peer节点更新了账本，哪些没有更新。因此，application可能会向那些没有同步更新账本数据的peer节点提交交易提案，导致交易在提交时失效同时浪费了资源。
服务发现通过让节点动态地计算所需的信息并以可消费的方式将信息提供给SDK，从而改进了这个过程。
在fabric区块链网络中服务发现时如何运作的？
应用程序在启动时会知道一组应用程序开发者或者管理员信任的 Peer 节点，以便对发现查询提供可信的响应。application使用的候补peer节点最好属于同一个组织。需要注意的是，为了让peer节点知道发现服务，他们必须定义EXTERNAL_ENDPOINT配置。要知道如何定义，请参考Service Discovery CLI文档。
application向发现服务发送一个配置查询以获得所有的静态信息，否则，就需要和网络中的其他节点进行通信。这些信息可以通过查询 Peer 节点的发现服务来更新。
发现服务是运行在peer节点上，而不是在application上，通过使用 gossip 通信层维护的网络元数据信息来查找在线的 Peer 节点。它也会从 Peer 节点的状态数据库中获取信息，比如相关的背书策略。
有了服务发现，application就不需要在指定要哪些 Peer 来背书了。SDK 可以简单地向发现服务发送一个通道名和链码 ID 来查询需要哪些 Peer 节点。发现服务会计算出包含下边两个对象的描述：
- 布局（Layouts）：一个 Peer 节点分组的列表和每组被选择的 Peer 节点的数量。
- Peer 节点和组的映射：从分布中的组到通道中的 Peer 节点。实际上，每个组中的节点都应该是同一个组织的，但是因为服务 API 是通用的并且没有区分组织，所以这里用“组”的概念。
发现服务的作用
发现服务可以支持如下查询：
- 配置查询：返回通道中所有组织和排序节点的 MSPConfig。
- 节点成员查询：返回加入通道的 Peer 节点。
- 背书查询：返回通道中指定链码的背书描述。
- 本地节点成员查询：返回响应查询的 Peer 节点的本地成员信息。默认情况下，需要管理员身份的客户端响应该查询。
特殊要求
当 Peer 启用了 TLS 的时候，客户端要连接 Peer 节点也必须提供 TLS 证书。如果 Peer 节点没有要求验证客户端证书（clientAuthRequired 设置为 false），这个 TLS 证书就可以是自签名的。