Netifi代理在Kubernetes集群上相比于直接使用RSocket应用程序通信有哪些改进？

Question

Netifi代理在Kubernetes集群上相比于直接使用RSocket应用程序通信有哪些改进？

9

假设我有一个 Kubernetes 集群，我在其中部署使用 RSocket 通信的 Spring Boot 应用程序。为了相互调用，它们将使用 Kubernetes 服务名称，因此我们将依赖于该“注册表”进行发现和路由。

另一方面，Netify 提供了一个可以在 Kubernetes 上部署的 Netifi broker。如果我理解正确，这个 broker 的作用是在应用程序之间进行通信的中介，因此这些 Spring Boot RSocket 应用程序不会通过它们的 Kubernetes 服务名称进行通信，而是通过 Netifi broker 进行通信。

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

- codependent

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- gregwhitaker · Accepted Answer

全面披露：我是Netifi的联合创始人之一。

在使用Netifi代理部署RSocket服务时，服务将通过其Netifi服务名称进行通信，而不依赖于K8s服务发现。

Netifi代理提供了许多优势，包括服务发现、预测性负载平衡和RSocket流量的动态路由。Netifi代理提供的负载平衡考虑了下游延迟，并实时将流量路由到最低延迟的节点。服务发现也非常快，因为它不基于DNS，而是通过RSocket在Netifi代理节点之间传递信息。

使用Netifi代理在K8s中部署RSocket服务的主要优点是：

更简单的K8s设置（无需涉及负载均衡器或DNS服务发现）
更复杂的负载平衡算法
能够路由流量（RSocket的核心是点对点）
轻松在K8s服务和部署在K8s之外的服务之间桥接。

我们发现客户在使用K8s时遇到的最大问题实际上是让他们的K8s服务与非K8s服务（裸机、PCF等）进行交互。使用Netifi这样的代理架构可以轻松、安全、高效地弥合这些差距。

编辑（回答有关弹性的问题）：

Netifi Broker是从头开始设计的，具有集群功能，以防止单点故障情况。我们通常鼓励客户在生产环境中部署至少3个Broker。集群易于设置，并使用多种发现机制。您实际上可以使用K8s DNS让Broker找到彼此并进行聚类，然后使用Netifi的服务发现来管理您的服务。就Netifi Broker所需的盒子大小而言，它实际上非常小。Netifi Broker完全是零拷贝的，可以运行在非常少的资源下。我们已经在不到100MB的内存中处理了大量负载（500K rps）的Broker。当然，这是极端情况。我们在Netifi内部运行的Broker在双核机器上都很舒适地运行，配备2或4 GB的RAM，这也是我们建议客户为其实例分配的资源水平。