ServiceMesh与Istio（一）

近两年微服务架构流行，主流互联网厂商内部都已经微服务化，初创企业虽然技术积淀不行，但也通过各种开源 工具 拥抱微服务。再加上容器技术赋能，Kubernetes又添了一把火，微服务架构已然成为当前软件架构设计的首选。但微服务化易弄，服务治理难搞！

微服务的“痛点”

微服务化没有统一标准，多数是进行业务领域垂直切分，业务按一定的粒度划分职责，并形成清晰、职责单一的服务接口，这样每一块规划为一个微服务。微服务之间的通信方案相对成熟，开源领域选择较多的有RPC或RESTful API方案，比如：gRPC、Apache Thrift等。这些方案多偏重于数据如何打包、传输与解包，对服务治理的内容涉及甚少。

微服务治理是头疼的事，也是微服务架构中的痛点。治理这个词有多元含义，很难下达一个精确定义，这里可以像小学二年级学生那样列出治理的诸多近义词：管理、控制、规则、掌控、监督、支配、规定、统治等。对于微服务而言，治理体现在以下诸多方面：

• 服务注册与发现

• 身份验证与授权

• 服务的伸缩控制

• 反向代理与负载均衡

• 路由控制

• 流量切换

• 日志管理

• 性能度量、监控与调优

• 分布式跟踪

• 过载保护

• 服务降级

• 服务部署与版本升级策略支持

• 错误处理

• ……

从微服务治理角度来说，微服务其实是一个“大系统”，要想将这个大系统全部落地，绝非易事，尤其是之前尚没有一种特别优雅的技术方案。多数方案（比如：Dubbo、go-kit等）都或多或少地对应用逻辑有一定的侵入性，让业务开发人员不能只focus到业务本身，还要关心那些“治理”逻辑。并且市面上内置了微服务治理逻辑的框架较少，且很多编程语言相关。这种情况下，大厂多选择自研或基于某个框架改造，小厂一般只能“东拼西凑”一些“半成品”凑合着使用，就这样微服务也走过了若干年。

Service Mesh横空出世，Istio带来“福音”

我不知道在没有TCP/IP协议的年代，主机和主机之间的应用通信时是否需要应用关心底层通信协议实现逻辑。但是和TCP/IP诞生的思想类似，在微服务使用多年后，人们发现需要独立地抽象出一层逻辑网络，专门用于“微服务通信与治理策略的落地”，让应用只关心业务，把服务治理的事情全部交由“这一层”去处理。

图 1：传统微服务之间的微服务治理逻辑的位置

图 2：微服务治理逻辑被独立出来之后的位置

由“Service Govern Logic”这一层组成的逻辑网络被定义为Service Mesh，每个微服务都包含一个service mesh的端点。

“Service Mesh”概念还非常年轻，这个词在国内被翻译为“服务网格”或“服务啮合层”，我们这里就用Service Mesh这个英文词。这里摘录一下ServiceMesh中文社区上的一篇名为《年度盘点2017之Service Mesh：群雄逐鹿烽烟起[1]》的文章中对Service Mesh概念的回顾：在 2016 年年初，“Service Mesh”还只是 Buoyant 公司的内部词汇，而之后，它开始逐步走向社区：2016 年 9 月 29 日在 SF Microservices 上，“Service Mesh”这个词汇第一次在公开场合被使用。这标志着“Service Mesh”这个词，从 Buoyant 公司走向社区。2016 年 10 月，Alex Leong 开始在 Buoyant 公司的官方 Blog 中连载系列文章“A Service Mesh for Kubernetes”。随着“The Services must Mesh”口号的喊出，Buoyant 和 Linkerd 开始 Service Mesh 概念的布道。2017 年 4 月 25 日，William Morgan 发布博文“What’s a Service Mesh? And why do I need one?”。正式给 Service Mesh 做了一个权威定义。而Service Mesh真正引起大家关注要源于Istio项目的开源发布。为什么呢？个人觉得还是因为“爹好”！Istio项目由Google、IBM共同合作创建，Lyft公司贡献了Envoy项目将作为Istio Service Mesh的data panel。Google、IBM的影响力让Service Mesh概念迅速传播，同时也让大家认识到了Istio项目在Service Mesh领域的重要性，于是纷纷选择积极支持并将自己的产品或项目与Istio项目集成。

Istio项目是Service Mesh概念的最新实现，旨在所有主流集群管理平台上提供Service Mesh层，初期以实现Kubernetes上的服务治理层为目标。它由控制平面和数据平面组成（是不是感觉和SDN的设计理念相似啊）。控制平面由 Go 语言实现，包括Pilot、Mixer、Auth三个组件；数据平面功能暂由Envoy在Pod中以Sidecar的部署形式提供。下面是官方的架构图：

图 3：Istio架构图（来自官网）

Sidecar中Envoy代理了Pod中真正业务Container的所有进出流量，并对这些流量按照控制平面设定的“治理逻辑”进行处理。而这一切对Pod中的业务应用是透明的，开发人员可以专心于业务逻辑，而无需再关心微服务治理的逻辑。Istio代表的Service Mesh的设计理念被认为是下一代“微服务统一框架”，甚至有人认为是微服务框架演化的终点。

Istio于2017年5月24日发布了0.1 release版本，截至目前为止Istio的版本更新到v 0.4.0，演进速度相当快，不过目前依然不要用于生产环境，至少要等到1.0版本发布吧。但对于Istio的早期接纳者而言，现在正是深入研究Istio的好时机。

Istio 是如何运行的？

一般来说，Istio Service Mesh 由两部分组成。

1、由 Envoy 代理组成的数据面板，它能够拦截网络请求，并控制服务之间的通信。

2、 支持服务的运行时管理的控制面板，它提供策略实施、遥测数据收集以及证书轮换等功能。

代理

Envoy 是由 Lyft 公司基于 C++ 编写的一个高性能、开源的分布式代理（在 Lyft 公司内部用于处理生产环境中的网络请求）。Envoy 作为 sidecar 部署在系统中，对所有流入与流出的网络请求进行拦截，实现各种网络策略，并与 Istio 控制面板集成。Istio 利用了 Envoy 内建的大量特性，例如服务发现与负载均衡、流量拆分、故障注入（fault injection）、熔断器以及分阶段发布等功能。

Pilot

作为控制面板的重要组成部分之一，Pilot 负责管理代理的配置，并将服务的通信策略分发至 Istio mesh 中所有的 Envoy 实例。它能够接受高级别的规则（例如发布策略），将其解释为低级别的 Envoy 配置，并将配置分发至 sidecar，而且不会导致停机或是重新部署。虽然 Pilot 本身不依赖于底层平台，但运维人员可以利用特定于平台的适配器，将服务发现的信息推送给 Pilot。

Mixer

Mixer 能够在 Istio 中集成各种生态的基础设施后端系统，它通过即插即用的适配器集，通过标准的配置模型，使 Istio 能够方便地与现有的服务进行集成。适配器对 Mixer 的功能进行了扩展，并将特定的接口暴露给监控、日志、追踪、配额管理及其他功能。适配器是按需加载的，并按照运维人员的配置在运行时发挥作用。

Citadel/Auth

Citadel 即之前的 Istio Auth，它为跨 mesh 的服务与服务之间的通信进行证书签名与轮换，提供双向认证与双向授权功能。Envoy 通过 Citadel 证书，在每个调用中以透明的方式注入双向的TLS，通过自动化的身份与凭证管理，对流量进行安全管理与加密。Citadel 符合 Istio 的整体设计，只需少量的服务代码（甚至完全不需要服务代码）即可配置认证与授权功能，并且能够无缝地支持多个集群与平台。

为什么要使用 Istio？

Istio 具有高度模块化的特性，适用于多种场景。对于它带来的各种益处的详细解释可能已经超出了本文的范围，但我还是会简单地做个介绍，体验一下如何通过它简化网络运维、安全运维以及 DevOps 的日常工作。

灵活性

Istio 能够保护应用不被片状网络和雪崩式故障所影响。如果你是一位网络 运维人员，就可以通过故障注入等特性在系统中注入网络延迟及网络隔离等故障，系统性地检验应用的灵活性。如果你希望将某个版本的服务迁移至另一个版本，可通过基于权重的流量路由方式，逐渐将流量导向新版本的服务，以此降低风险。更好的办法是，在进行实际的切换之前，你可以模拟出真实的流量指向新的部署服务的行为，以观察它的运行情况。此外，你还可以通过 Istio Gateway 对流入与流出的流量进行负载均衡，并对流量应用各种路由规则，例如超时、重试以及熔断等等，以减少潜在的故障，并从故障中恢复。

安全性

Istio 的一个主要使用场景是在异构的系统中对服务间的通信进行安全加密。安全运维人员能够以统一的方式进行大规模的操作，例如开启流量加密、在不破坏其他服务的前提下阻止对某个服务的访问、开启双向身份认证、通过访问控制（ACL）管理服务白名单、对服务与服务间的通信进行授权，以及分析服务的安全性状况等等。运维人员可以在单个服务、单个命名空间或整个 mesh 的范围内实施这些安全策略。这些功能的存在可以减少对于防火墙层次的依赖，减少安全运维人员的工作负担。

可观测性

微服务所带来的一大挑战是如何以可视化方式了解基础设施的运行情况。直至近期，最佳的方式仍然是对每个服务进行扩展，以实现端到端的服务交付。除非你打算投入一个团队的人力专门对二进制文件进行调整，否则仍然很难对整个平台有一个全局性的认识，对于系统瓶颈的故障诊断依然十分不便。

而通过 Istio 自带的功能，你就可以通过可视化的方式了解系统的关键指标，并且能够跨服务进行请求的追踪。如此一来，你就可以实现基于应用指标进行自动扩展等操作。虽然 Istio 支持多种扩展，例如 Prometheus、 Stackdriver、Zipkin 和 Jaeger 等等，但其本身并不受限于后端平台的选择。如果你找不到趁手的工具，完全可以自行编写适配工具，与 Istio 进行集成。

Istio的发展现状如何？

新的特性正在不断地加入 Istio 中，同时，我们也在改进现有的功能。Istio 的开发遵循标准的敏捷风格，每个特性都需要通过自身的生命周期进行交付（dev/alpha/beta/stable）。虽然有一部分功能仍在改进中，但有许多功能已经可以在生产环境中使用了（beta/stable）。欢迎在 istio.io 网站上查看最新的功能列表。

Istio 遵循严格的发布节奏，虽然我们提供每日和每周构建的版本，但并不提供相应的支持，也不确保其可靠性。另一方面，每月构建的 snapshot 版本则相对更安全，并且通常会包含新的特性。不过，如果你打算在生产环境中使用 Istio，请选择包含“LTS”（长期支持）标签的版本。在本文编写时，最新的 LTS 版本号是 0.8。你可以在 GitHub 上找到该版本以及其他各版本。

后续有什么计划？

自从在 GlueCon 大会上正式发布 Istio 0.1 版本以来，已经过了一年时间。虽然我们取得了很大的进展，但仍有许多工作需要完成。近期的目标是在关键的功能都进入 beta 阶段（某些情况下或许需要等待 stable 阶段）后发布 Istio 1.0 版本。需要指出的是，该版本并非 Istio 功能的全部，而只是我们基于社区的反馈，所选出的最重要功能。为了本次发布，我们也在尽力改进一些非功能性的需求，例如性能与扩展性，同时也在改进我们的文档以及上手体验。

Istio 的一个重要目标是支持混合型环境。举例来说，用户可以将虚拟机运行在 GCE、本地 Cloud Foundry 集群，或是其他公有云的服务上。Istio 能够为整体服务平台提供一个统一的视图，管理这些环境之间的连接并确保安全性。我们目前正在致力于实现多集群的架构，允许你在扁平网络中将多个 Kubernetes 集群加入一个单独的 mesh 中，并启用跨集群的服务发现功能，这项工作在 0.8 LTS 版本中还处于 alpha 阶段。在不远的将来，它还将支持全球化的集群级别的负载均衡，并通过 Gateway 对等互联提供对非扁平网络的支持。

除了 1.0 版本的发布之外，我们的另一个工作重心是 API 管理功能。仅举一例，我们计划推出一个 service broker API，它能够对各个服务提供服务发现与上线功能，将服务消费者与服务管理者相关联在一起。我们还将为 API 管理功能提供一个统一的接口，这些功能包括 API 业务分析、API 密钥验证、认证检验（例如JWT、OAuth等等）、编码转换（JSON/REST 至 gRPC 转换）、路由，以及与多种 API 管理系统的集成，例如 Google Endpoints 与 Apigee。

所有这些短期目标都是为了最终实现我们的长期目标，即将 Istio 融入至不同的环境中。按照我们的技术主管，同时也 Istio 的创始者 Sven Mawson 所说：“我们所希望实现的理想，是让 Istio 能够融入每个环境中，无论你使用的是哪一种环境或平台，都能够为你提供服务管理的功能“。

虽然 Istio 仍然处于早期阶段，但它的开发速度与接受度正在稳步地提升。无论对于主流云厂商还是个人贡献者来说，Istio 都已经成为了 Service Mesh 的代名词，同时也是基础设计发展路线图中的一个重要组成部分。每一次的发布，都意味着我们向目标更近了一步。

参考连接：

http://www.cnblogs.com/williamjie/p/9442340.html

https://baijiahao.baidu.com/s?id=1604614219077165559&wfr=spider&for=pc