Service Mesh入门实战

admin管理员组

文章数量:1530085

课程介绍

过去一年时间，Service Mesh 悄然兴起，成为云堆栈的一个重要组件。如 Google，IBM、Lyft 这些公司都在各自的产品应用中添加了Service Mesh。但是究竟为什么 Service Mesh 会受到如此大的关注呢？

本系列课程将带领读者学习什么是 Service Mesh， Service Mesh 能做什么，为什么 Service Mesh 是构建云原生应用的主要构件，并以实例为基础详细介绍 Service Mesh 的主要实现 linkerd。

其中包括：

• 深入了解 linkerd 的主要功能；
• 如何安装部署 linkerd；
• 深入理解 linkerd 配置，dtab 路由规则；
• linkerd 工作机制、数据访问流、部署模型等。

认真学习完这个课程之后，你将获得或者具备以下能力：从0到1理解 linkerd 的工作机制；具备通过 linkerd 构建弹性的、高可见性的、可追踪的云原生应用。

作者简介

杨章显，多年企业级在线会议系统的运维以及软件发布、变更管理经验，熟悉容器技术、容器编排、自动化运维、部署、监控等，目前为思科内部容器 PaaS 主要负责人，负责技术选型、实现、落地等工作。

课程内容

第01课 为什么我们需要 Service Mesh

云原生时代微服务的挑战

随着近年来云计算技术的快速发展，软件开发也从传统的单体应用到 SOA 以及时下流行的微服务，均随着技术的演变发生巨大的变化，无论是对开发人员还是运维人员的技术理念和思维都要求极大的转变。尤其是在云原生时代，微服务已经成为业界开发应用的主要方式，而一些云计算技术的出现如 Docker ，使得开发和发布微服务更加容易。但是微服务架构并不是万能银弹，虽然一方面可收之桑榆，但另外也可能失之东隅。其中最具挑战性的是如何确保分布在复杂网络环境中微服务处理网络弹性逻辑及可靠地交付应用请求，正如 L. Peter Deutsch 在分布式系统的谬误中论述，我们不能一厢情愿地认为：

• 网络是可靠的
• 网络零延迟
• 网络带宽是无限的
• 网络是安全的
• 网络拓扑一成不变
• 系统只有一个管理员
• 传输代价为零
• 网络是同质的

因此应用应当具有规避网络不可靠、丢包、延时等的能力。那么从开发人员和运维人员来说，怎么才能确保分布在复杂网络环境中的微服务具有处理网络弹性逻辑能力及可靠地交付请求呢？ 一些常用技术手段如：

• 负载均衡
• 服务发现
• 运行时动态路由
• 熔断机制
• 安全通讯
• 指标和分布式追踪

当然，在微服务架构中，多语言、多协议支持以及透明监控等问题也需要得到足够的重视。

下面我们看处理这些挑战和问题时技术方案是如何演进的。

解决方案——初级

在这种方案中，通常我们把上述的一些技术手段如负载均衡、服务发现或分布式追踪等跟业务逻辑代码一起封装起来，使得应用具有处理网络弹性逻辑的能力。该模式如下：

这种模式非常简单，但是从软件设计的角度，大家能很快发现它有很多缺点：

• 耦合性很高，每个应用都需封装负载均衡、服务发现、安全通讯以及分布式追踪等功能。
• 灵活性差，利用率低下，不同的应用需要重复的实现。
• 管理复杂，当其中一项如负载均衡逻辑发生变化，需要更新所有服务。
• 可运维性低，所有组件均封装在业务逻辑代码，不能作为一个独立运维对象。
• 对开发人员能力要求很高。

解决方案——中级

关于第一种方案，虽然应用具有处理网络弹性逻辑能力，增强动态运行环境中如何处理服务发现、负载均衡等，向提供高可用、高稳定性、高 SLA 应用更进一步，与此同时，你也看到这种模式具有很多缺点。为此，我们是否可以考虑将由应用处理服务发现、负载均衡、分布式追踪、安全通讯等设计为一个公用库呢？这样使得应用与这些功能具有更低的耦合性，而且更加灵活、提高利用率及运维性，更主要的是开发人员只需要关注公用库有，而不是自己实现，从而降低开发人员的负担。这方面很多公司如 Twitter、Facebook 等走在业界前列，像 Twitter 提供给 JVM 的可扩展 RPC 库 Finagle 和 Facebook 的 C++ HTTP 框架 Proxygen，Netflix 的各种开发套件，还有如分布式追踪系统 Zipkin，这些库和开发套件的出现大量减少重复实现的工作。对于这种模式：

虽然相对前一种解决方案，新的方案在耦合性、灵活性、利用率等方面有很大的提升，但是仍然有些不足之处：

• 如果将类似 Finagle，Proxygen 或者 Zipkin的 库集成现有的系统中，仍然需要花费的大量的时间、人力和物力将其集成到现有生态圈，甚至需要调整现有应用的代码。
• 缺乏多语言支持，由于这些库只针对某种语言或者少数几种语言，这使得在一个多技术栈的公司需要限制开发语言和工具的选择。
• 虽然公共库作为一个独立的整体，但在管理复杂性和运维性这些方面仍然有更大的提升空间。
• 公共库并不能完全使得开发人员只关注业务代码逻辑，仍然需要对公共库很深的认识。

解决方案——高级

显然，没有任何方案能一劳永逸的解决我们所有的问题，而各种问题驱使我们不断地向前演进、发展，探索新的解决方法。那么，针对我们现在所面临的问题，我们有更好的解决方案吗？答案当然有。

相信大家对 OSI 七层模型应该不陌生，OSI 定义了开放系统的层次结构、层次之间的相互关系以及各层所包括的可能的任务，上层并不需要对底层具体功能有详细的了解，只需按照定义的准则协调工作即可，因此，我们也可参照 OSI 七层模型将公用库设计为位于网络栈和应用业务逻辑之间的独立层，即：透明网络代理，新的独立层完全从业务逻辑中抽离，作为独立的运行单元，与业务不再直接紧密关联。通过在独立层的透明网络代理上实现负载均衡、服务发现、熔断、运行时动态路由等功能，这样透明代理现在在业界有一个更加新颖时髦的名字：Service Mesh。率先使用这个 Buzzword 的产品恐怕非 Buoyant 的 linkerd 莫属了，随后 Lyft 也发布了他们的 Service Mesh 实现 Envoy，再有 Istio 也迎面赶上。新的模式如：

在这种方案中，由于 Service Mesh 作为独立运行层，它很好的解决了上述所面临的挑战，使应用具备处理网络弹性逻辑和提供可靠交互请求的能力。它使得耦合性更低、灵活性更强，与现有环境的集成时间和人力代价更小，也提供多语言支持、多协议支持，运维和管理成本更低。最主要的是开发人员只需关注业务代码逻辑，而不是业务代码以外的其他功能，即 Service Mesh 对开发人员是透明的。下面我们将讲述什么是 Service Mesh。

Service Mesh 是什么

关于 Service Mesh，Buoyant 创始人 William Morgan 如是说：

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network

本文标签： 实战入门ServiceMesh