Service Mesh微服务架构的崛起

绝地灬酷狼 2022-10-02 03:49 146阅读 0赞

[2019独角兽企业重金招聘Python工程师标准>>> ][2019_Python_] ![hot3.png][]

[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开箱即用的特性，主要特点包括业务代码无入侵、跨语言&跨协议、支持主流微服务架构、通过插件式扩展来实现治理功能等。

*  [开源PaaS Rainbond v3.6.0正式发布，Service Mesh开箱即用][PaaS Rainbond v3.6.0_Service Mesh]
 *  [解读Rainbond ServiceMesh微服务架构][Rainbond ServiceMesh]
 *  [Rainbond插件体系设计简介][Rainbond]

转载于:https://my.oschina.net/xiaominmin/blog/1841633

[2019_Python_]: https://my.oschina.net/u/2663968/blog/3061697
[hot3.png]: /images/20220113/b5a9a0bb99ea4c3a961bb11f4132aecb.png
[SAMIR BEHARA]: https://dotnetvibes.com/2018/07/02/the-rise-of-service-mesh-architecture/
[PaaS Rainbond v3.6.0_Service Mesh]: https://www.goodrain.com/2018/06/20/rainbond-20180620/
[Rainbond ServiceMesh]: https://blog.goodrain.com/2018/05/15/rainbond-20180515/
[Rainbond]: https://blog.goodrain.com/2018/02/24/rainbond-20180224/