假设我有一个Kubernetes集群，在其中部署Spring Boot applications that communicate using RSocket。为了彼此调用，他们将使用Kubernetes服务名称，因此我们将依靠该“注册表”进行发现和路由。
另一方面，Netify提供了可以在Kubernetes上部署的Netifi broker。如果我了解得很清楚，那么该代理程序旨在协调应用程序之间的通信，因此那些Spring Boot RSocket应用程序将不会通过其Kubernetes服务名称进行通信，而是通过Netifi代理进行通信。
每种方法的优点和缺点是什么？
最佳答案
全面披露:我是Netifi的联合创始人之一。
与Netifi代理一起部署RSocket服务时，服务将通过其Netifi服务名称进行通信，而不依赖于K8s服务发现。
Netifi代理为您提供了许多优势，包括服务发现，可预测的负载平衡以及RSocket流量的动态路由。 Netifi代理提供的负载平衡考虑了下游延迟，并实时将流量路由到最小潜伏节点。服务发现也非常快，因为它不是基于DNS的，而是通过Netifi代理节点之间的RSocket进行的。
使用Netifi代理在K8中部署RSocket服务的主要优点是:
当谈到K8时，我们看到客户最大的痛点实际上是使他们在K8中的服务与他们的非K8服务(裸机，PCF等)交互。借助Netifi这样的中介架构，这是弥合这些差距的一种非常简单，安全且高效的方式。
编辑(回答有关弹性的问题):
Netifi Broker是从头开始设计的，具有群集功能，可以防止出现单点故障的情况。我们通常鼓励客户在生产环境中至少部署3个经纪人。群集易于设置，并使用多种发现机制。实际上，您可以将K8s DNS用于代理，以找到要群集的代理，然后将Netifi的服务发现用于您的服务。就Netifi Broker所需的盒子大小而言，它实际上很小。 Netifi Broker完全是零拷贝的，几乎可以用很少的资源运行。我们运行的代理在不到100MB的内存中具有很大的负载(500K rps)。那当然是极端的。我们在Netifi的内部代理非常舒适地在具有2或4 GB RAM的双核计算机上运行，这就是我们建议客户也为其实例分配的资源级别。