服务发现微服务是否打破了松散耦合的思想？
作为将微服务连接在一起并使其工作的机制，通常建议使用API和服务发现。但它们通常作为自己的微服务工作，但这些微服务显然应该“硬编码”到其他微服务中，因为每个微服务都应该向它们注册并查询其他微服务的位置。这是否打破了松耦合的思想，因为发现服务的丢失意味着其他服务无法通信？
共有1个答案
差不多是的。如果一个微服务“知道”另一个微服务--这意味着它们是高度耦合的。关于其他服务的具体知识来自哪里并不重要：硬编码的、配置文件或者可能是某个服务发现，但它仍然会导致高度耦合。
重要的是要明白，许多微服务传教士只是在宣扬如何在Web API之上构建整体应用程序。他们中的一些人可能认为他们使用的流行语越多越好...不太清楚为什么会发生这种情况。通过使用流行语沙拉而不是真正构建容错和水平可伸缩的应用程序，伪造一门语言并成为“专家”可能更容易。
但是还有另一种方法来看待服务发现：当服务客户机（如SPA应用程序或API网关）使用它时，它可能非常有用。客户端和网关应该了解服务API，否则，整个事情就没有意义了。但是他们可以使用注册表使其更加灵活/动态。
-
null
-
在客户端服务器应用程序上工作，在服务器端，我有一个面向客户端的服务组件，它拦截来自客户端的所有套接字请求，扫描消息后，它通过消息总线路由到不同的服务，因此它们是松散耦合的。 类似这样： 问题是，一旦服务完成了业务逻辑，就需要将回复发送回客户端，但通过“请求处理程序服务”，因此来自所有服务的所有回复消息都通过单个服务组件，即“请求处理程序服务”，因为我没有ChannelHandleContext对象
-
在单体架构时，因为服务不会经常和动态迁移，所有服务地址可以直接在配置文件中配置，所以也不会有服务发现的问题。但是对于微服务来说，应用的拆分，服务之间的解耦，和服务动态扩展带来的服务迁移，服务发现就成了微服务中的一个关键问题。 服务发现分为客户端服务发现和服务端服务发现两种，架构如下图所示。 这两种架构都各有利弊，我们拿客户端服务发现软件Eureka和服务端服务发现架构Kubernetes/SkyD
-
总而言之，我们有： 产品类别: 产品ID、产品名称 订单类别: 订单ID、产品ID、用户ID、订单日期 这些方法中的任何一种可以被认为是最佳实践吗？还是有不同的解决方案？
-
背景 当前有两个服务，分别是user-service和order-service，nacos服务列表中无法发现两个服务 排查 Nacos v2.2.3 依赖已引入，配置文件已配置addr 运行时未出现连接nacos的日志： 希望大佬们可以帮忙看看是什么问题 问题程序链接 https://oss-20001.oss-cn-qingdao.aliyuncs.com/cloud-demo.zip
-
我有几个微服务，每个微服务都有用于CRUD操作的RESTendpoint。我必须创建一个工作流，该工作流将从一个带有一些初始输入的微服务开始，但一个微服务的稍后输出可以用作其他微服务的输入。可以对这些REST API进行一些同步和异步调用。 我已经寻找了一些工作流引擎，但我不认为我可以在不编写任何java代码的情况下创建我的工作流。
-
我们能在Spring Cloud API网关和没有服务发现的情况下生存吗？