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

Question

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

在另一方面，Netify提供Netifi经纪人可以在Kubernetes部署。如果我理解得很好，这个代理是为了调​​解应用程序之间的通信，所以那些 Spring Boot RSocket 应用程序不会通过它们的 Kubernetes 服务名称进行通信，而是通过 Netifi 代理。

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

Answer 1

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

当使用 Netifi 代理部署 RSocket 服务时，这些服务将通过它们的 Netifi 服务名称进行通信，而不依赖于 K8s 服务发现。

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

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

• 更简单的 K8s 设置（不必使用负载平衡器或 dns 服务发现）
• 更复杂的负载平衡算法
• 路由流量的能力（RSocket 的核心是点对点）
• 在 K8s 服务和部署在 K8s 之外的服务之间轻松桥接。

当谈到 K8s 时，我们从客户那里看到的最大亮点实际上是让他们在 K8s 中的服务与他们的非 K8s 服务（裸机、PCF 等）进行交互。使用像 Netifi 这样的代理架构，这是一种非常简单、安全和高性能的方式来弥合这些差距。

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

Netifi Broker 从一开始就采用集群设计，以防止出现单点故障情况。我们通常鼓励客户在生产环境中至少部署 3 个代理。集群易于设置并使用多种发现机制。实际上，您可以使用 K8s DNS 来让代理找到自己进行集群，然后使用 Netifi 的服务发现来查找您的服务。就 Netifi Broker 所需的盒子大小而言，它实际上非常小。Netifi Broker 是完全零拷贝的，可以用很少的资源运行。我们在不到 100MB 的内存中运行了具有显着负载 (500K rps) 的代理。这当然是极端的。