Envoy

微软近期开源了一个新的名为 Open Service Mesh [1] 的项目并准备 捐赠给 CNCF [2] 。 基本介绍  Open Service Mesh (OSM) is a lightweight, extensible, Cloud Native service mesh that allows users to uniformly manage, secure, and get out-of-the-box observability features for highly dynamic microservice environments. ” Open Service Mesh（OSM）是一个轻量级，可扩展的云原生服务网格，它使用户能够统一管理，保护和获得针对高度动态微服务环境的开箱即用的可观察性功能。 OSM 在 Kubernetes 上运行基于 Envoy 的控制平面，可以使用 SMI API 进行配置。它通过以 sidecar 的形式注入 Envoy 代理来工作。 控制面负责持续配置代理，以配置策略和路由规则等都保持最新。代理主要负责执行访问控制的规则，路由控制，采集 metrics 等。（这和目前我们常见到的 Service Mesh 方案基本都一样的） 显著特性 基于 Service Mesh Interface (SMI) 的实现，主要包括

KubeCon+CloudNativeCon，作为由云原生计算基金会（CNCF）发起的最盛大的会议，聚焦着全世界关注云原生领域的目光。 自2016年起，在欧洲、北美等地举办以来，本论坛受到了Kubernetes大牛、开发者、厂商等全球开源技术爱好者的强力追捧。 2018年11月13-15日，KubeCon+CloudNativeCon 2018论坛将首次亮相中国上海，这无疑是对中国技术实力的认可，同时，中国程序员们也将可以在上海跨国采购会展中心共同参与这场顶尖的国际技术盛会。 KubeCon+CloudNativeCon 2018中国论坛作为CNCF的旗舰论坛，得到了Liz Rice、Janet Kuo等大咖的大力支持与推荐。本论坛精彩日程现已出炉，看看你关注的议题和大咖！ 本次论坛为期三天，预计将吸引开发人员、架构师、技术负责人、首席信息官、首席技术官、媒体和分析师等2500多人到场，以主题演讲、分论坛以及展位等形式全方位地为大家打造一场精彩绝伦的技术盛宴。 KubeCon+CloudNativeCon 2018中国论坛将聚焦云原生领域的最新技术动态，CNCF的重点项目Kubernetes、Prometheus、OpenTracing、Fluentd、gRPC、containerd、rkt、CNI、Envoy、Jaeger、Helm等多个项目也将悉数亮相。另外

根据CNCF的最新年度调查，很多组织对Service Mesh表现出很高的兴趣，并且有一部分已经在生产环境中使用它们。你可能不知道Linkerd是市场上第一个Service Mesh，但是Istio使Service Mesh更受欢迎。这两个项目都是最前沿的项目，而且竞争非常激烈，因此很难选择一个项目。 在本篇文章中，我们将和你一起了解Istio和Linkerd架构，组件，并比较它们的产品以帮助你做出明智的决定。 Service Mesh简介 在过去的几年中，微服务架构已成为软件设计中流行的样式。在这种架构中，我们将应用程序分解为可独立部署的服务。这些服务通常是轻量级的，多语言的，并且通常由各种职能团队进行开发部署。 当某些服务数量增加，难以管理且越来越复杂时，微服务架构将一直有效。但这也在管理安全性，网络流量控制和可观察性等各个方面带来了挑战。 Service Mesh可以很好地帮助应对这些挑战。 Service Mesh 用于描述组成应用程序的微服务及其之间的交互。随着服务数量的增加和复杂性的增加，扩展和管理变得越来越困难。Service Mesh可以为微服务架构提供服务发现，负载均衡，故障恢复，指标和监视。 Service Mesh 通常还能够满足更复杂的需求，例如A/B测试，金丝雀发布，速率限制，访问控制和端到端身份验证。 Service Mesh

调用链原理和场景 正如Service Mesh的诞生是为了解决大规模分布式服务访问的治理问题，调用链的出现也是为了对应于大规模的复杂的分布式系统运行中碰到的故障定位定界问题。大量的服务调用、跨进程、跨服务器，可能还会跨多个物理机房。无论是服务自身问题还是网络环境的问题导致调用上链路上出现问题都比较复杂，如何定位就比单进程的一个服务打印一个异常栈来找出某个方法要困难的多。需要有一个类似的调用链路的跟踪，经一次请求的逻辑规矩完整的表达出来，可以观察到每个阶段的调用关系，并能看到每个阶段的耗时和调用详细情况。 Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 描述了其中的原理和一般性的机制。模型中包含的术语也很多，理解最主要的两个即可： Trace：一次完整的分布式调用跟踪链路。 Span：跨服务的一次调用； 多个Span组合成一次Trace追踪记录。 上图是Dapper论文中的经典图示，左表示一个分布式调用关系。前端（A），两个中间层（B和C），以及两个后端（D和E）。用户发起一个请求时，先到达前端，再发送两个服务B和C。B直接应答，C服务调用后端D和E交互之后给A应答，A进而返回最终应答。要使用调用链跟踪，就是给每次调用添加TraceId、SpanId这样的跟踪标识和时间戳。 右表示对应Span的管理关系

1. 功能概述 Envoy启动时，会启动一个进程，并在这个进程中启动很多线程，这样，可以启动很多worker线程，一般worker线程数与核心数相同，每个worker线程处理所有已配置的listener上的请求，管理连接并处理filterchain，非阻塞；同时，在这个进程中会启动一个主线程，它负责启动和停止envoy，也是通过API提供配置管理的线程，同时它收集不同的指标，管理其它线程，也是非阻塞的。 2. 重要数据结构定义 2.1 Filter 过滤器，包括listener filter、network filter和http filter。Listener filter可以用于操作连接元数据，在新接收的套接字上进行操作，例如获取原始目的地址，重定向连接等；network filter主要负责数据读写；http filter主要负责数据处理。 2.2 Listener 监听器，envoy中支持在每个线程中配置任意数量的监听器，每个监听器独立配置一定数量的network filter，也可以选择性的配置listener filter，listener filter在连接建立之前处理，network filter在连接建立之后处理。 2.3 Worker 一个worker对应一个envoy的执行线程，将listener绑定在worker上，worker负责监听、过滤和转发

本文将结合一个具体例子中的细节详细描述Istio调用链的原理和使用方式。并基于Istio中埋点的原理解释来说明：为了输出一个质量良好的调用链，业务程序需根据自身特点做适当的修改，即并非官方一直在说的完全无侵入的做各种治理。另外还会描述Istio当前版本中收集调用链数据可以通过Envoy和Mixer两种不同的方式。 Istio一直强调其无侵入的服务治理，服务运行可观察性。即用户完全无需修改代码，就可以通过和业务容器一起部署的proxy来执行服务治理和与性能数据的收集。原文是这样描述的： Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, then configure

作者 | Drew Rothstein 策划 | Tina 当今，Kubernetes 已经成为容器编排领域的领导者。但是在 Coinbase 公司，却没有使用 Kubernetes。这是为什么？运行 Kubernetes 会产生哪些问题？ 本文要点：容器编排平台是一项复杂而令人惊叹的技术，它可以帮助一些企业和团队解决一系列的问题。然而，我们经常忽略的是，容器技术还带来了一系列的挑战，企业只有克服这些挑战才能避免失败。 https://github.com/hjacobs/kubernetes-failure-stories 1 历史 在讨论现状之前，让我们先了解下时至今日这项技术的发展历程。 1980 年代：chroot 1990 年代：jail 2000 年代（早期)：jail > FreeBSD 2000 年代（中期）：cgroups 2000 年代（后期）：LXC（Linux 容器) 2010 年代（早期）：Docker 2010 年代（后期）：Kubernetes 如果想进一步了解其历史，请查阅 Enterprise Docker 第七章。 https://www.oreilly.com/library/view/enterprise-docker/9781491994986/ 让我们从 10 年前说起，那时还没有现如今大家都知道的容器。那个时候，我们没有 / 不使用

1. 引言 在写完 eShopOnContainers 知多少[12]：Envoy gateways 后，就一直想进一步探索Service Mesh，最近刚在极客时间上学完《Service Mesh入门》，又大致浏览了一遍官方文档，对Istio也算有了基本的认识。下面就根据自己的理解对Istio进行简单的梳理，算是对知识的总结吧。 2. Cloud Native（云原生） 在介绍Istio之前，我们得先了解下Service Mesh，而Service Mesh 又是云原生的产物。因此，本着追本溯源的精神，我们得先了解下云原生。云原生（Cloud Native）这个概念是在2015年提出的，听的人多，真正能讲清楚的人少，我也一样。综合多方资料，下面尝试解读一下。 云原生，虽然字都认识，但真不好解释。一般讲云原生，其实是讲云原生应用，多了应用二字，就更具象了。从字面上直译：云，代表云端；原生：原本就生长在那里；连起来就是 「原本就生长在云端的应用」 。 应用怎么会原本就生长在云端呢？云又是怎么发展而来呢？别急，我们先来看下云计算的发展来解答下云的由来。 我们知道传统的应用都是跑在本地服务器上，随着虚拟化技术的发展，拉开了云计算的序幕，一大批云计算厂商基于虚拟机技术，提供了IaaS，PaaS和SaaS等产品形态，极大的提高资源的利用率。企业本着降本增效的目的

1. 引言 在写完 eShopOnContainers 知多少[12]：Envoy gateways 后，就一直想进一步探索Service Mesh，最近刚在极客时间上学完《Service Mesh入门》，又大致浏览了一遍官方文档，对Istio也算有了基本的认识。下面就根据自己的理解对Istio进行简单的梳理，算是对知识的总结吧。 2. Cloud Native（云原生） 在介绍Istio之前，我们得先了解下Service Mesh，而Service Mesh 又是云原生的产物。因此，本着追本溯源的精神，我们得先了解下云原生。云原生（Cloud Native）这个概念是在2015年提出的，听的人多，真正能讲清楚的人少，我也一样。综合多方资料，下面尝试解读一下。 云原生，虽然字都认识，但真不好解释。一般讲云原生，其实是讲云原生应用，多了应用二字，就更具象了。从字面上直译：云，代表云端；原生：原本就生长在那里；连起来就是 「原本就生长在云端的应用」 。 应用怎么会原本就生长在云端呢？云又是怎么发展而来呢？别急，我们先来看下云计算的发展来解答下云的由来。 我们知道传统的应用都是跑在本地服务器上，随着虚拟化技术的发展，拉开了云计算的序幕，一大批云计算厂商基于虚拟机技术，提供了IaaS，PaaS和SaaS等产品形态，极大的提高资源的利用率。企业本着降本增效的目的

很多同学看到这个题目，一定会提这样的问题：RSocket是个协议，Envoy是一个 proxy，Istio是service mesh control plane + data plane。 这三种技术怎么能放在一起比较呢？ 的确，从技术定位的角度来讲，它们确实是有很大的差距。但是，如果我们用RSocket来治理微服务，会有哪些不同呢？ RSocket RSocket是一种应用层协议，不是一个传输层的协议。一方面，它可以包容和支持不同的传输层协议和相关技术，比如tcp 和 proto buf。另一方面，它的重点是把反应流的实现，提升到应用层上来。 其实在底层的协议中，就有反应流的实现，tcp的滑动窗口就是很好的例子。但是往上，这种好的机制不见了，给编程的工作造成很多的麻烦。很大一部分的线上故障是由于阻塞链接造成的。另一方面，很多应用层的网络软件，从设计的时候就开始避免这样的麻烦，造成结构臃肿，通讯效率底下。简单的例子是如果所有的通讯都是反应式的，那就不用熔断了。 基于RSocket 的应用不止是端到端通讯，Broker也是对这个协议水到渠成的应用。作为一个反应式的Broker，它同样是异步，非阻塞的通讯方式，主要维护与就近的各个应用的链接以及和其它Broker的链接。与其它协议相比，它是多路复用，同时支持长链接。 经过这样的解释，不难理解