新华美玉官方网站在线做,网站关键词推广工具,网站开发和合同,百度收录提交入口网址作者 | 王夕宁 阿里巴巴高级技术专家
关注“阿里巴巴云原生”公众号#xff0c;参与文末留言互动#xff0c;即有机会获得赠书福利#xff01; 本文摘自于由阿里云高级技术专家王夕宁撰写的《Istio 服务网格技术解析与实践》一书#xff0c;文章从基础概念入手#xff0…
作者 | 王夕宁 阿里巴巴高级技术专家
关注“阿里巴巴云原生”公众号参与文末留言互动即有机会获得赠书福利 本文摘自于由阿里云高级技术专家王夕宁撰写的《Istio 服务网格技术解析与实践》一书文章从基础概念入手介绍了什么是服务网格及 Istio针对 2020 服务网格的三大发展趋势体系化、全方位地介绍了 Istio 服务网格的相关知识。你只需开心参与公众号文末互动我们负责买单技术人必备书籍《Istio 服务网格技术解析与实践》免费领~ 有外文指出2020 年 Service Mesh 技术将有以下三大发展
快速增长的服务网格需求Istio 很难被打败很可能成为服务网格技术的事实标准出现更多的服务网格用例WebAssembly 将带来新的可能。
什么是服务网格
Gartner 2018 关于服务网格技术趋势分析报告展示了一系列的服务网格技术划分服务网格技术的依据是基于应用服务代码是否必须对其服务网格感知及其是否锁定或锁定的程度。
基于编程框架的网格技术可以帮助开发人员构建一个架构体系良好的服务但这会导致应用代码与框架和运行时环境的紧密耦合。而基于 Sidecar 代理的服务网格技术不会为开发人员设置这些障碍并且使其管理和维护更加轻松能够提供更灵活的方法来配置运行时策略。 在微服务环境中可将单一应用程序分解为独立的多个组件并作为分布式服务进行部署这些服务通常是无状态的、短暂的、动态可扩展的运行在容器编排系统如 Kubernetes中。
服务网格一般由控制平面和数据平面组成。具体来说控制平面是一组在一个专用的命名空间中运行的服务。这些服务完成一些控制管理的功能包括聚合遥测数据、提供面向用户的 API、向数据平面代理提供控制数据等。而数据平面则是由一系列运行在每个服务实例旁边的透明代理构成。这些代理自动处理进出服务的所有流量因为它们是透明的所以这些代理充当了一个进程外网络堆栈向控制平面发送遥测数据并从控制平面接收控制信号。 服务实例可以根据需要进行启动、停止、销毁、重建或替换。因此这些服务需要一个通信中间件来支持服务的动态发现和自我修复连接能力从而使得这些服务之间能够以安全、动态和可靠的方式相互通信这就是服务网格所支持的功能。
服务网格是一个专用的基础设施层使服务到服务之间的通信更加安全、快速、可靠。如果你正在构建云原生应用程序则需要服务网格。在过去的一年中服务网格已成为云原生程序的关键组件它通过包含现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上服务网格通常实现为轻量级网络代理的组合这些代理与应用程序代码一起部署不需要知道应用程序是什么。
服务网格作为单独层的概念与云原生应用程序的兴起有关。在云原生模型中单个应用程序可能包含数百个服务每个服务可能有数千个实例并且每个实例可能处于不断变化的状态。这也是为什么像 Kubernetes 这样的协调器日益流行和必要的原因所在。这些服务之间的通信不仅变得越来越复杂而且也是运行时环境中最为常见的一部分因此管理这些服务之间的通信对于确保端到端的性能和可靠性至关重要。 服务网格是一种网络模型位于 TCP/IP 之上的抽象层。它假定底层的三四层网络存在并且能够从一点到另一点传送字节。它还假设该网络与环境的其他方面一样不可靠因此服务网络也必须能够处理网络故障。在某些方面服务网格类似于 TCP/IP。正如 TCP 协议栈抽象了在网络端点之间可靠地传递字节的机制一样服务网格抽象了在服务之间可靠地传递请求的机制。与 TCP 一样服务网格不关心实际有效负载或其编码方式只负责完成从服务 A 发送到服务B并且在处理任何故障的同时实现这一目标。但是与 TCP 不同的是服务网格不仅仅具备“使其工作”的能力还提供了一个统一的应用程序控制点用于将可见性和控制引入应用程序运行时。服务网格的明确目标是将服务通信从不可见的基础设施领域移出并转变为生态系统的一部分可以对其进行监控、管理和控制。
在云原生应用程序中保证请求具备完整的可靠性并非易事。服务网络通过各种强大的技术来管理这种复杂性支持熔断、延迟感知的负载均衡、最终一致性的服务发现、重试与超时等机制来尽可能保证可靠性。这些功能必须全部协同工作并且与其运行的复杂环境之间的相互作用也非常重要。
例如当通过一个服务网格向服务发出请求时其交互过程可以大致简化为如下步骤
服务网格组件通过应用动态路由规则来确定请求者想要的服务。请求应该路由到生产还是预发布的服务是路由到本地数据中心还是云中的服务是需要灰度到正在测试的服务的最新版本还是仍然路由到在生产中经过验证的旧版本所有这些路由规则都是动态可配置的并且可以全局应用也可以应用于任意流量片段找到正确的目的地后服务网格组件从相关的服务发现端点检索相应的实例池可能有多个实例。如果这些信息与服务网格组件在实践中观察到的信息不同那么它会决定要信任哪些信息来源服务网格组件根据各种因素选择最有可能返回快速响应的实例包括观察到的最近请求的延迟数据服务网格组件尝试将请求发送到选择的实例记录响应结果的延迟和响应类型如果实例已经由于各种原因宕机或者请求根本没有响应或者由于其他任何原因而无法处理请求服务网格组件则会根据需要在另一个实例上重试该请求前提是它知道请求是幂等的如果实例始终返回错误服务网格组件会将其从负载均衡池中逐出以便稍后定期重试。这种情况在互联网分布式应用中非常常见公共网络中的实例非常有可能由于某些原因导致瞬间故障如果请求的超时点已过服务网格组件则会主动使请求失败而不是通过进一步重试来添加负载以防雪崩发生。这一点对于互联网分布式应用至关重要否则一个小故障极有可能会引起雪崩式灾难与此同时服务网格组件以度量指标和分布式跟踪的形式捕获上述行为的各个方面并将这些数据发送到集中式的度量系统或者链路跟踪系统。值得注意的是这些功能都是在为分布式应用提供逐点弹性和应用程序范围的弹性能力。大规模分布式系统无论如何构建都有一个明确的特征任何小型本地化故障都有可能升级为系统范围的灾难性故障。服务网格必须设计成在基础系统接近其极限时通过减少负载和快速失败来防止这些故障升级。
为什么服务网格是必要的
服务网格本身并不是一个新功能更像是功能所在位置的转变。Web 应用程序始终必须管理服务通信的复杂性。在过去的十五年中服务网格模型的起源可以追溯到这些应用程序的演变过程。
在本世纪初中型 Web 应用程序的典型架构常见的是三层应用程序架构分为应用程序逻辑层、Web 服务逻辑层和存储逻辑层都是单独的层。层之间的通信虽然复杂但范围有限。这个时候的应用架构并没有网格但是在每个层的代码处理逻辑之间存在通信逻辑。
当网络发展到非常高规模时这种架构方法开始变得捉襟见肘。特别是一些大型互联网公司都面临着巨大的流量需求实现了有效的云原生方法的前身应用层被分成许多服务也就是现在通常所知的“微服务”层之间形成拓扑的通信方式。在这些系统中通常采用“胖客户端”库的形式也就是前面讲述过的类似于 Netflix 的 OSS 库Hystrix 的熔断能力就是很好的例证。这些代码库虽然与特定的环境相关并且需要使用特定的语言和框架但它们是用于管理服务之间通信的形式与能力在当时的情况下是不错的选择而且也在众多公司里被使用。
进入云原生时代之后云原生模型有两个重要因素
容器例如 Docker提供资源隔离和依赖管理编排层例如 Kubernetes将底层硬件抽象为同质的资源池。
尽管这些代码库组件在一定程度上允许应用程序具备一定的负载扩展能力并处理云环境中始终存在的部分故障但是随着数百个服务或数千个实例的增加以及存在不时重新调度实例的业务流程层单个请求通过服务拓扑所遵循的路径可能非常复杂。同时随着容器技术的普及且容器使每个服务都易于用另一种语言编写运行程序库式方法在此时此刻就变得捉襟见肘了。
这种复杂性和关键性的诉求使得应用越来越需要一个服务间通信的专用层该专用层与应用程序代码分离并且能够捕获底层环境的高度动态弹性能力。该层就是我们需要的服务网格。
服务代理可以帮助我们在云环境服务架构中添加重要功能。每个应用程序都可以拥有自己的要求或配置以了解代理在给定其工作负载目标时的行为方式。随着应用程序和服务越来越多配置和管理大量代理可能非常困难。此外在每个应用程序实例中使用这些代理可以为构建丰富的高级功能提供机会否则我们将不得不在应用程序本身执行这些功能。
服务代理形成一个网状的数据平面通过该数据平面处理和观察所有服务间的流量。数据平面负责建立、保护和控制通过网格的流量。负责数据平面如何执行的管理组件称为控制平面。控制平面是网格的大脑并为网格使用人员提供公开 API以便操纵网络行为。
Istio 服务网格
Istio 是一个用于连接/管理以及安全化微服务的开放平台提供了一种简单的方式用于创建微服务网格并提供负载均衡、服务间认证以及监控等能力关键的一点是并不需要修改太多服务就可以实现上述功能。Istio 本身是一个开源项目它提供了一致的方式用于连接、加固、管理和监控微服务最初是由 Google、IBM 和 Lyft 创建的服务网络的开源实现。Istio 可以帮助你以透明的方式为服务架构添加弹性和可观察性能力。使用 Istio应用程序不必知道它们是服务网格的一部分。每当应用程序与外界交互时Istio 将代表应用程序处理网络流量。这意味着如果你正在做微服务Istio 可以带来很多好处。
Istio 主要提供以下功能
流量管理控制服务之间调用的流量和API调用使得调用更可靠并使网络在恶劣情况下更加健壮可观测性获取服务之间的依赖以及服务调用的流量走向从而提供快速识别问题的能力策略执行控制服务的访问策略不需要改动服务本身。
服务身份和安全为网格中的服务提供可验证身份并提供保护服务流量的能力使其可以在不同可信度的网络上流转。
Istio 第一个生产可用版本 1.0 于 2018 年 7 月 31 日正式发布并于 2019 年 3 月发布版本 1.1。之后社区按照快速迭代的方式在三个月内接连发布了 10 个小版本。截至本书完稿之际社区已经发布了 1.4 版本。
Istio 的数据平面默认使用 Envoy 代理开箱即用可帮助你配置应用程序以在其旁边部署服务代理的实例。Istio 的控制平面由一些组件组成这些组件为最终用户和运维人员提供运维 API、代理的配置 API、安全设置、策略声明以及其他更多功能。我们将在本书的后续部分介绍这些控制平面组件。
Istio 最初是为在 Kubernetes 上运行而构建的但却是从部署平台中立的角度实现代码的。这意味着你可以在 Kubernetes、OpenShift、Mesos 和 Cloud Foundry 等部署平台上利用基于 Istio 的服务网格甚至可以在虚拟机、物理裸机上部署 Istio 环境。在后面的章节中我们将展示 Istio 对于包括私有数据中心在内的云组合的混合部署来说有多强大。在本书中我们将优先考虑在 Kubernetes 上进行部署在后面更高级的章节中会引入虚拟机等环节。
Istio 在希腊语中的意思是“启航”而 Kubernetes 在希腊语中可以翻译为“舵手”或“驾驶员”。所以从一开始 Istio 就期望与 Kubernetes 很好地配合高效地运行分布式微服务架构并提供安全、连接和监控微服务的统一方法。
通过每个应用程序实例旁边的服务代理应用程序不再需要具有特定于语言的弹性库来实现熔断、超时、重试、服务发现、负载均衡等功能。此外服务代理还处理度量标准收集、分布式跟踪和日志收集等。
由于服务网格中的流量流经 Istio 服务代理因此 Istio 在每个应用程序中都有控制点来影响和指导其网络行为。这允许服务运维人员可以控制路由流量并通过金丝雀部署、暗启动Dark Launch、分级滚动和 A/B 测试来实现细粒度部署。我们将在后面的章节中探讨这些功能。
核心功能
Istio 在服务网络中统一提供了许多关键功能主要包括流量管理、安全、可观测性、平台支持、集成和定制五个部分。
1.流量管理
通过简单的规则配置和流量路由Istio 可以控制服务之间的流量和 API 调用。Istio 简化了熔断器、超时和重试等服务级别属性的配置并且可以轻松设置 A/B 测试、金丝雀部署和基于百分比的流量分割的分阶段部署等重要任务。
Istio 有开箱即用的故障恢复功能你可以在问题出现之前先发现问题通过优化使服务之间的调用更加可靠。
2.安全
Istio 具备强大的安全功能使开发人员可以专注于应用程序级别的安全性。Istio 提供底层安全通信信道并大规模管理服务通信的认证、授权和加密。使用 Istio服务通信在默认情况下是安全的允许跨多种协议和运行时一致地实施策略而关键的是所有这些都很少或根本不需要应用程序更改。
虽然 Istio 与平台无关但将其与 Kubernetes 网络策略一起使用时其优势更大包括在网络和应用层保护 pod-to-pod 或服务到服务通信的能力。后续章节中会讲述如何在 Kubernetes 中结合网络策略与 Istio 来共同保护服务。
3.可观测性
Istio 具备强大的追踪、监控和日志记录能力可让你深入了解服务网格部署。通过 Istio 的监控功能可以真正了解服务性能如何影响上游和下游的功能而其自定义的仪表板可以提供对所有服务性能的可视性并让你了解该性能如何影响其他进程。
Istio 的 Mixer 组件负责策略控制和遥测收集提供后端抽象和中介将 Istio 的其余部分与各个后端基础设施的实现细节隔离开来并为运维人员提供对网格和后端基础设施之间所有交互的细粒度控制。
所有这些功能可以让你更有效地设置、监控和实施服务上的服务等级目标 SLO。当然最重要的是可以快速有效地检测和修复问题。
4.平台支持
Istio 是独立于平台的目标是可以在各种环境中运行包括跨云、内部部署、Kubernetes、Mesos 等。你可以在 Kubernetes 上部署 Istio 或在具有 Consul 的 Nomad 上部署。Istio 目前支持
在 Kubernetes 上部署的服务使用 Consul 注册的服务在各个虚拟机上运行的服务。
5.集成和定制
可以扩展和自定义 Istio 的策略实施组件以与现有的 ACL、日志记录、监控、配额、审计等解决方案集成。
此外从版本 1.0 开始Istio 支持基于 MCPMesh Conf?iguration Protocol网格配置协议进行配置分发。通过使用 MCP可以很容易地集成外部系统例如可以自己实现 MCP 服务器然后将其集成到 Istio 中。MCP 服务器可以提供以下两个主要功能
连接并监控外部服务注册系统以获取最新的服务信息例如 Eureka、ZooKeeper 等系统将外部服务信息转换为 Istio ServiceEntry 并通过 MCP 资源发布。
为什么要使用 Istio
在从单体应用程序向分布式微服务架构的转型过程中开发人员和运维人员面临诸多挑战使用 Istio 可以解决这些问题。随着规模和复杂性的增长服务网格越来越难以理解和管理各种需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及更加复杂的运维例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。Istio 提供了一个完整的解决方案通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。
Istio 提供一种简单的方式来为已部署的服务建立网络该网络具有负载均衡、服务间认证、监控等功能只需要对服务的代码进行一点改动或不需要做任何改动。想要让服务支持 Istio只需要在你的环境中部署一个特殊的 Sidecar 代理使用 Istio 控制平面来配置和管理代理拦截微服务之间的所有网络通信。
此外面向服务的架构SOA的企业服务总线ESB与服务网格有一些相似之处在 SOA 体系架构中 ESB 对于应用程序服务来说是透明的这意味着应用程序对它无感知。服务网格可以得到类似的行为服务网格应该对应用程序透明就像 ESB 那样简化服务间的调用。当然ESB 还包括交互协议的中转、消息转换或者基于内容的路由之类的事情而服务网格不负责 ESB 所做的所有功能。服务网格确实通过重试、超时、熔断提供服务请求的弹性能力同时也提供服务发现和负载均衡等服务。复杂的业务转换、业务流程编排、业务流程异常以及服务编排能力等并不属于服务网格的解决范畴。相对于 ESB 的集中式系统服务网格中的数据平面高度分布其代理与应用程序并存这消除了 ESB 架构中经常出现的单点故障瓶颈问题。
当然也需要清楚服务网格没有解决哪些问题像 Istio 这样的服务网格技术通常都提供了强大的基础架构功能可以触及分布式架构的许多领域但肯定不能解决你可能遇到的每个问题。理想的云架构能从实现的每个层中分离出不同的关注点。
在基础架构的低层更加关注基础设施如何提供自动化部署的基础架构能力。这有助于将代码部署到各种平台上无论是容器、Kubernetes还是虚拟机等。Istio 不会限定你应该使用哪种自动化部署工具。
在更高的业务应用级别应用程序业务逻辑是企业保持核心竞争力的差异化资产。这些代码资产涉及了包括业务功能单一以及需要调用的服务以何种顺序执行如何执行这些服务的交互如何将它们聚合在一起以及在发生故障时要执行的操作等。Istio 不实现或替换任何业务逻辑它本身不执行服务编排也不会提供业务负载的内容转换或者增强不会针对负载进行拆分或者聚合。这些功能最好留给应用程序中的库和框架来实现。
下图是关于云原生应用程序中的关注点分离其中 Istio 对应用程序层起支持作用并位于较低级别的部署层之上。 Istio 扮演着部署平台和应用程序代码之间的连接角色。它的作用是促进从应用程序中取出复杂的网络逻辑可以基于作为请求的一部分的外部元数据例如 HTTP 标头等来执行基于内容的路由。也可以根据服务和请求的元数据匹配进行细粒度的流量控制和路由。还可以保护传输和卸载安全令牌验证或者可以实施服务运维人员定义的配额和使用策略等。 了解 Istio 的能力与其他系统的相似之处以及它在架构中的位置可帮助我们像我们过去可能遇到的有前途的技术那样犯同样的错误至关重要。
成熟度和支持级别
Istio 社区针对每个组件功能的相对成熟度和支持级别提出了不同的功能阶段定义分别用 Alpha、Beta 和 Stable 来描述各自的状态如表 1-1 所示。 表 1-2 是我们摘录的 Istio 1.4 版本现有功能中已经达到 Beta 及 Stable 功能阶段的列表。此信息将在每次发布后更新可参照官方网站获取更新状态。 当然Istio 仍然有一些功能还处于 Alpha 状态如 Istio CNI 插件它能够代替 istio-init 容器完成同样的网络功能而且无需 Istio 用户额外申请 Kubernetes RBAC 授权以及在 Envoy 中使用自定义过滤器的能力等等。相信在后续不断完善中这些功能将逐渐变得越来越稳定且生产可用。
总结
Istio 作为当前业界服务网格领域中最流行的实现其功能允许你在混合环境中简化云原生服务架构应用的运行和操作。Istio 使开发者专注于使用自己喜欢的编程语言构建服务功能这有效地提升了开发者的生产力同时开发者免于将解决分布式系统问题的代码糅合到业务代码中。
Istio 是一个完全开放的开发项目拥有一个充满活力、开放和多元化的社区它的目标是赋能开发者和运维人员使他们在所有环境中都能敏捷地发布和维护微服务拥有底层网络的完全的可见性且获得一致的控制和安全能力。在本书的后续部分我们将展示如何利用 Istio 的功能在云原生世界中运行微服务。
本文摘自于《Istio 服务网格解析与实战》经出版方授权发布。本书由阿里云高级技术专家王夕宁撰写详细介绍 Istio 的基本原理与开发实战包含大量精选案例和参考代码可以下载可快速入门 Istio 开发。Gartner 认为2020 年服务网格将成为所有领先的容器管理系统的标配技术。本书适合所有对微服务和云原生感兴趣的读者推荐大家对本书进行深入的阅读。 推荐阅读 【1】阿里云服务网格ASM公测来袭系列之一快速了解什么是ASM 文章链接https://yq.aliyun.com/articles/748761 【2】阿里云服务网格ASM之扩展能力(1)在ASM中通过EnvoyFilter添加HTTP请求头 文章链接https://yq.aliyun.com/articles/748807 “阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践做最懂云原生开发者的公众号。” 原文链接 本文为云栖社区原创内容未经允许不得转载。
