让我们首先回顾一下什么是服务发现-下面是一个很好的解释：https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/（此链接应该能很好地澄清所问的问题）
下面是它在实践中的应用示例：假设您有服务A使用的服务B。服务B（与SOA中的大多数服务一样）实际上是B类型应用程序的群集。服务A需要使用群集B的一个节点，而B节点的群集是动态的，即B节点的创建和终止取决于整个B服务上的负载。现在，我们希望服务A在每次需要使用服务B时与活动B节点通信。为此，我们将使用服务发现工具来在任何给定时间向我们提供活动B节点之一的地址。
因此，尝试回答您的上述问题，将端点服务器信息（特别是端点地址）作为静态配置放在一个配置文件中（在服务A启动时读取），并不会在服务B端点可能不断变化时给予您所希望的动态。

云服务器架构正在改变我们构建Web应用程序的方式，我们正在从单一的大型应用程序转变为将其分解为越来越小的可单独部署的服务（称为微服务），这些服务共同形成大型应用程序。
让我们考虑一个服务要与其他服务通信的场景，比如说服务A需要与服务B通信。服务A需要知道服务B的IP地址和端口号。解决该问题最简单的方法是在服务A中维护一个配置文件，该文件保存服务B的IP地址和端口。这种方法有几个缺点
请考虑以下情况：-

• 当应用程序中的微服务数量增加时
• 很难在配置文件中进行管理
• 当发生一些管理不善时，很容易出错
• 它缺乏在以后某个时间点更改IP或端口的灵活性
• 它无法利用云的功能根据需求动态扩展或收缩。

这种简单的方法过于静态，会冻结云因此，新的解决方案应运而生

替代解决方案：服务发现

服务发现通过提供一种方法来帮助解决上述问题

• 为了注册服务，即当新服务变为在线时，它将自己注册到具有其IP和端口的服务发现服务。
• 帮助服务查找其他服务，即帮助服务A查找服务B。
• 运行状况检查：检查示例的运行状况，并在示例运行状况不佳时将其删除。
• 在服务脱机时取消注册。

因此，它有助于利用云的全部功能来根据需求动态扩展和收缩，并使体系结构彼此松散耦合

在云环境中，Docker映像被动态部署在任何机器或IP +端口组合上，依赖服务在运行时更新变得很困难。服务发现的创建仅出于此目的。
服务发现是在微服务架构下运行的服务之一，它注册在服务网格下运行的所有服务的条目，所有操作都可以通过RESTAPI获得，因此无论何时服务启动并运行，各个服务将它们自己注册到服务发现服务，并且服务发现服务维护心跳以确保那些服务是活动的。服务发现还有助于在以公平的方式部署的服务之间分发请求。

不得不承认，你说的方法是可行的，但如果服务太多，需要管理的复杂度会增加，而且手动配置服务列表也很容易出错。
服务发现并不是一种将要调用的服务列表放入客户端配置的简单方法，而是保存所有服务本身的示例列表。
您可以简单理解，我们有一个注册服务，可以自动管理要访问的服务示例列表，当您添加服务或关闭服务时，注册服务会自动更新您的服务列表，当您调用它时，会从注册中心获取最新的服务列表进行调用，为了不影响性能，您也可以在客户端缓存服务列表

如果您有2个微服务，比如A和B，并且您希望A与B通信，则A将使用服务发现方法（工具）在微服务架构中找到B。
不仅是客户端到服务器的通信，还包括可能在同一服务器上运行的2个微服务。
它解决的问题是在集群中的2个不同节点上运行的2个微服务可以发现彼此，如果没有服务发现，这是不可能的。
您可以了解kurbernetes如何支持服务发现，例如使用coreDNS通过DNS。https://kubernetes.io/docs/concepts/services-networking/service/