问什么是服务定位器？

EN

这两件事本质上是一样的。服务定位器就是任何中央系统，它可以让您找到一个服务来处理某些请求。使用服务定位器设计模式，您可以使用它从服务定位器获取服务实现(实际上是代码级的接口)。

更普遍的是，该系统通常用于分布式计算，在网络中找到一个节点，该节点可以满足其他节点的请求。

例如，某些客户端可能希望对某些数据执行一些计算。让我们说，有多种方法来完成这个计算，每种方法都是作为一个服务实现的，但是客户机并不关心实际使用的是什么。客户端只需向服务定位器请求任何服务，而不必担心返回哪种特定类型。

在这两种情况下，好处和缺点大致相同。服务定位器使您能够更好地模块化您的程序，并使您减少对特定服务实现的担忧。另一方面，您会得到这个集中式的故障点，这可能是系统中的一个薄弱环节。和其他一切一样，这是一种权衡，所以没有简单的“好与坏”的答案。

你给出的两个定义是不同的东西。

第一个(美化注册表)实际上称为服务定位器。这意味着其他类依赖的实体(称为Service )可以在运行时检索它们的依赖项。看看这篇文章的一个例子，以及为什么它被认为是反模式的原因。

第二个(DI容器)不一定被认为是服务定位器。这取决于你在哪里使用它。如果您在类中使用它来获取依赖项，那么它将被用作服务定位器。另一方面，如果您只在成分根中使用它，那么它就不会用作服务定位器。许多人认为在复合根中使用DI容器是进行依赖注入的非常好的方法。

服务定位器/注册中心有两个关键问题：

1. 找到注册表。通常，唯一的方法是显式地告诉您的代码注册中心的位置，尽管在某些情况下(DI容器、发现协议(如吉尼)，发现注册表并不那么困难，甚至可以作为给定的方式提供。
2. 确保登记册中的信息是正确的/相关的。这实际上是最难的部分。即使没有恶意攻击的问题，确保任何持久的服务集合实际上都是正确策划的，这也是一个可怕的劳动密集型问题。(通常，您可以在信息不正确的情况下自动检测-需要足够的努力-但实际上无法确定如何在没有人工干预的情况下解决问题。)

OTOH，复制分布式注册表是完全可行的，只要它包含的映射的变化速度不太快。如果不是复制注册表，您认为DNS是什么？(嗯，还有额外的东西。)这确实表明，使用DNS来处理注册表管理的硬部分可能是一个明智的举动，而不是在更高级别的网络堆栈…上再次复制所有这些内容。