什么是服务网格?

什么是服务网格?

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

为什么需要服务网格?

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

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

服务网格有什么作用?

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

来源:nginx.com

负载均衡

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

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

服务发现

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

监控

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

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

服务网格2来源:redhat.com

加密

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

验证

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

什么时候使用服务网格?

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

结论

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

促销

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

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

如果您对此信息有任何疑问,我们随时可以回答与本文相关的任何问题,一年 365 天,一周 7 天,一天 24 小时。

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

相关阅读:

Posted in: LinuxTags: