服务发现为什么不是集中配置的子集？
How is service discovery not a subset of centralized configuration?
我正在研究像 ZooKeeper, Consul and Eureka 这样的共识型工具，它们似乎都在推销同一套解决方案：
- 服务发现
- 动态、集中的配置管理
- 同步原语
- 共识算法
然而，我对这些事情了解得越多，我就越难以理解 服务发现 与动态、集中式 配置管理（ KV对)系统.
我对服务发现的理解（到目前为止）是它允许节点动态搜索、查找和连接到远程服务。因此，如果应用程序使用 AuthService 进行身份验证、授权，它将使用服务发现在 http://auth103.example.org:9103 处查找 AuthService 节点并使用它。
我对动态配置系统的 理解 是它们为节点提供了一个集中式基础设施，可以动态地从配置服务器接收更新，以及向配置服务器发布更新。因此，如果一个应用程序实例决定它需要更新所有其他实例的配置，它会联系配置服务并更新，比如 numPurgerThreads 配置。配置服务随后会更新所有其他应用程序实例，以便它们正确更新各自的配置。
但这不就是同一个问题吗？
在这两种情况下，您：
- 连接到某种查找服务
- 查询数据；或
- 向其发布数据，然后传播到其他节点
服务发现是动态配置对不对？！？！
我真正想做的是：我不能只用这些工具之一实现一个配置服务，这恰好也解决了服务发现问题吗？或者有没有为什么我需要 1 个 Consul 集群用于 config/KV 管理，而另一个，比如说，Consul 集群用于服务发现？
好吧，如果你这样看，这些都只是数据库的变种，或者如果你愿意的话，也可以是数据存储，正如你所描述的那样：
Connect to a lookup service of some sort
Query it for data; or
Publish data to it, which then ripples out to other nodes
您提到的所有用例都需要某种类型的多个客户端连接的数据存储。对于不同的用例，使它们中的一些比其他的更优化的是它们的接口、数据模型、一致性保证等。
具体来说，在服务发现的情况下，一个很好的功能可以是故障检测——例如k/v 存储，允许在服务不再连接时删除服务数据。这样，您可以将服务注册到您的服务发现工具，并知道当服务出现故障或失去连接时，它将不再存在于存储的数据中。
只是为了澄清几个术语，(imo) 动态配置系统可以在运行时更新它们的状态，这与预先定义所有内容（即配置文件）的静态相反。 集中式 CM 意味着只有一个地方可以存储所有配置数据。那么中心化 CM 既可以是静态的也可以是动态的，对吧？
IMO，服务发现有一个 CM 没有的组件，那就是 一个用于自动检测服务的协议。
我猜你需要一个动态的 CM（KV 存储）来实现服务发现，但你不能仅使用服务发现（协议）来实现 CM 存储。以 DHCP 为例（希望我们同意它是一个服务发现协议？）- Dynamic Host Configuration Protocol'，所以它有一个配置方面，还有一个协议，它不仅仅是一个简单的 KV 存储。顺便说一句，它是去中心化的，只是为了说明之前的观点，即 CM 不必是中心化的..
所以服务发现有一个配置方面，但 CM 没有（必然）有一个服务发现。这是否意味着 SD 是 CM 的子集？我会说不。
我正在研究像 ZooKeeper, Consul and Eureka 这样的共识型工具，它们似乎都在推销同一套解决方案：
- 服务发现
- 动态、集中的配置管理
- 同步原语
- 共识算法
然而，我对这些事情了解得越多，我就越难以理解 服务发现 与动态、集中式 配置管理（ KV对)系统.
我对服务发现的理解（到目前为止）是它允许节点动态搜索、查找和连接到远程服务。因此，如果应用程序使用 AuthService 进行身份验证、授权，它将使用服务发现在 http://auth103.example.org:9103 处查找 AuthService 节点并使用它。
我对动态配置系统的 理解 是它们为节点提供了一个集中式基础设施，可以动态地从配置服务器接收更新，以及向配置服务器发布更新。因此，如果一个应用程序实例决定它需要更新所有其他实例的配置，它会联系配置服务并更新，比如 numPurgerThreads 配置。配置服务随后会更新所有其他应用程序实例，以便它们正确更新各自的配置。
但这不就是同一个问题吗？
在这两种情况下，您：
- 连接到某种查找服务
- 查询数据；或
- 向其发布数据，然后传播到其他节点
服务发现是动态配置对不对？！？！
我真正想做的是：我不能只用这些工具之一实现一个配置服务，这恰好也解决了服务发现问题吗？或者有没有为什么我需要 1 个 Consul 集群用于 config/KV 管理，而另一个，比如说，Consul 集群用于服务发现？
好吧，如果你这样看，这些都只是数据库的变种，或者如果你愿意的话，也可以是数据存储，正如你所描述的那样：
Connect to a lookup service of some sort
Query it for data; or
Publish data to it, which then ripples out to other nodes
您提到的所有用例都需要某种类型的多个客户端连接的数据存储。对于不同的用例，使它们中的一些比其他的更优化的是它们的接口、数据模型、一致性保证等。
具体来说，在服务发现的情况下，一个很好的功能可以是故障检测——例如k/v 存储，允许在服务不再连接时删除服务数据。这样，您可以将服务注册到您的服务发现工具，并知道当服务出现故障或失去连接时，它将不再存在于存储的数据中。
只是为了澄清几个术语，(imo) 动态配置系统可以在运行时更新它们的状态，这与预先定义所有内容（即配置文件）的静态相反。 集中式 CM 意味着只有一个地方可以存储所有配置数据。那么中心化 CM 既可以是静态的也可以是动态的，对吧？
IMO，服务发现有一个 CM 没有的组件，那就是 一个用于自动检测服务的协议。
我猜你需要一个动态的 CM（KV 存储）来实现服务发现，但你不能仅使用服务发现（协议）来实现 CM 存储。以 DHCP 为例（希望我们同意它是一个服务发现协议？）- Dynamic Host Configuration Protocol'，所以它有一个配置方面，还有一个协议，它不仅仅是一个简单的 KV 存储。顺便说一句，它是去中心化的，只是为了说明之前的观点，即 CM 不必是中心化的..
所以服务发现有一个配置方面，但 CM 没有（必然）有一个服务发现。这是否意味着 SD 是 CM 的子集？我会说不。