Service Mesh微服务架构的崛起

SAMIR BEHARA

本文将解释Service Mesh相关概念,为什么云原生应用需要它,以及这项技术被社区热烈拥抱、积极采用的原因。

毫不夸张地说,微服务已经席卷了整个软件行业。从Monolith过渡到微服务架构,可以让我们频繁、独立而可靠地部署应用。

然而,在微服务架构中,一切都不是绿色的,它必须处理在设计分布式系统时遇到的相同问题。

然而,微服务架构不是万能的,在设计分布式系统时会遇到很多有待解决的问题。说到这里,我们不妨首先回顾一下关于分布式计算的8大谬误——

  • 网络是可靠的(The Network is Reliable)
  • 延迟为零(Latency is Zero)
  • 带宽是无限的(Bandwidth is Infinite)
  • 网络是安全的(The Network is Secure)
  • 拓扑不会改变(Topology does not Change)
  • 有一名管理员(There is one Administrator)
  • 传输成本为零(Transport Cost is Zero)
  • 网络是同质的(The Network is Homogenous)

在微服务体系结构中,对于网络的依赖带来了可靠性问题。随着服务数量的增加,我们必须处理它们之间的交互,监视整个系统的健康状况,处理容错、日志记录,处理多个故障点等等。每个微服务都需要有这些共同的功能,以便服务通信是平滑和可靠的。但是,如果你要处理几十上百个微服务,操作难度光是听起来就有些吓人。

什么是服务网格?

Service Mesh可以定义为在微服务体系结构中处理服务间通信的基础结构层,它减少了与微服务体系结构相关的复杂性,并提供了许多治理功能,如 -

  • 负载均衡(Load Balancing)
  • 服务发现(Service Discovery)
  • 健康检查(Health Check)
  • 身份验证(Authentication)
  • 流量管理和路由(Traffic Management & Routing)
  • 断路和故障转移(Circuit Breaking and Failover Policy)
  • 安全(Security)
  • 监控(Metrics & Telemetry)
  • 故障注入(Fault Injection)

为什么需要Service Mesh?

在微服务架构中,处理服务到服务的通信是企业IT的一大挑战。大多数时候,我们需要依赖第三方库或者组件来提供服务发现、负载均衡、断路器、监控等功能。像Netflix这样的公司,他们开发了自己的库,比如Hystrix for Circuit Breaker、Eureka for Service Discovery、Ribbon for Load balanced等,在其组织中得到了广泛的使用。

然而,这些组件需要在应用代码中进行配置,而且语言不同,实现方式策略也会有所不同。在升级这些外部组件时,我们需要更新应用、验证并部署所有改动。如此便产生了一个问题,我们的应用代码编程了业务和这些附加配置混合体。这种紧密耦合增加了整个应用的复杂性——开发人员现在还需要了解这些组件是如何配置的,以便在遇到任何问题时能够排除故障。

Service Mesh适时出现,将复杂性从应用中分离了出来,并将其放入服务代理(service proxy)代为处理。这些服务代理提供了如流量控制、断路、服务发现、身份验证、监控、安全性等等功能特性。那么对于应用来说,只需要关心业务功能的实现即可。

假设在我们的微服务体系结构中,您有5个服务相互通信。与其在每个微服务中构建配置、路由、遥测、日志记录、断路等常见的必要功能,不如将其抽象为一个单独的组件——这里称为“服务代理”(service proxy)。

随着Service Mesh的引入,责任的划分变得清晰,开发人员的生活也更加轻松——如果存在问题,开发人员可以根据应用程序或网络相关的原因,轻松地确定根源。

Service Mesh是如何实现的?

要实现Service Mesh,可以将代理与服务一起部署,该模式被称为sidecar。

Sidecars抽象了应用程序的复杂性,处理了诸如服务发现、流量管理、负载平衡、线路中断等功能。

Lyft的Envoy是目前非常流行的云原生应用开源代理。特使在每个服务旁运行,并以平台无关的方式提供必要的特性。所有到我们的服务的流量都通过特使代理。

而Istio是一个连接、管理和保护微服务的开放平台。它在Kubernetes社区非常流行,并被广泛采用。

在这一点上,Istio是服务网格的最佳实现之一,它使我们能够在不深入了解底层基础设施的情况下部署微服务。

开源PaaS Rainbond在v3.6.0版本中加入了Service Mesh开箱即用的特性,主要特点包括业务代码无入侵、跨语言&跨协议、支持主流微服务架构、通过插件式扩展来实现治理功能等。


关于Rainbond

Rainbond是一款以应用为中心的开源PaaS,由好雨基于Docker、Kubernetes等容器技术自主研发,可作为公有云或私有云环境下的应用交付平台、DevOps平台、自动化运维平台和行业云平台,或作为企业级的混合云多云管理工具、Kubernetes容器管理工具或Service Mesh微服务架构治理工具。

猜你喜欢

转载自blog.csdn.net/ZYQDuron/article/details/80937226