如何帮助管理分布式微服务

规模变得越来越大，同一服务的多个实例同时运行，这些微服务之间的通信变得越来越复杂。服务网格是一种新兴的架构形式，旨在以减少管理和编程开销的方式动态连接这些微服务。

什么是服务网格?

从广泛的意义上讲，“服务网格”正如Red Hat公司所描述的那样，“服务网格是一种控制应用程序的不同部分如何共享数据的方法。”

不过这个描述可能包含很多不同的东西。事实上，它听起来很像大多数开发人员所熟悉的来自客户端-服务器应用程序的中间件。

服务网格的独特之处在于，它是为适应分布式微服务环境的独特性质而构建的。在由微服务构建的大型应用程序中，可能存在给定服务的多个实例，它们运行在不同的本地或云计算服务器上。显然，所有这些移动部件都使得单个微服务很难找到他们需要与之通信的其他服务。服务网格会自动处理即时发现和连接服务，这样开发人员和微服务都不必这样做。

将服务网格视为开放式系统互联(OSI)网络模型的第7级软件定义网络(SDN)的等效物。正如软件定义网络(SDN)创建一个抽象层，因此网络管理员不必处理物理网络连接，服务网格将应用程序的底层基础结构与企业交互的抽象体系结构分离。

随着开发人员开始努力解决真正庞大的分布式架构的问题，服务网格的概念出现了。 Linkerd是该领域的第一个项目，诞生于Twitter内部项目的分支。Istio是另一个受欢迎的服务网络，拥有主要的企业支持，起源于Lyft。

服务网格负载平衡

服务网格提供的一个关键特性是负载平衡。人们通常将负载均衡视为网络功能，企业希望防止任何一个服务器或网络链路被流量淹没，因此可以相应地路由其数据包。正如Twain Taylor所描述的那样，服务网格在应用程序级别上做了类似的事情，理解这一点可以让人们很好地理解服务网格就像是应用程序层的软件定义的网络。

本质上，服务网格的一个工作是跟踪分布在基础设施上的各种微服务的哪些实例是“最健康的”。它可能会轮询以查看它们是如何做的，或跟踪哪些实例响应缓慢服务请求，并将后续请求发送到其他实例。服务网格可以为网络路由执行类似的工作，注意到消息需要很长时间才能到达目的地，并采取其他路由进行补偿。这些速度慢的原因可能是底层硬件的问题，或者仅仅是服务被请求超载。重要的是，服务网格可以找到相同服务的另一个实例，并将其路由到该实例，从而最有效地利用整个应用程序的容量。

服务网格与Kubernetes

如果人们对基于容器的架构有些了解，那么可能想知道Kubernetes(流行的开源容器编排平台)适合这种情况。毕竟，Kubernetes管理容器之间如何通信不是其全部要点吗?正如Kublr公司在其企业博客上指出的那样，可以将Kubernetes的服务资源视为一种非常基本的服务网络，因为它提供服务发现和循环请求平衡。但是功能齐全的服务网格提供了更多功能，如管理安全策略和加密，“线路中断”以暂停对慢响应实例的请求。

人们需要了解的是，大多数服务网格确实需要像Kubernetes这样的编排系统。服务网格提供扩展功能，而不是替代功能。

服务网格与API网关

每个微服务都将提供一个应用程序编程接口(API)，作为其他服务与之通信的手段。这引发了服务网格与其他更传统的API管理形式(如API网关)之间的差异问题。正如IBM公司解释的那样，API网关位于一组微服务和外部世界之间，根据需要路由服务请求，以便请求者不需要知道它正在处理基于微服务的应用程序。另一方面，服务网格调解微服务应用程序内部的请求，并需要用户完全了解其环境。

正如Justin Warren所指出的那样，另一种思考方式是服

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!