什么是服务网格?

什么是服务网格?

服务网格是一个额外的基础设施层,它提供了给定应用程序中所有服务之间的通信方式。 它通常部署为每个服务实例旁边的一系列代理。 由于服务网格代理与应用程序服务一起部署,而不是作为应用程序服务的一部分,因此它们通常被称为边车。 这意味着作为一个整体,这些 Sidecar 代理是一个网状网络和一个独立于应用程序的基础设施层。 服务网格不仅代理应用程序中所有服务之间的通信,而且由于所有内部和外部请求都通过它,它提供了一种处理许多可以从应用程序中混淆的任务的方法。

为什么需要服务网格?

高可用性应用程序采用由服务组成的微服务架构变得越来越普遍。 每个服务负责整个应用程序中的特定内容。 这种架构提供了灵活性,因为每个谨慎的服务都可以采用不同的技术、编程语言,并根据其特定目的进行优化。 关注点分离通过封装功能有助于简化开发。 它还有助于更快地进行水平扩展,从而可以直接添加更多服务来处理更多负载。

随着服务数量的增加,它们的互连性也在增加。 这就是服务网格变得有吸引力的地方。 在由数十个不同服务和数百或数千个实例组成的广泛分布式应用程序中管理所有服务之间的通信并非易事。 在服务网格存在之前,需要在应用程序级别管理通信。 开发人员需要考虑并在应用程序中构建每个谨慎服务通信的机制。 这将需要对每个单独的服务的依赖关系进行深入和全面的理解,因为它与系统中的其他服务有关。

服务网格有什么作用?

除了促进给定应用程序中所有服务之间的通信之外,服务网格还提供了许多额外的功能和好处。

来源:nginx.com

负载均衡

对于像 Kubernetes 这样的编排基础设施,有一个内置的服务网格概念,它使用它的服务组件来执行服务发现和循环负载平衡的一些基本处理。 这可能是一个开始,但是随着应用程序变得越来越复杂,将需要更强大的负载平衡。 接受传入请求并将其传递给下一个可用服务是不够的。

服务网格可以查看并分析应用程序中的所有流量。 这意味着服务网格可以智能地将流量专门路由到具有更高快速响应可能性的服务或实例。 此外,服务网格可以根据延迟阈值智能地从轮换中移除特定服务。 如果服务变得不健康并且对请求的响应始终缓慢,则服务网格将悄悄地将该服务拉出轮换,以便稍后再次尝试。

服务发现

微服务架构要求服务不仅要了解如何相互通信,而且在更基础的层面上,服务需要知道其他服务的存在。 服务网格代理,部署有容器的边车,使新服务的几乎即时注册可用于更广泛的服务网格。 这意味着更广泛的应用程序可以立即利用新启动的资源。

监控

使用具有微服务架构的服务网格的一个巨大优势是它可以监控应用程序中的服务。 类似于在数千个单独的容器之间进行通信的困境,提供监控分布式应用程序的方法是一个难以回答的问题。 以前,它需要开发人员让应用程序了解任何监控基础设施以及如何与该基础设施进行通信。 考虑到服务在任何给定应用程序中的不同行为,这可能意味着必须编写一个库来提供一种可重用性的方法来监视应用程序不同部分的约定。

服务网格不断收集有关网格内以及应用程序内所有通信的信息。 这些数据是免费提供的,服务网格实现通常可以将该数据放入其他服务(如 Prometheus)进行检查。 从代理级别到服务级别都有流量指标,可以深入了解延迟、饱和度和错误。 服务网格可能会显示分布式跟踪,这允许深入了解服务到服务级别的请求,因为它们在服务网格中移动。 服务网格还可以提供访问日志,以帮助用户从单个实例的角度理解请求。

服务网格2来源:redhat.com

加密

微服务架构的另一个考虑因素是如何处理加密。 从应用程序的一个部分流向另一部分的请求需要在执行过程中进行加密和解密。 在应用程序层上管理这个只是另一个级别的复杂性,可能已经是一个复杂的业务逻辑,意味着该服务要执行。 服务网格可以再次混淆应用层的这一职责。 它可以处理加密和解密,并且在可能的情况下,它可以通过重用持久连接而不是创建新连接来提高性能。 创建新关系通常是一项昂贵的操作。 减少促进服务之间通信所需的新连接数量是使用服务网格的巨大好处。

验证

一项服务如何知道另一项服务的请求来自何处? 是否应该处理该请求? 该请求是否经过审查? 当考虑在微服务架构中发生的大量请求时,就会出现这些问题。 应用程序可以处理身份验证和授权,但是当有这么多不同的服务需要相互通信时,这是一个复杂的问题。 服务网格中的 sidecar 代理已经在侦听、查找和发送请求到他们需要去的地方。 从这个角度来看,将请求的身份验证和授权从应用程序中提取出来,并将其留给请求的基础架构,这对应用程序来说无疑是一个胜利。 开发人员不再需要关心一个服务将如何向另一个服务进行身份验证。

何时使用服务网格?

这个问题的答案取决于对应用程序的分析。 服务网格通常在具有一些编排层(如 Kubernetes)的微服务架构中最有用且最容易实现。 Istio,对于 example,可以轻松地作为 Kubernetes 应用程序中 pod 的 sidecar 部署,并在路由、负载平衡、监控等方面为应用程序提供即时的实际好处。 对于不使用某些编排服务来处理资源供应的应用程序,实现服务网格更加复杂,并且可能会失去其作为在应用程序不同部分之间共享数据的开箱即用解决方案的一些光彩。

结论

最终,服务网格是基于微服务的高度协调的应用程序的有力促进者。 它在应用程序和通信基础设施之间提供了清晰的划分。 这种描述使开发人员专注于开发与添加新功能和错误修复有关的应用程序。 它还可以帮助运营团队简洁地进行应用程序管理。

促销

我们以成为 Hosting™ 中最有帮助的人而自豪!

我们的支持团队由经验丰富的 Linux 技术人员和才华横溢的系统管理员组成,他们对多种网络托管技术有着深入的了解,尤其是本文中讨论的技术。

如果您对此信息有任何疑问,我们将随时为您解答与本文相关问题的任何询问,每天 24 小时、每周 7 天、每年 365 天。

如果您是完全托管的 VPS 服务器, Cloud 专用,VMWare 私有 Cloud私有父服务器, 托管 Cloud 服务器或专用服务器所有者,并且您对执行概述的任何步骤感到不舒服,可以通过电话@800.580.4985 联系我们, 聊天,或支持票以帮助您完成此过程。