微服务中的服务间通信
-
null
-
null
共有1个答案
数据在外部的重要思想之一？数据未锁定。您确实不希望尝试对不同服务所拥有的数据同时持有锁。
此外，您应该假设对用户的响应将是异步的。我们可能会立即确认来自用户的消息，但这只是确认我们已经将请求复制到服务将找到它的地方。
-
我在微服务之间的通信上遇到了麻烦。我有许多spring boot应用程序，它们之间有许多请求HTTP和AMQP（RabbitMQ）。在本地（在dev中），我使用没有Docker图像的Eureka（Netflix Oss）。
-
“在微服务之间添加的同步依赖关系越多，例如查询请求，客户端应用程序的总体响应时间就越差。 “这是真的吗？我认为在同步通信中，我们比异步通信更直接地得到反馈。例如，假设一个用户向微服务a发送http请求，微服务a又异步地向另一个微服务B发送请求，并异步地等待它的答复。如果微服务B关闭，那么用户将等待到超时才能得到响应，而在同步通信中，他将立即得到响应。
-
我实际上在研究微服务，我面临一个问题。 上下文 我正在开发两个微服务： 用户管理，基于spring，使用MySQL数据库 计划管理，基于ASP.NET与SQL Server数据库。此服务的唯一访问点是列出一些RESTFULendpoint的API，如 计费管理，基于MongoDB的node.js。 问题 > 我该怎么做才能只允许通过用户服务访问规划信息，而不耦合这两个服务？知道以后可以从其他地方访
-
我正在从事 服务项目，主要从服务间通信之间的安全角度提出疑问。在我的项目中，我们有 API 网关，它可以筛选所有传入请求是否存在安全问题，然后再将它们路由到适当的微服务。API 网关位于客户端应用程序和微服务之间。然后，它会限制微服务的公开，同时提供其他请求管理功能，例如身份验证、SSL 终止、协议转换、监视、请求路由、缓存等。 假设案例微服务1（MS1） 部门答案预计在这里。
-
在单体架构时，因为服务不会经常和动态迁移，所有服务地址可以直接在配置文件中配置，所以也不会有服务发现的问题。但是对于微服务来说，应用的拆分，服务之间的解耦，和服务动态扩展带来的服务迁移，服务发现就成了微服务中的一个关键问题。 服务发现分为客户端服务发现和服务端服务发现两种，架构如下图所示。 这两种架构都各有利弊，我们拿客户端服务发现软件Eureka和服务端服务发现架构Kubernetes/SkyD
-
我正在构建一个基于Spring云的微服务ML管道。我有一个数据摄取服务，它（当前）从SQL接收数据，这些数据需要被预测服务使用。 普遍的共识是写入应该使用kafka/Rabbitmq使用基于异步消息的通信。 我不确定的是如何编排这些服务？ 我是否应该使用API网关来调用启动管道的摄取？