为什么要使用服务网格Service Mesh？

为了理解服务网格的必要性，我们将从多个阶段来查看Internet应用程序的简要历史。

阶段0：巨石单体

记得那些时候？整个代码库打包为一个可执行文件并已部署。根据用例，这仍然可以更好地工作。

但问题是一些快速增长的公司在扩展性，部署，所有权等方面遇到了困难。

第1阶段：微服务

想法很简单，用SLA将monolith分解成多个部分。这种方法运作良好，并被许多公司广泛采用。

现在，每个团队都可以大胆地用他们喜欢的语言、框架等来构建他们的微服务。

虽然它解决了第0阶段的一些问题，但现在还是存在一些严重的问题

• 为每个微服务配置VM的规范。
• 使用Chef，OS版本等自动化 工具 维护系统级依赖性。
• 监控每项服务。

对于实现生产环境的构建和部署的人来说，这是一场噩梦。并且假设它们共享相同的操作系统但需要隔离，或者出于可移植性原因将它们打包到单独的VM镜像中。为每个服务实现新VM非常昂贵！

阶段2：容器化

通过利用 Linux 中的 cgroups 和 命名空间 ，新的操作系统级虚拟化技术通过共享相同的主机操作系统来实现应用程序的隔离环境。Docker是最受欢迎的容器运行时。

因此，为每个微服务创建并发布了一个镜像。现在，应用程序被隔离，快速，便宜地启动新容器，所有这些都可以通过一个操作系统实现！

容器化解决了构建和部署问题。我们还没有完善的监控解决方案！

我们还有其他问题吗？

管理容器！

使用容器运行可靠的基础架构需要注意一些关键事项。

• 容器的可用性
• 供应容器
• 向上/向下缩放
• 负载均衡
• 服务发现
• 跨多台计算机调度容器

阶段3：容器编排

Kubernetes是最受欢迎的集装箱协调器，它彻底改变了我们对基础设施的看法。

Kubernetes负责健康检查，可用性，负载平衡，服务发现，可扩展性，跨VM的调度容器等。太棒了！

那真是吗？

不是，请记住，我们尚未解决微服务阶段的监控/可观察性问题。那只是冰山一角。微服务是分布式的管理微服务，但是不是那么简单。

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

• 指标（延迟，成功率等）
• 分布式跟踪
• 客户端负载平衡
• 断路
• 交通换乘
• 限速
• 访问记录

像Netflix这样的公司提出了几种工具，并经过了微服务运行的实践考验。

• Netflix Spectator（适用于指标）
• Netflix Ribbon （客户端LB /服务发现）
• Netflix Hystrix（断路器）
• Netflix Zuul（边缘路由器）

满足这些最佳实践的方法是在每个微服务上使用客户端库来解决每个问题。

微服务增加了多个库！

但服务A是用 Java 编写的，其他服务呢？

如果我找不到其他语言的等效库怎么办？

如何让所有团队使用/维护/升级库版本？

我的公司有几百个服务我应该修改它们以便使用上面的库吗？

你现在看到问题了吗？

自微服务出现以来，这一直是一个问题。

阶段4：服务网格

Envoy ，Linkerd和Nginx 等多个代理为Mesh提供解决方案。但是这篇文章只关注Envoy Mesh。Envoy是服务代理，设计为管理微服务产生的所有运营问题。

Envoy可以作为 边车 与每个应用程序一起运行并抽象网络。当基础设施中的所有服务流量通过Envoy网格流动时，通过统一的可观察界面可以很容易地显示问题区域。

Envoy拥有许多方便的功能

• 支持HTTP 2，包括gRPC
• 健康检查
• 负载均衡
• 度量
• 追踪
• 访问日志记录
• 断路
• 重试政策
• 超时配置
• 限速
• Statsd / Prometheus支持
• 交通流量
• 使用xDS Server进行动态配置

还有很多！

因此，通过从服务中抽象整个网络并与Envoy形成网格，因为它的数据面板允许我们控制上面列出的能力。