spring-boot - 与在Kubernetes集群上使用直接RSocket应用程序通信相比，Netify Broker有什么改进？(What does Netify broker improve over using direct RSocket application communication on a Kubernetes cluster?)

Question

Let's suppose I have a Kubernetes cluster where I deploy Spring Boot applications that communicate using RSocket .

(假设我有一个Kubernetes集群，其中部署了使用RSocket进行通信的Spring Boot应用程序 。)

In order to call each other they would use the Kubernetes service name, so we would be relying of that "registry" for discovery and routing.

(为了彼此调用，他们将使用Kubernetes服务名称，因此我们将依靠该“注册表”进行发现和路由。)

On the other hand, Netify offers a Netify broker that can be deployed on Kubernetes.

(另一方面，Netify提供了可以在Kubernetes上部署的Netify代理 。)

If I understood well, this broker is meant to mediate the communication between applications, so those Spring Boot RSocket applications wouldn't communicate via their Kubernetes service names, but through the Netify broker.

(如果我理解得很清楚，那么该代理程序旨在协调应用程序之间的通信，因此那些Spring Boot RSocket应用程序将不会通过其Kubernetes服务名称进行通信，而是通过Netify代理进行通信。)

What are the advantages and disadvantages of each of the approaches?

(每种方法的优点和缺点是什么？)

  ask by codependent translate from so

Answer 1

等待大神答复