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

Question

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

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

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

Answer 1

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

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

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

使用 Netifi 代理在 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) 的代理。 这当然是极端的。 我们 Netifi 的内部代理非常舒适地在具有 2 或 4 GB RAM 的双核机器上运行，这也是我们建议客户为其实例分配的资源水平。