为什么要选择 Service Mesh？ | 云原生社区（中国）

点击查看目录

本文为翻译文章，点击查看原文。

除非你长期与世隔绝，否则你应该听说过 Kubernetes，他已经称为高速发展的互联网公司的一条准则。最近又有一个热门话题–Service Mesh（服务网格），它已经被这些高速发展公司用来解决一些特定的问题。所以如果你想了解什么是 Service Mesh，接下来我可以给你一个更好的解释。

互联网应用的演进

为了理解 Sevice Mesh 的重要性，我们通过四个阶段来简短的回顾下互联网应用的发展历程。

还记得那些年吗？所有的代码库都打包成一个可执行和部署的软件包。当然，至今在某些使用场景下这个方式依然是很管用的。但是对于一些业务快速增长的互联网公司，在应用的可扩展性、快速部署和所有权等方面遇到了阻力。

微服务的思思想很简单，依照 SLA（服务等级协议）将单体应用拆分成多个模块。这种方式运行效果显著，所以广泛为企业所接受。现在，每个团队都用他们喜爱的语言、框架等自由地设计他们的微服务。然后它开始看起来就像下面这样。

我们曾经在我的一个项目中开玩笑说，那里有各种语言的微服务:)

尽管微服务解决了单体应用的一些问题，但现在公司有一些严重问题。

对负责构建和部署的人来说这就是一个噩梦。

而且这些服务在虚拟机中共享同一个 OS，但为了达到可移植性，服务之间需要隔离或者被封装到独立的 VM 镜像。微服务典型的架构设计如下图所示：

但为每个服务/副本安装在一台独立的虚拟机上，花费是非常高的。

容器是利用 Linux 中的 cgroups 和 namespace 的一种新的操作系统级别的虚拟化技术，通过共享主机的操作系统，实现为不同的应用隔离运行环境的。Docker 是目前最流行的容器运行时。

所以我们会为每个微服务创建一个容器镜像并以容器形式发布成服务。这样不仅可以在一个操作系统上实现应用运行环境的隔离，而且启动新的容器相比于启动新的 VM 速度更快、成本也更低！使用容器技术之后的微服务设计看起来就像这样。

容器化解决了构建和部署的问题，但还没有完美的监控解决方案！那要怎么办？我们还有其他问题吗？管理容器！

使用容器运行一个可靠的基础设施层需要注意以下几个重要的点：

Kubernetes 是当下最流行的容器编排工具，它彻底改变了我们对基础设施的看法。Kubernetes 侧重于健康检查，可用性，负载均衡，服务发现，扩展性，跨主机调度容器等等，很神奇！

我们要的就是这样吗？

并不完全是，仅仅这样还不能解决在微服务阶段提到的服务监控/观测的问题。这只是冰山一角。微服务是分布式的，所以管理微服务不是件容易的事。

我们需要考虑一些最佳实践来便捷地运行微服务。

像 Netflix 这样的公司已经推出了几种工具，并接受了那些运行微服务的做法。

现在，为了满足这些最佳实践的唯一方法是在每个微服务上使用一个客户端库来解决每个问题。所以每个服务的结构看起来就像这样。

但这是针对像 Service A 这样的用 JAVA 写的服务，那其他的服务要怎么办？如果我使用其他语言没有类似 java 的库要怎么办？怎样才能让所有团队使用/维护/升级库版本？我们公司有上百个服务，我要修改所有应用都使用上面的库吗？

发现了吗？自微服务诞生以来，这些一直都是个问题（语言限制、应用代码改造）。

目前有多种代理为 Service Mesh 提供解决方案，如：Envoy、Linkerd 和 Nginx。本文只关注 Envoy 的 Service Mesh。

Envoy 是针对微服务产生的这些问题设计出来的服务代理。

Envoy 能够作为 SideCar 运行在每个应用的旁边，形成抽象的应用网络。当基础设施中的所有服务流量通过 Envoy 网格流动时，通过一致的可观察性来问题区域变得容易。

如下图所示，当把 Envoy 作为 SideCar 添加到服务后，所有微服务的入站和出站流量都通过各自的 Envoy 代理

Envoy 拥有许多方便的功能

等……

所以通过从服务中抽象出整个网络，使用 Envoy 作为 SideCar 形成网格组成数据平面，允许我们控制上面列出的能力。

欢迎反馈，谢谢！