Istio旨在成为容器化微服务的网格管道

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

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

当使用容器来开发微服务时，后一块可能是棘手的。当它们可能散布在服务器节点集群中时，并且在它们的实例不断弹出时，随后被更新版本替换而下线时，该如何将所有组件部分链接起来？在面向服务的架构中（ 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 的监控功能使用户能够测量服务之间的实际流量，例如每秒请求数，错误率和延迟，还可以生成依赖关系图，以便用户可以看到服务之间如何相互影响。

通过其 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 ，而其他供应商则希望自己混合搭配并构建它。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31543630/viewspace-2213972/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31543630/viewspace-2213972/