当前，业界主要有以下主要几种 Service Mesh 框架，下面进行详细的说明及对比。
当我们尝试在 Kubernetes 中使用 NodePort 或 LoadBalancer 类型的服务设施配置进行通信时，Istio 或许是一个非常流行、新兴的开源服务网格产品，其能够用于通信管理、可观察性、错误处理及安全性等。作为微服务架构体系的一部分，为了无需过多地使用重复的逻辑填充每个微服务代码，我们可以利用 Istio 服务网格在一个地方完成所有这些事情。
根据CNCF的最新年度调查，很明显，很多人对在他们的项目中使用服务网格表现出了浓厚的兴趣，并且许多人已经在他们的生产中使用它们。近69％的人正在评估Istio，64％的人正在研究Linkerd。Linkerd是市场上第一个服务网格，但是Istio使服务网格更受欢迎。这两个项目都是最前沿的，而且竞争非常激烈，因此选择一个项目是一个艰难的选择。在此博客文章中，我们将了解有关Istio和Linkerd体系结构，其运动部件的更多信息，并比较其产品以帮助您做出明智的决定。
Flagger 团队很荣幸为你带来 Kubernetes Gateway API 支持，作为1.19.0 版本[1]的一部分。阅读本文，了解为什么这是 Flagger 的一个重大发展，以及如何利用它。
Istio的可观测性包括metrics，日志，分布式链路跟踪以及可视化展示。下面主要介绍如何在istio中部署基于Prometheus的metrics监控，基于jaeger的链路跟踪和基于kiali的可视化界面。
虽然 Flagger 可以单独执行加权路由和 A/B 测试，但通过 Istio，它可以将两者结合起来，从而形成具有会话关联性的 Canary 版本。这种部署策略将金丝雀发布与 A/B 测试相结合，当我们尝试逐步向用户推出新功能时，金丝雀发布是很有帮助的，但由于其路由的特性（基于权重），即使用户之前已经被路由到新版本，他们仍然还有路由到应用程序的旧版本上，这种情况可能不符合我们的预期。
Cilium 最近两年真的是很火了。我在 2019 年折腾 Cilium 的时候，那时候它还处于不温不火的状态。比如我当时发布了一篇 K8S 生态周报| cilium 1.6 发布 100% kube-proxy 的替代品 | MoeLove ，很多人还在好奇 cilium 到底是什么。
[1] https://k8s.io/docs/concepts/services-networking/ingress
在云上跨区域流量通常需要收费，我们可以借助istio的能力将流量路由到同一区域内的服务将节省大量的出口流量费。
将流量从基础设施扩展中解耦，这样就可以让 Istio 提供各种独立于应用程序代码之外的流量管理功能。除了 A/B 测试的动态请求路由，逐步推出和金丝雀发布之外，它还使用超时、重试和熔断器来处理故障恢复，最后还可以通过故障注入来测试服务之间故障恢复策略的兼容性。这些功能都是通过在服务网格中部署的 Envoy sidecar/代理来实现的。
通过配置路由调整服务之间的流量，支持AB测试，金丝雀测试和流量百分比分发，支持断路器，超时和重试。
在微服务中另外一个重点就是网关,网关理论包含入口网关和出口网关,传统意义上的网关很难做到出口网络控制,但是对于Istio是一件非常轻松的事情(因为所有的出口流量都会经过Istio),入口网关控制解析路由数据流向,出口网关控制对外访问的限制,在Istio中使用了 Ingress和Egress 来实现网关的功能.
冉昕，腾讯云服务网格TCM产品经理，现负责云原生流量接入网关与应用通信可观测性等产品特性策划与设计工作。
Istio是一个开放平台，提供统一的方式来集成微服务，管理跨微服务的流量，执行策略和汇总遥测数据。Istio的控制面板在底层集群管理平台（如Kubernetes，Mesos等）上提供了一个抽象层
作者 | 董红帅，马蜂窝微服务体系建设以及基础服务能力建设专家。 马蜂窝作为旅行社交平台，是数据驱动的新型旅行电商。基于十余年的内容积累，马蜂窝通过 AI 技术与大数据算法，将个性化旅行信息与来自全球各地的旅游产品供应商实现连接，为用户提供与众不同的旅行体验。 随着业务的发展，马蜂窝架构也在跟随技术步伐进行更迭，开始基于 Kubernetes 进行更多的延展。在这个技术背景下，需要针对云服务开启新一轮的架构更新，比如：微服务场景建设新的蜂效平台及周边设施来支持迭代和流量泳道的能力，在多 Kubernete
8月1日凌晨，Istio 1.0发布，已生产就绪！ Cilium社区感谢所有Istio贡献者为此付出的巨大努力。我们很幸运能够参与社区活动，为Istio做出贡献，并帮助一些用户通过Istio和Cilium进行生产部署。如果您有兴趣在深入了解技术细节之前了解Istio + Cilium的用户故事，请考虑阅读HP FitStation团队（最大的Cilium + Istio用户之一）发布的以下Istio博客: Istio是惠普FitStation平台的游戏规则的改变者。
Istio Bookinfo 示例包含四个独立的微服务，每个微服务都有多个版本。 其中一个微服务 reviews 的三个不同版本已经部署并同时运行。 为了说明这导致的问题，在浏览器中访问 Bookinfo 应用程序的 /productpage 并刷新几次。 您会注意到，有时书评的输出包含星级评分，有时则不包含。 这是因为没有明确的默认服务版本路由，Istio 将以循环方式请求路由到所有可用版本，此任务的最初目标是应用将所有流量路由到微服务的 v1 （版本 1）的规则。
现在最火的后端架构无疑是微服务了，微服务将之前的单体应用拆分成了许多独立的服务应用，每个微服务都是独立的，好处自然很多，但是随着应用的越来越大，微服务暴露出来的问题也就随之而来了，微服务越来越多，管理越来越麻烦，特别是要你部署一套新环境的时候，你就能体会到这种痛苦了，随之而来的服务发现、负载均衡、Trace跟踪、流量管理、安全认证等等问题。如果从头到尾完成过一套微服务框架的话，你就会知道这里面涉及到的东西真的非常多。当然随着微服务的不断发展，微服务的生态也不断完善，最近新一代的微服务开发就悄然兴起了，那就是服务网格/Service Mesh。
备注：本文根据腾讯云赵化冰和知乎唐阳在 IstioCon 2021 中的演讲 “How to Manage Any Layer-7 Traffic in an Istio Service Mesh?”
istio搁置有一段时间了，并且现在开始介入的是最新版本1.4.2，所以难免有些错误的地方，非常欢迎指正与讨论。
赵化冰，腾讯云高级工程师，Istio Member，ServiceMesher管理委员，Istio 项目贡献者， Aerika 项目创建者 ，热衷于开源、网络和云计算。目前主要从事服务网格的开源和研发工作。 唐阳，知乎基础架构工程师。Istio 项目贡献者，Argo 项目贡献者，专注于开源，云原生与微服务。目前负责知乎服务网格的研发工作。 本文根据腾讯云高级工程师赵化冰和知乎基础架构工程师唐阳在 IstioCon 2021 中的演讲 “How to Manage Any Layer-7 Traffic
随着Istio 1.16.0[1]的正式发布，也宣布了 Istio 基于Kubernetes Gateway API[2]的实现进入到了 Beta 阶段，这意味着 Istio 中所有南北向（Ingress）流量管理都可以迁移至 Kubernetes Gateway API。未来随着 Kubernetes Gateway API 的发展和成熟，Istio 东西向（Mesh）流量管理 API 也会被其慢慢代替。
2017 年，Google 联合 IBM、Lyft 推出了 Istio，因为有 K8s 的成功经验在先，Istio 一出生就引人注目，其受到的关注度甚至远超最早提出服务网格概念的 Linkerd。只要有关注度，就有溢价存在，业界为 Istio 买账更像是买一种预期，认为 Istio 能像 K8s 一样，快速成为服务网格领域的事实标准。
当前，业界主要有以下主要几种Service Mesh框架，下面进行详细的说明及对比。
最近几年，软件体系结构领域发生了巨大的变化。我们都见证了这一重大转变，就是将大型的整体应用程序和粗粒度应用程序分解为被称为微服务的细粒度部署单元，主要通过同步REST和gRPC接口以及异步事件和消息传递进行通信。这种架构的好处很多，但缺点同样明显。在“旧世界”中曾经很简单的软件开发过程，例如调试，概要分析和性能管理，现在变得复杂了一个数量级。此外，微服务架构也带来了自己独特的挑战。
微服务架构可谓是当前软件开发领域的技术热点，它在各种博客、社交媒体和会议演讲上的出镜率非常之高，无论是做基础架构还是做业务系统的工程师，对微服务都相当关注，而这个现象与热度到目前为止，已经持续了近 5 年之久。
本文翻译自 https://www.tigera.io/blog/running-istio-on-kubernetes-in-production-part-i/，作者 Alexander Lukyanchenko，发表于2019年5月。
译文链接： https://zhuanlan.zhihu.com/p/369068128 译者：iyacontrol 来源：分布式实验
我们将主要关注Istio，它是服务网格的一种具体实现。在此过程中，我们将介绍Istio的核心架构。
- 前言 - 在本教程中，我们将介绍服务网格的基础知识，并了解它如何实现分布式系统架构。 我们将主要关注Istio，它是服务网格的一种具体实现。在此过程中，我们将介绍Istio的核心架构。 - 什么是服务网络 - 在过去的几十年中，我们已经看到了单体应用程序开始拆分为较小的应用程序。此外，诸如Docker之类的容器化技术和诸如Kubernetes之类的编排系统加速了这一变化。 尽管在像Kubernetes这样的分布式系统上采用微服务架构有许多优势，但它也具有相当的复杂性。由于分
一个完全开源的服务网格产品，对分布式应用是透明的。Istio 管理服务之间的流量，实施访问政策并汇总遥测数据，而不需要更改应用代码。Istio 以透明的方式对现有分布式应用进行分层，从而简化了部署复杂性。
服务网格是一个软件层，用于处理应用程序中服务之间的所有通信。该层由容器化微服务组成。随着应用程序的扩展和微服务数量的增加，监控服务的性能变得越来越困难。为了管理服务之间的连接，服务网格提供了监控、记录、跟踪和流量控制等新功能。它独立于每项服务的代码，这使它能够跨网络边界和多个服务管理系统工作。
不夸张的说，正是 Istio 的出现使 “Service Mesh” 这一概念开始流行起来。在深入介绍 Istio 的细节之前，让我们首先简单地了解一下 Service Mesh 是什么，以及它的重要性体现在哪里。我们都已经了解单体应用所面对的挑战，一种显而易见的方案是将其分解为多个微服务。虽然这种方式简化了单个服务的开发，但对于成百上千的微服务的通信、监控以及安全性的管理并不是一件简单的事。直至目前，对于这些问题的解决方案也只是通过自定义脚本、类库等方式将服务串联在一起，并且投入专门的人力以处理分布式系统的管理任务。但这种方式降低了各个团队的效率，并且提高了维护的成本。这正是 Service Mesh 大显身手的时机。
Istio 可以管理集群的出入口流量，当客户端访问集群内的应用时， Istio 可以将经过 istio-ingressgateway 的流量实现负载均衡和熔断等一系列功能。
Istio 近期的版本中出现了一个新的 API 组：networking.istio.io/v1alpha3，应该会替代现有的config.istio.io/v1alpha2 API。新的 API 不管是结构上还是功能上、以及命名上，都有很大差异。这里使用一些简单例子，体验一下 Alpha 3 带来的变化。
版权说明：本文由高晓雪参照如下文档翻译。魏新宇根据高晓雪的翻译文档，做了适当的注解和文字矫正。 https://developers.redhat.com/download-manager/file/istio_mesh_for_microservices_r1.pdf 本文适合对istio的读者提供泛读参考，对istio理解较深的读者，建议直接阅读英文原文。本系列分上下两篇：上篇为1-3章内容，下篇为4-7章内容。 目录 为微服务引入Istio服务网格 1.介绍 1.1.更快的挑战 1.2.认识Ist
官方解释：An open platform to connect, secure, control and observe services.
solo宣布了Service Mesh Hub的开源版本，这代表了其在简化复杂企业环境中使用服务网格的经验方面向前迈出了一大步。
新版本上线之前，经历过开发和测试人员的验证，也经过产品经理的验收。可是当要上线到生产环境时，谁也保证不了上线一定就能跑起来。所以往往需要在上线时保持新版本和旧版本同时在用，测试人员或内测用户可以访问新版本，其他人继续使用旧版本。再有就是上线时新旧系统能够丝滑切换，用户完全感知不到这种变化。
初始的 Kubernetes 内部服务向外暴露，使用的是自身的 LoadBlancer 和 NodePort 类型的Service，在集群规模逐渐扩大的时候，这种 Service 管理的方式满足不了我们的需求，比如 NodePort 需要大量的端口难以维护，多了一层NAT，请求量大会对性能有影响；LoadBlancer 需要每个 Service 都有一个外部负载均衡器。接着 Kubernetes 提供了一个内置的资源对象 Ingress API 来暴露 HTTP 服务给外部用户，它的创建是为了标准化的将 Kubernetes 中的服务流量暴露给外部，Ingress API 通过引入路由功能，克服了默认服务类型 NodePort 和 LoadBalancer 的限制。在创建 Ingress 资源的时候通过 IngressClass 指定该网关使用的控制器，主要是靠 Ingress 控制器不断监听 Kubernetes API Server 中 IngressClass 以及 Ingress 资源的的变动，配置或更新入口网关和路由规则。IngressClass实现了网关与后台的解耦，但也有着很多的局限性。Ingress 配置过于简单，只支持 http 和 https 协议的服务路由和负载均衡，缺乏对其他协议和定制化需求的支持，而且 http 路由只支持 host 和 path 的匹配，对于高级路由只能通过注解来实现，当然这取决于 Ingress 控制器的实现方式，不同的 Ingress 控制器使用不同的注解，来扩展功能，使用注解对于 Ingress 的可用性大打折扣；路由无法共享一个命名空间的网关，不够灵活；网关的创建和管理的权限没有划分界限，开发需要配置路由以及网关。当然也有很多第三方的网关组件，例如 istio 和 apisix 等，提供了丰富的流量管理功能，如负载均衡、动态路由、动态 upstream、A/B测试、金丝雀发布、限速、熔断、防御恶意攻击、认证、监控指标、服务可观测性、服务治理等，还可以处理南北流量以及服务之间的东西向流量。对外提供路由功能，对内提供流量筛选，已经很好的满足了当下网络环境的所有需求。但对于小集群来说，这两个网关的部署成本有点高；而且太多类型的网关，不同的配置项、独立的开发接口、接口的兼容性、学习成本、使用成本、维护成本以及迁移成本都很高。急需一种兼容所有厂商 API 的接口网关。所以应运而生，Kubernetes 推出了 Gateway API。Gateway API 是 Kubernetes 1.19 版本引入的一种新的 API 规范，会成为 Ingress 的下一代替代方案。它有着 Ingress 的所有功能，且提供更丰富的功能，它支持更多的路由类型选择，除了 http路由外，还支持 tcp 以及 grpc 路由类型；它通过角色划分将各层规则配置关注点分离，实现规则配置上的解耦；并提供跨 namespace 的路由与网关支持使其更适应多云环境等。与 Ingress Api 工作类似的，Gateway Controller 会持续监视 Kubernetes API Server 中的 GatewayClass 和 Gateway 对象的变动，根据集群运维的配置来创建或更新其对应的网关和路由。API 网关、入口控制器和服务网格的核心都是一种代理，目的在于内外部服务通信。更多的功能并不等于更好的工具，尤其是在 Kubernetes 中，工具的复杂性可能是一个杀手。
Istio 1.0版本只支持在单个网络，即Mesh中的服务只能连接在一个网络上。虽然在架构设计上是开放的，但从目前的代码来看，Istio的内部实现还是和Kubernetes高度集成的。由于Kubernetes集群中Pod缺省只支持一个网络接口，因此Istio也存在该限制并不让人意外。
之前的 Service Entry 一文中讲到了 ServiceEntry 对象，让网格内部的应用在访问外部应用时，可以使用 VirtualService 进行部分控制。但是如果我们进一步尝试策略的话，会发现常用的 Denier 等适配器都是无效的（这点并没有经过官方验证）。这里就需要使用刚才说的 Egress Gateway 了。
在K8S上部署的微服务，经常会依赖不受你控制的其他微服务。当两者之间的HTTP交互出现延迟或错误后，你的微服务能否按预期正常工作？应该做一个故障注入实验来检验一下。如果在K8S上使用了Istio，那么恭喜你，你已经拥有了简单易用的混沌工程开源工具。
作为云原生服务网格领域的热门开源项目，Istio 可以为微服务提供无侵入的流量管理、安全通信、服务可见性等服务治理能力。目前越来越多的微服务项目开始考虑将自己的微服务基础设施向 Istio 进行迁移。
前面我们了解了 Gateway 和 VirtualService 资源对象的作用，以及它们是如何影响 Envoy 的配置的，那么这些资源对象又是如何影响流量的呢？通过 Istio 如何实现流量管理的呢？
2013 年容器技术 Docker 开源，2014 年容器编排工具 Kubernetes 开源。2015 年，云原生计算基金会（CNCF）成立，标志着应用进入云原生时代， 2016 年 9 月 14 日，Envoy 的开源标志着应用技术架构进入到服务网格（Service Mesh）时代，2017 年 5 月 24 日，Google、IBM、Lyft 共同宣布 Istio 开源标志着进入由控制面和数据面组成的服务网格成为主流。Istio 是当前最受欢迎的服务网格技术。
作者赵化冰，腾讯云高级工程师，Istio Member，ServiceMesher管理委员，热衷于开源、网络和云计算。目前主要从事服务网格的开源和研发工作。 目录 Istio 服务模型 Pilot 服务模型源码分析 第三方服务注册表集成 Consul 集成 其他服务注册表的集成 小结 参考文档 作为云原生服务网格领域的热门开源项目，Istio 可以为微服务提供无侵入的流量管理、安全通信、服务可见性等服务治理能力。目前越来越多的微服务项目开始考虑将自己的微服务基础设施向 Istio 进行迁移。 Is
今天的文章继续聊聊有关Service Mesh微服务架构的话题，如果对之前的聊过的话题还不了解，可以参考文末的推荐阅读。今天要聊的话题是：如何在Service Mesh微服务架构中实现“金丝雀发布”？
原文地址：https://dzone.com/articles/microservices-traffic-management-using-istio-on-ku
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
