容器云技术：容器化微服务，Istio占C位出道

在精彩的软件容器世界中，当新项目涌现并解决你认为早已解决的问题时，这感受就像地面在你的脚下不断地移动。在许多状况下，这些问题好久之前被解决，但如今的云原生架构正在推进着更大规模的应用程序部署，这就须要新的工具和方法。

微服务就是一个很好地例子。在此模型下，典型的应用程序或服务将被分解成能够独立部署的功能模块，这些功能模块能彼此分开扩展和维护，而且连接在一块儿时能够提供应用或服务的所有功能。

当使用容器来开发微服务时，后一块多是棘手的。当它们可能散布在服务器节点集群中时，而且在它们的实例不断弹出时，随后被更新版本替换而下线时，该如何将全部组件部分连接起来？在面向服务的架构中（SOA），微服务能够被视为进化的继承者，这种任务相似于企业服务总线（EBS）所处理的任务，因此须要的是一种基于云原生版本的EBS。

这是一个相对新的开源项目Istio旨在填补的工做。它被正式的描述为服务网格，由于它的其中一部分分布在由容器管理的基础架构中，而且它开始着手于知足服务发现，负载均衡，消息路由，遥测和监控，以及必不可少的安全等需求。

Istio源自于谷歌和IBM之间的合做，实际上包含了一些现有的组件，特别是由乘车服务公司Lyft开发的组件。它以某一种形式存在了至少一年，最终在七月底达到1.0版本的里程碑，这意味着它终于被认为足够成熟，能够做为生产的一部分基础架构运做。

IBM研究员兼IBM云计算首席技术官Jason McGee告诉The Next Platform，云原生态系统已基本肯定容器做为打包和运行的核心结构，而Kubernetes则做为管理容器的编排系统。但McGee解释说，还有第三块拼图尚未落地，这就是Istio的设计点。

“你如何管理在容器平台上运行的应用程序或服务之间的交互？”McGee问道。 “若是你正在构建微服务，或者你有一组应用程序，那么应用程序之间的通讯会产生一大堆有趣的问题。你如何了解谁与谁之间进行对话，如何收集有关应用程序之间通讯的数据，如何保护控制哪些服务能够相互通讯的通讯，以及如何使应用程序安全，尤为是咱们今天拥有更多种的动态或分布式架构应用程序，你在公有云的何处能安放高质量的组件？”

McGee说他在IBM的团队几年前已经开始研究这个问题了，当时他遇到了谷歌的同行并发现他们正走在同一条道路上，但IBM主要关注流量路由，版本控制和A/B测试方面，谷歌则专一于安全和遥测。两家公司决定合并各自的努力，结果就是Istio的产生。

Istio由如下组件组成：

Envoy，被描述为边车代理，它做为代理部署在每一个微服务实例旁边;

Mixer，它是一个核心组件，用于经过Envoy代理实施策略，并从中收集遥测指标;

Pilot，负责配置代理;

Citadel，是负责颁发证书的集中组件，它也有本身在每一个节点的代理。

Envoy是由Lyft开发的组件，被McGee描述为“一种很是轻量的L4到L7的智能路由器”，它捕获来自与其配对的微服务的全部传入和传出通讯，做为一种流量的控制方式，执行策略和收集遥测。Pilot是IBM提供的主要组件，可做为部署在基础架构中的全部Envoy代理的控制平面。

“若是你想象在一个服务网格中，你可能有一百个微服务，若是每一个都有多个实例，你可能有数百或数千个这些智能路由器，你须要一种方法对它们进行所有编程，因此Istio引入了这个称为Pilot的东西。能够把它想象成程序员，全部这些路由器的控制平面。因此你有一个地方能够经过它来编程这个服务网络，而后围绕数据收集进行遥测，围绕安全进行证书管理，但从根本上说你能够利用这个智能路由层和这个控制平面来管理它。”McGee解释道。

Istio还有本身的API，容许用户将其插入现有的后端系统，例如用于日志记录和遥测。

根据谷歌的说法，Istio的监控功能使用户可以测量服务之间的实际流量，例如每秒请求数，错误率和延迟，还能够生成依赖关系图，以便用户能够看到服务之间如何相互影响。

Istio
经过其Envoy边车代理，Istio还能够在每一个服务请求上使用双向TLS身份验证（mTLS），添加传输加密并使用户可以受权跨基础架构的每一个请求。

Istio消除了开发人员担忧实例之间的可否安全通讯，解决了控制哪一个实例能够与哪些实例进行通讯，以及提供执行诸如金丝雀部署之类功能等需求。若是是发布新版本的特定微服务的代码，最初只更新实例的一部分，直到你对新代码运行可靠性感到满意，再更新其余部分。

应该注意的是，其余服务网格平台已经存在，例如开源端的Linkerd或Conduit，而微软有一项服务，被称之为Azure Service Fabric Mesh，目前做为其云平台上的技术预览。此外，服务网格表明了网络管道上方的抽象层，所以前提是已经为每一个容器实例配置了网络接口，IP地址和其余网络属性。这一般意味着，不管什么时候建立新的容器实例，部署微服务还将须要一个单独的工具来自动配置网络。

然而，IBM但愿Istio将成为云原生工具包的标准组成部分，正如Kubernetes那样，Kubernetes基于谷歌为本身的内部集群开发的Borg和Omega技术和其上面的容器层技术。

“从社区的角度来看，个人指望是Istio成为架构的默认部分，就像容器和Kubernetes已经成为云原生架构的默认部分同样。”McGee说。为此，IBM但愿将Istio与其公有云所提供的Kubernetes托管服务以及其内部部署的IBM Cloud Private堆栈集成在一块儿。

“因此，你如今能够运行Istio，咱们支持如今平台上运行Istio，但指望是在不久的未来，咱们将Istio内嵌，因此每当使用咱们的平台时，Istio组件就在那里，你能够利用它，而且没必要负责部署和管理Istio自己，只需可以在应用程序中使用它。”McGee说。

谷歌已经添加对了Istio的支持，尽管只是将其标记为alpha版本，做为托管服务的一部分，该服务在其云平台上客户的Google Kubernetes Engine（GKE）集群中自动安装和维护。

Istio也得到了业内其余公司的支持，尤为是Red Hat，几年前它从新设计了OpenShift应用程序平台，以Docker容器和Kubernetes为基础。

Red Hat的Istio产品经理Brian Redbeard Harrington表示Red Hat打算将服务网格集成到OpenShift中，但Red Hat但愿在正式使用前能看到一些粗糙点的改进，好比支持多租户技术。

“Istio如今的目标是他们所谓的软多租户技术，也就是说，咱们但愿在组织内部可使用它，以便该组织内的两个不一样的团队可使用并信任它，只要没有一个组的行为过于恶意，他们就不会影响到彼此的服务。经过咱们运行OpenShift Online的方式，咱们让客户运行咱们从未看过的代码，而且必须最后安排这两个客户并存，这是一个很是独特的多租户挑战。”Harrington解释道。

“咱们须要对这个多租户有更高的信心; 咱们须要对性能和稳定性有更高的信心。 咱们尚未看到任何搅局者，但咱们已经看到了可提供不少价值的领域，包括在进行规模测试和一些自动化回归测试方面，咱们还在社区层面贡献了一个名为Kiali的项目，可视化的给出了Istio的内部运做，这只是咱们所提供的产品的一部分。”他补充道。

换句话说，Istio是另外一种开源工具，能够为那些但愿构建云原生应用程序基础架构的用户添加选项菜单。像Red Hat这样的供应商将把它融入他们通过测试和支持的企业平台产品中好比OpenShift，而其余供应商则但愿本身混合搭配并构建它。

原文地址：

https://www.nextplatform.com/2018/08/15/istio-aims-to-be-the-mesh-plumbing-for-containerized-microservices/---------------------