SOA 中的服务可发现性答案

【问题标题】：Service discoverability in SOASOA 中的服务可发现性
【发布时间】：2014-12-19 04:48:57
【问题描述】：

我正在阅读有关 SOA 的幻灯片。并且在这一点上有疑问：

Discoverability is beyond the scope of a Web Service

这是否意味着，网络服务不负责发现部分？我的意思是服务提供商将他们的 web 服务提交给服务注册中心，以便客户可以发现它，不是吗？就是那个意思吗？

【问题讨论】：

标签： web-services soa

【解决方案1】：

如果他们谈论在服务注册中心（即：UDDI）之间发现服务的可能性，那是对的，服务不需要知道关于可发现性部分的任何信息。但请记住，服务有一个暴露其元数据的合约，这是发布到服务注册表的数据。图形说明：

查看从 Michael Poulin 的帖子中提取的此注释，这就是我最初试图解释的内容。

现在说到服务可发现性原则，我可以见证这是唯一一个经久不衰的原则显着改变。 Thomas Erl 谈到了这个原则：“这以服务为导向的原则与架构级别的可发现性......在服务级别，可发现性原则是指个人的设计服务，以便它变得尽可能可发现，无论可发现性产品或扩展是否实际存在于其周边实施环境”。

原则定义很好地指出了两件事对服务发现很重要：补充元数据和可以有效解释服务的元数据。我是重新表述原则以指向元数据文档补充服务并添加到此类服务的注册表/存储库中文件。虽然注册表/存储库是基础设施的一个元素并且可能缺席，补充元数据文件到期。绿洲 SOA RM 标准将此类文档标识为“服务描述”。 Michael Poulin

【讨论】：

这一切都是正确的，除了几乎没有人使用 UDDI，当然不是公共 UDDI 注册中心。这是一个好主意，但时机未到。
@JohnSaunders 完全同意。服务发现机制的想法仍然完全有效，即：Netflix Curator（现已移至 Apache）curator.apache.org/curator-x-discovery/index.html
我从事 SOA 已经有一段时间了，从来不需要“发现”服务。如果我不了解该服务，那我为什么要打电话给它？为什么我们不知道它的位置？如果我们移动服务，那么我们只需要一种机制来管理服务 URL 的变化。这不需要发现机制。
嗯，我认为这取决于您的架构的规模和性质，在某些情况下，如果没有服务发现机制就无法继续进行下去，这是对真实案例的精彩描述：jasonwilder.com/blog/2014/02/04/service-discovery-in-the-cloud
对不起，还没有看到负载均衡不起作用的情况。我知道使用简单的服务定位机制的情况，其中客户端根据某些标准查找要使用的端点，但是完整的“服务发现”机制 - 不。那篇文章似乎预设了发现的必要性。