Istio服务网格的兴起

Diogenes Rettori是Red Hat OpenShift的首席产品经理。

在过去的一年中，围绕Istio服务网格技术引起的关注和吸引力确实令人着迷。 实际上，在撰写本文时，Istio的版本仅为0.8，但是对于连续两个KubeCon / CloudNativeCon事件，它一直是一个炙手可热的热门话题 ，仅在丹麦事件中就有十几个不同的会议。 那为什么呢？

在深入探讨Istio受欢迎的原因之前，让我们介绍一下服务网格的主题。 通用术语，服务网格已在许多不同的上下文中互换使用，例如定义了不同无线设备之间的通信方法，或代表了各个应用程序可以直接与其他应用程序通信的系统。 最近 ，该术语已用于表示应用程序或微服务的网络，以及它们之间的关系和交互。 后者是本文的重点。

[您准备好入侵容器了吗？ 了解如何使用Kubernetes入门 。 •到底什么是Kubernetes ？ | 通过InfoWorld的云计算新闻通讯了解云计算的最新发展。 ]

Red Hat涉足云原生和微服务领域，尤其是四年前Red Hat OpenShift接管Kubernetes和Docker的方向，这一事实帮助我们了解了服务网格技术（尤其是Istio）的重要性。 本文将探讨我认为Istio受欢迎的四个不同原因。

微服务与转型

在您的整个职业生涯中，甚至可能是在您目前的职位上，您可能都遇到过这样的情况，即从编写代码到将代码部署到生产中之间的时间很长，以至于开发人员继续进行其他项目，而您的反馈循环就变成了无关紧要的。 为了帮助缩短交付周期，一些公司决定通过将大型应用程序分解为较小的部分（例如功能或微服务）来提高效率。 曾经具有多个功能的单个应用程序（读取：程序包）曾经被划分为可以独立更新的单独程序包。

这肯定有其价值，但是必须承认，这种情况也需要对这些单独的服务及其之间的接口进行更多的管理。 例如，曾经被定义为应用程序内部API调用的一部分的关系现在必须跨网络移动。

克里斯蒂安·波斯塔（Christian Posta）的演讲“ 微服务的最难部分：调用服务 ”解决了一个重要问题。 调用API时，可能会导致您相信自己正在处理A到B直接集成（下面的图1）。 但是，计算机网络并没有针对直接通信进行优化（图2），因此不可避免地，您将不得不处理无法控制的许多不同物理和虚拟网络设备，尤其是在考虑或使用云环境时。 例如，可能其中一种设备的性能低于最佳性能，从而影响了整个应用程序的响应时间（图3）。

红帽

微服务先锋和Netflix OSS

一些看似为云而生的公司早就发现了这一点，即为了在云中提供弹性服务，应用程序必须保护自己免受环境异常的影响。

Netflix创建并随后开源了一套技术（主要是Java），以实现诸如断路，边缘路由，服务发现和负载平衡等功能。 这些功能使应用程序可以更好地控制其通信，从而提高了整体可用性。 为了测试并确保该方法的弹性，Netflix还依赖于混乱的工程 ，这涉及将各种现实问题注入到应用程序网络中，从而在任何给定的时间点中断工作流程。 Netflix开发的技术组合允许其应用程序参与以应用程序为中心的网络，这实际上是一个服务网格。

创建Netflix OSS堆栈时，虚拟机实际上是在云中运行应用程序的唯一方法。 因此，Netflix选择Java作为服务网格功能的语言平台。

除了Netflix OSS堆栈的仅Java方面之外，提出的另一个挑战是，为了实现服务网格功能，开发人员必须在其应用程序中包括Java库，并在代码中添加条款以使用此类功能。组件。 当时，想要强制使用这些技术的公司无法在平台级别做到这一点。

随着Kubernetes的到来，服务发现和负载平衡等功能已成为平台的一部分，从而允许以任何语言编写的任何应用程序都可以利用它们。 通过声明式和活动状态管理，Kubernetes还能够通过自动重启无响应的应用程序来提高整体应用程序可用性。 在当今世界，Kubernetes和容器是运行微服务应用程序的事实上的标准。

在Kubernetes中，您的应用程序在“ pod”中运行，“ pod”由一个或多个容器组成。 在吊舱中运行多个容器的一种技术称为“侧车”，这实际上是另一种与主应用程序在同一隔离空间（吊舱）中运行的软件。

Kubernetes为Istio等技术的兴起创造了有利条件。 乘车共享公司Lyft已经在开发名为Envoy的智能代理，以提供其在微服务部署中所需的弹性和动态路由功能。 Side-car容器和Envoy允许公司将轻量级代理附加到应用程序的每个实例，以支持服务发现，负载平衡，断路器，跟踪和服务网格的其他功能。 将其与将治理添加到Envoy实例的配置和管理的控制平面相结合，然后您将拥有Istio。

拥抱分布式架构

最后，Istio和服务网格通常是“包容” 分布式计算的谬论 。 换句话说，Istio 允许应用程序假设网络可靠，快速，安全，不变等—分布式计算的谬论根本不是谬论。 可以说Istio和Kubernetes解决了所有这些难题，但是忽略这些谬论可能是企业可能犯的最大错误之一。 公司必须接受这样的事实，即当您具有相互交互的多个微服务和功能时，您正在处理分布式系统。

请参阅下面的分布式计算谬误的完整列表以及Istio对它们的回应：

在与OpenShift客户的对话中，我经常发现他们已经实现了Netflix自己开发的相同模式，因为他们了解对这些功能的需求。 我也很高兴找到专注于这些功能的完整团队。 我经常听到“我们是断路器团队”或“我们是服务发现团队”。

投资创建自己的服务网格功能的公司现在有机会使用Kubernetes和Istio。 通过对这些开源技术进行标准化，他们可以访问更大社区创建的功能，知识和用例，从而有助于以更大的成本促进他们向更具弹性的应用程序和更快的上市时间的过程。

Diogenes Rettori是 Red Hat OpenShift 的首席产品经理 。 在加入OpenShift团队之前，他专注于Red Hat JBoss中间件的客户培训。 Diogenes具有很强的工程背景，曾在爱立信和IBM等公司任职。

-

新技术论坛提供了一个以前所未有的深度和广度探索和讨论新兴企业技术的场所。 选择是主观的，是基于我们对InfoWorld读者认为最重要和最感兴趣的技术的选择。 InfoWorld不接受发布的营销担保，并保留编辑所有贡献内容的权利。 将所有查询发送到 [email protected] 。

From: https://www.infoworld.com/article/3273547/the-rise-of-the-istio-service-mesh.html