Istio 教程|部署 Service Mesh 简化微服务通信(上)
技术
作者:Jakub Pavlik
译者:小君君
2018-09-05 11:03

如果你对“Service Mesh”不熟悉请不要担心,因为这是一个比较新的概念。虽然它的应用并不是很广泛,但它非常好用。本文将帮助你全面了解 Service Mesh 的基础知识,让你在基础架构实践中受益。 

Service Mesh 的两个主要目标,一是允许查看先前不可见的服务通信层;二是对微服务通信逻辑的完全控制,如动态服务发现、负载均衡、超时、回退、重试、熔断、分布式跟踪和服务之间的安全策略执行。这两个目标是由流量审计和跟踪功能来完成。 

Kubernetes 已拥有了一个非常基本的 “Service Mesh” 开箱即用功能。它通过定位所需的 Pod 以及请求的负载均衡来提供服务发现。“服务”通过管理集群中每个主机上的 iptables 来工作,只能使用轮询调度算法,不能进行重试或回退逻辑,其他功能就很难实现了。

如果你能在集群中部署一个功能齐全的 Service Mesh 系统(Linkerd,Istio或Conduit),就会获得: 

  • 允许服务使用纯 HTTP,而不必在应用层考虑 HTTPS:Service Mesh 代理将管理发送方的 HTTPS 封装并在接收端实现 TLS 终止,允许应用组件使用普通的 HTTP 或 gRPC,其他协议在传输过程中无需加密(加密由代理处理)。
  • 安全策略实施:代理可以确定哪些服务可以被允许访问其他服务和端点,并阻止未经授权的流量通过。
  • 熔断:在访问具有高延迟的过载服务或端点时选择自动回退,以免遇到越来越多的请求,若处理不当可能导致该端点在过度负载下完全失败。
  • 延迟感知负载均衡:不使用负载均衡(它会忽略每个目标的延迟),而是根据每个后端目标的响应时间使用更智能的均衡。这是现在的 Service Mesh 非常重要的特征。
  • Queue depth 负载均衡:根据当前请求处理量,优先对有空闲的目标路由发送新的请求。因为,Service Mesh 会确切地知道先前的请求在在哪里发送,以及它们中的哪些仍在被处理中或已经完成,所以它会把那些基于该逻辑的请求传送到最少队列中进行处理。
  • 每个请求路由:将由指定 HTTP 标记的特定请求,路由到负载均衡器后面的特定目标上,这样就可以轻松部署测试其他创造性用例。这是 Service Mesh 提供的最强功能之一。
  • 健康检查,重试预算和驱逐不良目标。
  • 度量标准和跟踪:报告每个目标的请求数量、延迟指标、成功和错误率。
     

部署网格的两种主要模式 

Kubernetes 术语中的 DaemonSet 是主机共享代理。如果同一主机上存在许多容器,而且可以利用连接池来提高吞吐量,那么此类部署将使用较少的资源。但是,一个代理的失败会导致该主机上的所有容器终止,而不是仅仅破坏单个服务(如果它被用作 sidecar 代理)。


作为 Sidecar 容器,代理被注入到每个 Pod 中意味着与主服务一起运行。像 Linkerd 这种更“重量级”的代理,部署会为每个 Pod 增加约 200MB 的内存。但如果使用较新的 Conduit,每个 Pod 只需 10MB 左右。Conduit 还没有拥有 Linkerd 的所有功能,所以我们还没有看到两者的对比结果。通常“把一个 Pod 放入一个 Sidecar 容器”是不错的选择,这可以把可能的代理故障限制在单个 Pod 上,而不会影响同一主机上的其他 Pod。


为什么要创建 Service Mesh? 

我们通过不同类型的应用程序架构图表来说明一下,创建 Service Mesh 的原因。

第一个示例是一个老式的三层 Web 服务,它是利用 monolith all-in-one 应用程序编写的。它每天可能服务数百万个请求,但没有复杂的功能,底层服务的通信非常简单明了:Nginx 将所有流量转发到 Apache 实例中,后者从 database\file 存储中获取数据并返回到所需页面。


这个示例体系结构不会从 Service Mesh 中获益太多,因为这个 monolith 没有开发人员编写代码,也不涉及微服务,只是利用它来负责应用程序组件之间的路由和通信。在整体应用程序中,所有核心组件都位于同一台计算机上,不通过网络进行通信,没有 REST API 或 gRPC。而所有“业务逻辑”只在一个应用程序中运行,将所有 Apache Web 服务器作整体部署。 


第二个例子是一个基于微服务的应用程序,这个应用程序有很多进程和后台逻辑。它做了很多事情,比如学习访问者模式和检测用户在网站上的个性偏好模式,通知用户他们最喜欢的主题更新等。你可以想象在所有这些微服务之间发生的许多复杂过程,分布在数千个容器和数百个节点上。请注意,我们的插图非常简化。实际上,如果我们要显示一个大型云原生应用程序的真实体系结构,可能整个屏幕都放不下。 


在这个例子中,我们在每个微服务中都有一段与通信相关的代码。它设置重试策略、超时、处理异常(在网络故障的情况下)等。我们还看到一个多语言环境,有些团队利用 Scala 创建组件,有些使用 Golang,Node.js 或 Python。所有组件都可以通过网络上的 REST API 或 gRPC 相互通信,每个团队花费时间和精力在他们自己的组件中使用各自的语言实现通信逻辑,他们就无法共享彼此的库和功能,这样就可以节省时间并使用插入应用程序的所有组件来统一解决方案。


除了查询服务的发现机制功能(如 Consul 或 ZooKeeper)以及读取外部传递和给予应用程序一些配置外,还需要向 Prometheus / InfluxDB 报告延迟和响应相关指标。这包括有关缓存响应时间(redis 或 memcached 缓存)的信息,该缓存响应时间通常位于另一个节点上,或者作为一个单独集群,但这可能会导致过载甚至高延迟。


除了团队 backlog 过多和截止日期临近之外,所有这些都是服务代码的一部分,需要维护。开发人员不喜欢把时间花在与项目事务管理相关的代码部分上,例如添加跟踪和指标(用于在排除故障和分析时方便操作)或处理可能的网络故障,实施回退和重试预算。


在这种环境中,Service Mesh 将节省开发时间,并统一允许以中心方式控制通信。我们应如何将这种通信层机制更改为统一的“Service Mesh”呢?我们将所有这些微服务通信、路由、发现、延迟测量,请求跟踪和微服务代码的类似部分都移出服务之外,形成一个独立的代理进程,它知道如何为每个微服务处理所有这些(以及更多)的问题。幸运的是这些工具已经存在!


Twitter,Lyft 和 Netflix 等公司已开放其解决方案,其他贡献者也在开源库之上构建了自己的工具。目前有几个主要选项可用作 Service Mesh:Linkerd,Conduit, Istio 和 Envoy。Istio 是一个建立在 Envoy 之上的组件,它是一个控制平面,可以与 Envoy 和 Linkerd 一起用作其数据平面代理。控制平面允许集群操作员以集中的方式进行特定设置,然后将其分布在数据平面代理上并重新配置它们。


Linkerd 和 Conduit 都是由前 Twitter 工程师团队 Buoyant 创建。目前 Linkerd 是最常用的 Service Mesh。但是 Conduit 是从零开始专门为 Kubernetes 构建轻量级代理 sidecar,非常快速且非常适合 Kubernetes 环境。在撰写本文时,Conduit 仍处于积极发展阶段。


让我们看一下从依赖于应用程序的通信逻辑到 “Service Mesh” 模式的变化。 


最值得注意的是,所有这些代理都可以在同一地方配置和更新,通过它们的控制平面(或通过某些存储库中的配置文件,这取决于所选的工具和部署方法),我们可以应用一组特定的规则去完成成千上万个代理。因此,路由、负载均衡、度量标准收集、安全策略实施、熔断、数据传输加密,所有这些操作都将遵循一组严格的规则,由集群管理员来管理。 

Service Mesh 适合你么? 

乍一看,这种将微服务通信机制分离到独立架构层的新概念存在一个问题:它是否足够有用,值得配置和维护整一套复杂的特殊代理?


要回答这个问题,你需要估计应用程序的大小和复杂程度。如果你只有几个微服务和数据存储端点(例如,一个用于记录的 ElasticSearch 集群,一个用于度量的 Prometheus 集群,具有两个或三个主应用程序数据的数据库),那么实现 Service Mesh 可能对你的环境来说有点过头了。但是,如果你的应用程序组件分布在数百或数千个节点上,并且包括 20 多个微服务,那你的环境将从 Service Mesh 提供的功能中受益良多。


即使在较小的环境中,如果你希望将重试和熔断行为与应用程序本身分离(例如,在管理层就重新连接或回退代码,以此避免重试其他服务或数据库),你可以使用 Service Mesh 从应用程序开发人员那里消除这种网络逻辑维护负担,因此他们将更多地关注业务逻辑,而不是参与管理和调整所有微服务的相互通信。Ops 团队将一次性配置 Service Mesh,并以集中的方式不时调整,最大限度地减少在应用程序组件通信上花费的精力。


Istio 是完整功能 Service Mesh 的完美示例,它有几个“主要组件”来管理所有“数据平面”代理(这些代理可以是 Envoy 或 Linkerd,但默认情况下,是 Envoy ,我们的教程中也将对 Envoy 进行讲解,而 Linkerd 集成仍在进行中)。

以下是官方网站上 Istio 架构的快速图表: 


你可以在官方文档中阅读更多内容,以下是 Istio 组件及其功能的摘要:

控制平面:

  • Pilot:向 Envoy 代理提供路由规则和服务发现信息。
  • Mixer:从每个 Envoy 代理收集遥测信息并实施访问控制策略。
  • Istio-Auth:提供“服务到服务”和“用户到服务”的身份验证,并可以将未加密的流量转换为基于 TLS 的服务。快速提供访问审核信息(正在进行的工作)。

数据平面

  • Envoy:功能丰富的代理,由控制平面组件管理。拦截进出服务的流量,并按照控制平面中设置的规则应用所需的路由和访问策略。

2018 中国云原生用户大会 

2018 年 9 月 16 日,由才云科技( Caicloud )、「K8sMeetup 中国社区」和「Kubeflow 社区」联合主办的聚焦中国行业应用与技术落地的盛会——2018 中国云原生用户大会( 2018 CEUC )即将盛大启幕。


届时 CNCF 执行董事 Dan Kohn,VMware 中国研发中心总经理任道远、网易云基础服务总经理陈谔、Caicloud CEO 张鑫博士、Caicloud CTO 邓德源以及 Caicloud COO & CNCF 全球大使韩佳瑶博士等众多云原生领域行业大牛即将登台演讲,与国内外云原生技术专家及爱好者共同展望云原生未来,并围绕开源技术前沿话题,从市场、技术、产业及整个开源生态层面进行全方位探讨。


售票通道现已开启,可以扫描下图二维码直接购买。议题提交、赞助合作以及其他合作请直接点击“阅读原文”查看大会官网。




54 comCount 0