有关微服务的优缺点的简短故事，服务网格概念和Google工具，它们使您可以运行微服务应用程序而不会被无休止的策略，访问和证书设置所困扰，并迅速发现错误而不是隐藏在代码中，而是隐藏在微服务逻辑中。
本文基于去年的DevOops 2017大会上
Craig Box的
报告，该
报告的视频和翻译被删减。
Craig Box（Craig Box，
Twitter ）-Google的DevRel，负责微服务以及Kubernetes和Istio工具。 他当前的故事是关于在这些平台上管理微服务的。
让我们从一个称为Service Mesh的相对较新的概念开始。 该术语用于描述组成应用程序的交互微服务网络。
在较高的层次上，我们将网络视为仅移动位的管道。 我们不想担心它们，例如，不必担心应用程序中的MAC地址，但我们会努力考虑它们所需的服务和连接。 如果从
OSI的角度看，那么我们有一个第三层网络（具有确定路由和逻辑寻址的功能），但是我们想从第七层的角度来考虑（具有访问网络服务的功能）。
真正的第七层网络应该是什么样？ 也许我们希望看到类似问题服务周围流量的痕迹。 这样您就可以连接到服务，同时将模型级别从第三级别提升。 我们想要了解集群中正在发生的事情，找到意外的依赖关系，找出故障的根本原因。 我们还需要避免不必要的开销，例如，以高延迟连接或连接到具有冷缓存或未完全预热的服务器。
我们必须确保服务之间的流量受到保护，免受微不足道的攻击。 需要相互TLS身份验证，但不能在我们编写的每个应用程序中嵌入适当的模块。 重要的是，不仅要在连接级别上而且还要在更高级别上控制围绕我们的应用程序的内容。
Service Mesh是使我们能够在微服务环境中解决上述问题的一层。
整体和微服务：利弊
但是首先我们要问自己，为什么我们要彻底解决这些问题？ 我们以前是如何进行软件开发的？ 我们有一个看起来像这样的应用程序-就像一个整体。
太好了：所有代码都处于完整视图。 为什么不继续使用这种方法？
是的，因为整体存在其自身的问题。 主要困难在于，如果我们要重建此应用程序，则即使没有任何更改，也必须重新部署每个模块。 我们被迫使用相同的语言或兼容的语言来创建应用程序，即使不同的团队在工作。 实际上，不能单独测试各个零件。 是时候更改它了，是时候使用微服务了。
因此，我们将整体分为几部分。 您可能会注意到，在此示例中，我们删除了一些不必要的依赖关系，并停止使用从其他模块调用的内部方法。 我们从之前使用的模型创建了服务，在需要维护状态的情况下创建了抽象。 例如，每个服务应具有独立的状态，以便在您访问它时，您不必担心我们其余环境中正在发生的事情。
结果如何？
我们离开了庞大的应用程序世界，以获取真正看起来很棒的东西。 我们加快了开发速度，停止使用内部方法，创建了服务，现在我们可以独立扩展它们，使服务更大，而无需合并其他所有东西。 但是，我们失去的改变的代价是什么？
我们在应用程序内部进行了可靠的调用，因为您只是简单地调用了函数或模块。 我们用不可靠的远程过程调用替换了模块内部的可信调用。 但是另一端的服务并非总是可用。
我们很安全，在同一台机器上使用相同的过程。 现在，我们正在连接可能位于不同计算机和不受信任网络上的服务。
在网络上的新方法中，可能有其他尝试连接到服务的用户出现。 延迟增加，同时它们的测量能力降低。 现在，我们在创建一个模块调用的所有服务中都有逐步的连接，我们不再只能在调试器中查看应用程序并找出导致故障的确切原因。 这个问题需要以某种方式解决。 显然，我们需要一套新的工具。
该怎么办？
有几种选择。 我们可以使用我们的应用程序，说如果
RPC第一次不起作用，那么您应该再次尝试，然后一次又一次。 请稍等，然后重试或添加抖动。 我们还可以添加入口-出口跟踪信息，以表示调用已开始和结束，这对我来说相当于调试。 您可以添加基础结构以提供连接身份验证，并教我们所有应用程序如何使用TLS加密。 我们将不得不承担各个团队的工作负担，并始终牢记SSL库中可能出现的各种问题。
在多个平台上保持一致性是一项不感恩的任务。 我希望应用程序之间的空间变得合理，以便进行跟踪。 我们还需要能够在运行时更改配置，以免重新编译或重新启动应用程序以进行迁移。 这些愿望清单并实现服务网格。
伊斯斯蒂奥
谈论
Istio 。
Istio是用于连接，管理和监视微服务体系结构的完整框架。 Istio旨在在Kubernetes上工作。 他本人并没有部署该软件，也不希望在我们用于Kubernetes中的容器的计算机上使用该软件。
在图中，我们看到了构成微服务的机器和模块的三个不同部分。 我们有一种使用Kubernetes提供的机制将它们组合在一起的方法。 我们可以针对某个特定的组，该组可能具有自动缩放功能，已附加到Web服务或可能具有其他部署方法，它将包含我们的Web服务。 在这种情况下，我们无需考虑机器，我们在访问网络服务的级别上进行操作。
这种情况可以以图表的形式表示。 考虑当我们有一个机制来进行图像处理的例子。 左侧的用户是微服务中来自我们的流量。
要接受来自用户的付款，我们有一个单独的付款微服务，该服务调用位于群集外部的外部API。
为了处理用户登录，我们提供了一个身份验证微服务，该服务将状态再次存储在集群外部的
Cloud SQL数据库中 。
Istio是做什么的？ Istio改进了Kubernetes。 您可以使用Kubernetes中的一个名为Initializer的alpha函数来安装它。 部署软件时，kubernetes会注意到它并询问我们是否要更改并在每个kubernetes中添加另一个容器。 此容器将处理路径和路由，请注意所有应用程序更改。
这就是Istio电路的外观。
我们拥有外部计算机，它们为特定服务中的流量提供入站和出站代理。 我们可以卸载已经讨论过的功能。 我们不需要教应用程序如何使用TLS执行遥测或跟踪。 但是我们可以在其中添加其他内容：自动中断，速度限制，
金丝雀释放 。
现在，所有流量都将流经外部计算机上的代理服务器，而不是直接流向服务。 Kubernetes在相同的IP地址上执行所有操作。 我们将能够拦截将流向前台或终端服务的流量。
Istio使用的外部代理称为
Envoy 。
Envoy实际上比Istio古老，它是由Lyft开发的。 投入生产已经超过一年，启动了微服务的整个基础架构。 我们与社区合作为Istio项目选择了Envoy。 因此，谷歌，IBM和LYFT是仍在努力的三家公司。
Envoy用C ++ 11编写。在成为开源项目之前，它已经投入生产18个月以上。 将其连接到服务时不会占用很多资源。
特使可以做的几件事。 这是为HTTP创建代理服务器的过程，包括HTTP / 2和基于它的协议，例如gRPC。 它还可以在二进制级别转发到其他协议。 Envoy控制您的基础结构区域，因此您可以使自己的零件保持自治。 它可以处理大量的重试和等待网络连接。 您可以设置一定的尝试次数，以在停止呼叫之前将服务器连接到服务器，然后将服务未响应的信息传输到服务器。
无需担心重新加载应用程序以向其添加配置。 您只需使用与kubernetes非常相似的API连接到它，然后在运行时更改配置。
Istio团队为UpStream Envoy平台做出了巨大贡献。 例如，注入错误警报。 我们可以看到在失败对象的请求数量超过要求的情况下，应用程序的行为方式。 并且还实现了图形显示和交通分离的功能，以处理使用金丝雀部署的情况。
该图显示了Istio系统的架构。 我们将仅采用前面提到的两个微服务。 最终，在图中，一切都非常类似于软件定义的网络。 从我们随应用程序一起部署的Envoy代理服务器，使用命名空间中的IP表传输流量。 控制面板负责管理控制台，但不自行处理流量。
我们有三个组成部分。 创建配置的飞行员查看使用Istio控制面板的API可以更改的规则，然后更新Envoy，使其行为类似于群集发现服务。 Istio-Auth充当证书颁发机构，并将TLS证书传输到代理。 该应用程序不需要SSL，它们可以通过HTTP连接，并且代理将为您处理所有这一切。
Mixer处理请求以确保您遵守安全策略，然后传输遥测信息。 在不对应用程序进行任何更改的情况下，我们可以看到集群内部发生的所有事情。
Istio的好处
因此，让我们更详细地讨论从Istio获得的五件事。 首先，考虑
交通管理 。 我们可以将流量控制与基础架构扩展区分开来，因此较早的时候我们可以做20个应用程序实例，其中19个将在旧版本上，而一个在新版本上，即5％的流量将在新版本上。 借助Istio，我们可以部署所需数量的任何实例，并同时指示应将多少百分比的流量发送到新版本。 一个简单的分离规则。
可以使用规则随时对所有内容进行编程。 Envoy将随着配置更改而定期更新，这不会导致服务中断。 由于我们在访问网络服务的级别上工作，因此我们可以查看软件包，在这种情况下，就有机会进入位于网络第三层的用户代理。
例如，我们可以说来自iPhone的任何流量都遵循不同的规则，并且我们会将一部分流量定向到新版本，我们要针对特定设备进行测试。 内部调用微服务可以确定它需要连接到哪个特定版本，您可以将其转移到另一个版本，例如2.0。
第二个优点是
透明度 。 当您在集群内部有一个视图时，您可以了解它的构成方式。 我们不需要为开发过程中的指标创建工具。 指标已经存在于每个组件中。
有人认为保留一个日志记录进行监视就足够了。 但是实际上，我们需要的是拥有一套通用的指标，可以将其提供给任何监视服务。
这就是使用Prometheus服务创建的Istio工具栏的外观。 请记住将其部署在群集中。
在示例中，屏幕快照显示了特定于整个集群的许多受监视参数。 可以推断出更有趣的事情，例如，有多少百分比的应用程序会给出500个以上的错误，这意味着失败。 响应时间汇总在群集内的所有呼叫和响应服务实例中；此功能不需要设置。 Istio知道Prometheus支持什么，他知道集群中可用的服务，因此Istio-Mixer可以将指标发送到Prometheus，而无需任何其他设置。
让我们看看它是如何工作的。 如果调用特定服务，则代理服务会将有关此调用的信息发送到Mixer，后者会捕获参数，例如响应的等待时间，代码状态和IP。 对其进行规范化并将其发送到您配置的任何服务器。 特别是为了显示主要指示器，有Prometheus服务和FLUX DB适配器，但是您也可以编写自己的适配器并以任何格式显示任何其他应用程序的数据。 如果您要添加新指标，则无需在基础架构中进行任何更改。
如果您想做更深入的研究，请使用
Zipkin分布式跟踪
系统 。 有关通过Istio-Mixer路由的所有呼叫的信息可以发送到Zipkin。 在响应用户时，您将在其中看到微服务调用的整个链，并轻松找到延迟处理时间的服务。
在应用程序级别，几乎不必担心创建跟踪。 Envoy本身将所有必要的信息传递给Mixer，Mixer将其发送到跟踪，例如，Zipkin，来自Google或任何其他用户应用程序的
stackdriver跟踪 。
让我们谈谈
容错和效率 。
首先，需要在服务调用之间设置超时以测试负载平衡器的运行状况。 我们在此连接中引入错误，然后看看会发生什么。 考虑一个例子。 假设服务A和服务B之间存在连接。我们等待视频服务的响应100毫秒，如果未收到结果，则仅进行3次尝试。 本质上，在报告连接尝试失败之前，我们将花费300毫秒的时间。
此外，例如，我们的电影服务应通过另一个微服务查看电影的评级。 评级的超时时间为200毫秒，并给出了两次呼叫尝试。 如果无法达到星级，致电视频服务可能会导致您等待400毫秒。 但是，我们记得，在300毫秒后，电影服务将报告它处于空闲状态，并且我们永远不会知道失败的真正原因。 使用超时并测试在这些情况下会发生什么是一种在微服务体系结构中查找各种聪明错误的好方法。
现在让我们来看看效率。 kubernetes平衡器本身仅在第四层级别起作用。 我们发明了一种输入构造器，用于从第二层到第七层进行负载平衡。 Istio被实现为可访问网络服务的网络层的平衡器。
我们执行TLS卸载，因此我们在Envoy中使用了掺杂良好的现代SSL，因此您不必担心漏洞。
Istio的另一个优势是
安全性 。
Istio的基本安全功能是什么？ Istio-Auth服务可在多个方向上工作。 它为
SPIFFE服务使用了公共框架和一组认证标准。 如果我们在谈论流量，那么我们有一个Istio证书颁发机构，该证书颁发机构为在群集中运行的服务帐户颁发证书。 这些证书符合SPIFFE标准，由Envoy使用kubernetes安全机制分发。 Envoy使用密钥进行双向TLS身份验证。 因此，后端应用程序接收标识符，以此为基础可以组织策略。
Istio自己维护根证书，因此您不必担心撤销和到期日期。 系统将响应自动缩放，因此引入新实体，您将获得新证书。 没有手动设置。 您不需要配置防火墙。 用户将使用网络策略和kubernetes在容器之间实施防火墙。
最后，
应用政策 。 Mixer是基础架构后端的集成点，您可以使用Service Mesh进行扩展。 服务可以轻松地在集群中移动，可以在多个环境中，云中或本地部署。 一切都旨在对通过Envoy进行的呼叫进行操作控制。
我们可以允许和禁止特定的呼叫，为未接呼叫设置前提条件，限制其速度和数量。例如，您每天允许20次免费请求某些服务。如果用户发出了20个请求，则后续的请求将不被处理。前提条件可能包括诸如服务器经过身份验证，ICL以及列入白名单之类的内容。在要求使用该服务的每个人都具有相同的访问速度的情况下，可以使用配额管理。最后，Mixer收集准备就绪的遥测请求和响应结果。这使制造商和用户可以使用服务观看此遥测。
还记得我们开始学习Istio的带有照片应用程序的第一张幻灯片吗？以上所有内容都以这种简单形式隐藏。在顶层，您所需的一切将自动完成。您将部署应用程序，而不必担心如何定义安全策略或配置某些路由规则。该应用程序将完全按照您的期望运行。如何开始使用Istio
Istio支持kubernetes的早期版本，但是我所谈论的新的初始化器功能在1.7及更高版本中。这是kubernetes中的Alpha函数。我建议使用Google Container Engine Alpha群集。我们拥有可以在特定天数内启用的群集，同时可以使用其中的所有生产功能。首先，Istio是github上的一个开源项目。我们刚刚发布了0.2版。在版本0.1中，您可以在kubernetes名称空间中管理同名对象。从0.2版开始，我们支持在自己的名称空间和kubernetes集群中工作。我们还增加了对管理在虚拟机上运行的服务的功能的访问权限。您可以在虚拟机中部署Envoy并保护在其上运行的服务的安全。将来，Istio将支持其他平台，例如Cloud Foundry。这里是该框架的快速安装指南。。如果您的群集运行的Google Container Engine 1.8已启用alpha功能，则安装Istio只是一个命令。如果您喜欢这次演讲，请参加10月14日在Peter 举行的DevOops 2018大会：您不仅可以聆听演讲，还可以与讨论区的任何发言人聊天。