我知道这是一个奇怪的问题，我敢打赌这可能取决于场景或偏好。
如果我有一组微服务，让我们一般地称它们为 A、B 和 C。这些中的每一个都在自己的身体中运行。
如果 A 需要访问 B 和 C 来处理请求，那么我希望依靠 Kubernetes DNS 解析并创建一个将路由到 B 的服务，以及另一个将路由到 C 的服务。 让我们一般地称这些为 ServiceB 和 ServiceC。
现在，我只是将服务名称存储在发出请求的客户端代码中定义的常量中。
根据您自己的经验，是否有充分的理由将这些存储在配置文件(或configmap)中？我无法想象它们在应用程序的整个生命周期中会发生太大变化。
你在实践中做什么，为什么？
根据您自己的经验，是否有充分的理由将它们存储在配置文件(或configmap)中？
- 作为一般的最佳实践指南，我们倾向于避免在代码中硬编码"神奇的东西"。即使只是为了以后能够将其重定向，例如，从开发服务重定向到 qa 服务以进行一些错误搜索或测试。
你在实践中做什么，为什么？
- 如果它是可远程配置的 - 我们将其置于某种形式的配置中，无论是配置文件、配置映射还是环境变量。我们更喜欢公开它，而不必更改它，而不是硬编码它，然后后悔......根据我们预期更改的频率，我们将其(按升序)放置在：捆绑在 docker 映像中的一些配置文件、包含文件内容的 ConfigMap、带有环境变量的 ConfigMap、直接在容器定义中的环境变量、应用程序正在读取的数据库字段。