Envoy

敖小剑，蚂蚁金服高级技术专家，十七年软件开发经验，微服务专家，Service Mesh 布道师，ServiceMesher 社区联合创始人。 本文内容整理自 8 月 11 日 Service Mesher Meetup 广州站主题演讲，完整的分享 PPT 获取方式见文章底部。 前言 标题“Service Mesh发展趋势(续)”中的“续”是指在今年5月底，我在 CloudNative Meetup上做了一个“ Service Mesh发展趋势：云原生中流砥柱 ”的演讲，当时主要讲了三块内容：Service Mesh 产品动态、发展趋势、与云原生的关系。后来有同学反应希望部分感兴趣的内容能讲的更深一些，所以今天将继续“Service Mesh 发展趋势”这个话题。 今天给大家分享的内容有部分是上次演讲内容的深度展开，如社区关心的 Mixer v2 以及最近看到的一些业界新的技术方向，如 web assembly 技术，还有产品形态上的创新，如 google traffic director 对 Service Mesh 的虚拟机形态的创新支持。 在 Service Mesh 出道四年之际，也希望和大家一起带着问题来对 Service Mesh 未来的发展进行一些深度思考。 在正式开始分享之前，让我们先轻松一下，下面是最近流行的梗，各种灵魂拷问： 我们今天的分享内容，将效仿上面的方式

流量治理是一个非常宽泛的话题，例如： 动态修改服务间访问的负载均衡策略，比如根据某个请求特征做会话保持； 同一个服务有两个版本在线，将一部分流量切到某个版本上； 对服务进行保护，例如限制并发连接数、限制请求数、隔离故障服务实例等； 动态修改服务中的内容，或者模拟一个服务运行故障等。 在Istio中实现这些服务治理功能时无须修改任何应用的代码。较之微服务的SDK方式，Istio以一种更轻便、透明的方式向用户提供了这些功能。用户可以用自己喜欢的任意语言和框架进行开发，专注于自己的业务，完全不用嵌入任何治理逻辑。只要应用运行在Istio的基础设施上，就可以使用这些治理能力。 一句话总结Istio流量治理的目标：以基础设施的方式提供给用户非侵入的流量治理能力，用户只需关注自己的业务逻辑开发，无须关注服务访问管理。 Istio流量治理的概要流程如图1所示： 图1 Istio流量治理的概要流程 在控制面会经过如下流程： （1）管理员通过命令行或者API创建流量规则； （2）Pilot将流量规则转换为Envoy的标准格式； （3）Pilot将规则下发给Envoy。 在数据面会经过如下流程： （1）Envoy拦截Pod上本地容器的Inbound流量和Outbound流量； （2）在流量经过Envoy时执行对应的流量规则，对流量进行治理。 负载均衡

上回书说到后端架构发展历程，还回顾完云计算的历史 本回将继续梳理云原生实现方案 Service Mesh 的发展历程，介绍 Service Mesh 的代表 Istio 的亮眼功能。 什么是原生 Native 在回顾完云计算的历史之后，我们对 Cloud 有更深的认识，接着继续看一下：什么是 Native？ 字典的解释是：与生俱来的。 那 Cloud 和 native 和在一起，又该如何理解？ 这里我们抛出一个我们自己的理解：云原生代表着原生为云设计。 详细的解释是：应用原生被设计为在云上以最佳方式运行，充分发挥云的优势。 这个理解有点空泛，但是考虑到云原生的定义和特征在这些年间不停的变化，以及完全可以预料到的在未来的必然变化，我们觉得，对云原生的理解似乎也只能回到云原生的出发点，而不是如何具体实现。 Cloud Native 是道，Service Mesh 是术 那在这么一个云原生理解的背景下，我们再来介绍一下对云原生应用的设想，也就是云原生应用应该是什么样子。 在云原生之前，底层平台负责向上提供基本运行资源。而应用需要满足业务需求和非业务需求，为了更好的代码复用，通用型好的非业务需求的实现往往会以类库和开发框架的方式提供，另外在 SOA/ 微服务时代部分功能会以后端服务的方式存在，这样在应用中就被简化为对其客户端的调用代码。 然后应用将这些功能，连同自身的业务实现代码，一起打包

> 原文链接： Istio 1.3 发布，HTTP 遥测不再需要 Mixer Istio 是 Google、IBM 和 Lyft 联合开源的服务网格（Service Mesh）框架，旨在解决大量微服务的发现、连接、管理、监控以及安全等问题。 Istio 对应用是透明的，不需要改动任何服务代码就可以实现透明的服务治理。 1.3 版本已经发布，距离上一个重要版本 1.2 发布已过去两个多月，我们来看看有哪些修改内容。 1. 智能协议检测 在之前的版本中，如果要使用 Istio 的路由功能， Service 的端口命名必须使用特殊的命名格式。如果用户不遵循该命名规则，就无法使用路由功能。从 1.3 版本开始，即使没有按照规则命名 Service 的端口，Istio 也会自动识别出站流量的协议为 HTTP 或 TCP 。目前还不支持自动识别入站流量的协议，下个版本将会支持。 2. 无 Mixer 的遥测功能（实验性） 这才是大家最期待的！该版本将大多数常见的安全策略相关的功能（如 RBAC）直接迁移到了 Envoy 中，同时也将大部分遥测功能迁移到了 Envoy 中。现在 Istio proxy 可以直接将收集到的 HTTP 指标暴露给 Prometheus ，无需通过 istio-telemetry 服务来中转并丰富指标信息。如果你只关心 HTTP 服务的遥测，可以试试这个新功能

Istio is the future！基本上，我相信对云原生技术趋势有些微判断的同学，都会有这个觉悟。其背后的逻辑其实是比较简单的：当容器集群，特别是K8S成为事实上的标准之后，应用必然会不断的复杂化，服务治理肯定会成为强需求。 Istio的现状是，聊的人很多，用的人其实很少。所以导致我们能看到的文章，讲道理的很多，讲实际踩坑经验的极少。 阿里云售后团队作为一线踩坑团队，分享问题排查经验，我们责无旁贷。这篇文章，我就跟大家聊一个简单Istio问题的排查过程，权当抛砖。 二分之一活的微服务 问题是这样的，用户在自己的测试集群里安装了Istio，并依照官方文档部署bookinfo应用来上手Istio。部署之后，用户执行kubectl get pods命令，发现所有的pods都只有二分之一个容器是READY的。 # kubectl get pods NAME READY STATUS RESTARTS AGE details-v1-68868454f5-94hzd 1/2 Running 0 1m productpage-v1-5cb458d74f-28nlz 1/2 Running 0 1m ratings-v1-76f4c9765f-gjjsc 1/2 Running 0 1m reviews-v1-56f6855586-dplsf 1/2 Running 0 1m reviews

> 原文链接： Contour 学习笔记（一）：使用 Contour 接管 Kubernetes 的南北流量 在 Kubernetes 中运行大规模以 Web 为中心的工作负载，最关键的需求之一就是在 L7 层实现高效流畅的入口流量管理。自从第一批 Kubernetes Ingress Controller 开发完成以来， Envoy （由 Matt Klein 和 Lyft 团队开发）已经成为云原生生态系统中的新生力量。Envoy 之所以受到支持，因为它是一个 CNCF 托管的项目，与整个容器圈和云原生架构有着天然的支持。 容器公司 Heptio 开源的项目 Contour 使用 Envoy 作为 Kubernetes 的 Ingress Controller 实现，为大家提供了一条新的 Kubernetes 外部负载均衡实现思路。 据 官方博客 介绍， Heptio Contour 可以为用户提供以下好处： 一种简单的安装机制来快速部署和集成 Envoy。 与 Kubernetes 对象模型的集成。 Ingress 配置的动态更新，而无需重启底层负载均衡器。 项目成熟后，将允许使用 Envoy 一些强大的功能，如熔断器、插件式的处理器链，以及可观测性和可调试性，可以非常方便地对接监控系统。 IngressRoute 之间可以级联，用来做蓝绿部署非常方便。 下面我们就来试用一下。

> 原文链接： Contour 学习笔记（一）：使用 Contour 接管 Kubernetes 的南北流量 在 Kubernetes 中运行大规模以 Web 为中心的工作负载，最关键的需求之一就是在 L7 层实现高效流畅的入口流量管理。自从第一批 Kubernetes Ingress Controller 开发完成以来， Envoy （由 Matt Klein 和 Lyft 团队开发）已经成为云原生生态系统中的新生力量。Envoy 之所以受到支持，因为它是一个 CNCF 托管的项目，与整个容器圈和云原生架构有着天然的支持。 容器公司 Heptio 开源的项目 Contour 使用 Envoy 作为 Kubernetes 的 Ingress Controller 实现，为大家提供了一条新的 Kubernetes 外部负载均衡实现思路。 据 官方博客 介绍， Heptio Contour 可以为用户提供以下好处： 一种简单的安装机制来快速部署和集成 Envoy。 与 Kubernetes 对象模型的集成。 Ingress 配置的动态更新，而无需重启底层负载均衡器。 项目成熟后，将允许使用 Envoy 一些强大的功能，如熔断器、插件式的处理器链，以及可观测性和可调试性，可以非常方便地对接监控系统。 IngressRoute 之间可以级联，用来做蓝绿部署非常方便。 下面我们就来试用一下。

在云原生技术全面爆发之前，我们开发的应用可以被称为非云原生应用，非云原生应用并没有考虑到应用的弹性和规模性，甚至很多都不具备扩展性，当业务规模扩大时，特别依赖硬件的升级，进而带来了很多问题。云原生的出现带来了新的开发方式，然而这一技术处于快速的发展过程中，导致很难定义清楚各类概念和理解各种技术名词。 为此，Infoq专门采访了京东云中间件团队负责人李道兵，了解京东云在云原生领域的理念和相关探索，以期对开发者有所帮助。以下为本次采访的整编内容。 如今，企业很难在聊云原生这个话题时避开容器，但是往回倒四年，容器在国内的应用并不普遍，大多集中在技术实力较强的互联网大厂，但也并非后来大火的 Docker，当时的不少文章还将这群早期实践者称作“敢于吃螃蟹的人”。显然，在云原生领域，容器的发展是推动其落地的重要条件，但最大的需求并不是为了使用容器，这个逻辑本身就很奇怪，为了出现而出现的技术往往不会有好的结局，容器所解决的问题才是组织或开发者最大的需求。那么，组织现阶段对云原生实践最大的需求是什么呢？ 过去几个月，InfoQ 先后就云原生这一话题采访了阿里巴巴、腾讯、青云、居然之家、华为等众多厂商，对值得关注的开源技术及相关落地实践进行了初步探索。本文，InfoQ 对京东云中间件产品研发部高级总监李道兵进行了独家专访，了解京东云在云原生领域的理念和相关探索。 云原生理念 关于云原生

微服务的概念已经在各大公司实践开了，以Java为代表的spring boot成为了微服务的代表，K8S+Docker成为了微服务运行的最佳环境，微服务的概念已经离我们没有那么遥远了。 当然微服务是复杂的，除了组件繁多还需要代码做出很多改造才能享受到它带来的优势，那么有没有一种方式可以不需要太多代码改动就能够在多种不同的开发语言中灵活使用呢? 基于服务网格Istio就诞生了,拨云见日我们今天就来一同学习了解微服务和Istio相关的知识. 附上: 喵了个咪的博客: w-blog.cn Istio官方地址: https://preliminary.istio.io/zh Istio中文文档: https://preliminary.istio.io/zh/docs/ PS : 此处基于当前最新istio版本1.0.3版本进行搭建和演示，不同的版本各种细节会有些许不同！ 一. 微服务 在开始讲解Istio之前我们需要先了解微服务的概念，以及在微服务管理中常常需要使用到的一些列的组件： 服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。 服务发现：服务调用方从服务注册中心找到自己需要调用的服务的地址。 负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。 服务网关

敖小剑，蚂蚁金服高级技术专家，十七年软件开发经验，微服务专家，Service Mesh 布道师，ServiceMesher 社区联合创始人。 本文内容整理自 8 月 11 日 Service Mesher Meetup 广州站主题演讲，完整的分享 PPT 获取方式见文章底部。 前言 标题“Service Mesh发展趋势(续)”中的“续”是指在今年5月底，我在 CloudNative Meetup上做了一个“ Service Mesh发展趋势：云原生中流砥柱 ”的演讲，当时主要讲了三块内容：Service Mesh 产品动态、发展趋势、与云原生的关系。后来有同学反应希望部分感兴趣的内容能讲的更深一些，所以今天将继续“Service Mesh 发展趋势”这个话题。 今天给大家分享的内容有部分是上次演讲内容的深度展开，如社区关心的 Mixer v2 以及最近看到的一些业界新的技术方向，如 web assembly 技术，还有产品形态上的创新，如 google traffic director 对 Service Mesh 的虚拟机形态的创新支持。 在 Service Mesh 出道四年之际，也希望和大家一起带着问题来对 Service Mesh 未来的发展进行一些深度思考。 在正式开始分享之前，让我们先轻松一下，下面是最近流行的梗，各种灵魂拷问： 我们今天的分享内容，将效仿上面的方式