Istio 中文文档 Istio的源头是微服务。 An open platform to connect, secure, control and observe services. 连接、保护、控制和观测服务(微服务)的开放平台（平台开源）。 连接（Connect）：智能控制服务之间的流量和API调用，进行一些列测试，并通过红/黑部署逐渐升级。 保护（Secure）：通过托管身份验证、授权和服务之间通信加密自动保护服务。 控制（Control）：应用策略并确保其执行使得资源在消费者之间公平分配。 观测（Observe）：通过丰富的自动跟踪、监控和记录所以服务，了解正在发生的情况。 Service Mesh 借着微服务和容器化的东风，传统的代理摇身一变，成了如今炙手可热的 Service Mesh。 有网络访问的地方就会有代理的存在。 代理可以是嵌套的，也就是说通信双方 A、B 中间可以多层代理，而这些代理的存在有可能对 A、B 是透明的。 代理可以为整个通信带来更多的功能，比如： 拦截：选择性拦截传输的网络流量，比如GFW 统计：既然所有的流量都经过代理，那么代理也可以用来统计网络中的数据信息，比如了解哪些人在访问哪些网站，通信的应答延迟等 缓存：如果通信双方比较”远“，访问比较慢，那么代理可以把最近访问的数据缓存在本地，后面的访问不用访问后端来做到加速，比如CDN 分发（负载均衡）：如果某个通信方有多个服务器后端，代理可以根据某些规则来选择如何把流量发送给多个服务器,即负载均衡功能，比如Nginx 跳板：如果 A、B 双方因为某些原因不能直接访问，而代理可以和双方通信，那么通过代理，双方可以绕过原来的限制进行通信,比如翻墙 注入：既然代理可以看到流量，那么也可以修改网络流量，可以自动在收到的流量中添加一些数据，比如有些宽带提供商的弹窗广告 Service Mesh可以看做是传统代理的升级版，用来解决在微服务框架中出现的问题，即可以把Service Mesh看作是分布式的微服务代理。 在传统模式下，代理一般是集中式的单独的服务器，所有的请求都要先通过代理，然后再流入转发到实际的后端。 在 Service Mesh 中，代理变成了分布式的，它常驻在应用的身边。 最常见的就是 Kubernetes Sidecar 模式，每一个应用的 Pod 中都运行着一个代理，负责流量相关的事情。 这样的话，应用所有的流量都被代理接管，那么这个代理就能做到上面提到的所有可能的事情，从而带来无限的想象力。 原来的代理都是基于网络流量的，一般都是工作在 IP 或者 TCP 层，很少关心具体的应用逻辑。 在 Service Mesh 中，代理知道整个集群的所有应用信息，并且额外添加了: 热更新、 注入服务发现、 降级熔断、 认证授权、 超时重试、 日志监控等功能 让这些通用的功能不必每个应用都自己实现，放在代理中即可。Service Mesh 中的代理对微服务中的应用做了定制化的改进！ 应用微服务之后，每个单独的微服务都会有很多副本，而且可能会有多个版本，这么多微服务之间的相互调用和管理非常复杂，但是有了 Service Mesh，我们可以把这块内容统一在代理层。 如何对这些分布式代理进行统一的管理？手动更新每个代理的配置，对代理进行升级或者维护是不可持续的事情，需要一个控制中心。 管理员只需要根据控制中心的API来配置整个集群的应用流量，安全规则即可，代理会自动和控制中心打交道根据用户的期望改变自己的行为。 可以理解 Service Mesh 中的代理会抢了 Nginx 的生意，这也是为了 Nginx 也要开始做 NginMesh 的原因。 Istio Istio 就是我们上述提到的 Service Mesh 架构的一种实现，服务之间的通信（比如这里的 Service A 访问 Service B）会通过代理（默认是 Envoy）来进行。 而且中间的网络协议支持 HTTP/1.1，HTTP/2，gRPC 或者 TCP，可以说覆盖了主流的通信协议。 控制中心做了进一步的细分，分成了 Pilot、Mixer 和 Citadel，它们的各自功能如下： Pilot：为 Envoy 提供了服务发现，流量管理和智能路由（AB 测试、金丝雀发布等），以及错误处理（超时、重试、熔断）功能。 用户通过 Pilot 的 API 管理网络相关的资源对象，Pilot 会根据用户的配置和服务的信息把网络流量管理变成 Envoy 能识别的格式分发到各个 Sidecar 代理中。 Mixer：为整个集群执行访问控制（哪些用户可以访问哪些服务）和 Policy 管理（Rate Limit，Quota 等），并且收集代理观察到的服务之间的流量统计数据。 Citadel：为服务之间提供认证和证书管理，可以让服务自动升级成 TLS 协议。 代理会和控制中心通信，一方面可以获取需要的服务之间的信息，另一方面也可以汇报服务调用的 Metrics 数据。 Istio解决的问题 单个应用拆分成了许多分散的微服务，它们之间相互调用才能完成一个任务，而一旦某个过程出错（组件越多，出错的概率也就越大），就非常难以排查。 用户请求出现问题无外乎两个问题：错误和响应慢。 故障排查 应用容错性 应用升级发布 系统安全 用什么姿势接入 Istio 虽然 Istio 能解决那么多的问题，但是引入 Istio 并不是没有代价的。最大的问题是 Istio 的复杂性，强大的功能也意味着 Istio 的概念和组件非常多，要想理解和掌握 Istio ，并成功在生产环境中部署需要非常详细的规划。 一般情况下，集群管理团队需要对 Kubernetes 非常熟悉，了解常用的使用模式，然后采用逐步演进的方式把 Istio 的功能分批掌控下来。 第一步，自然是在测试环境搭建一套 Istio 的集群，理解所有的核心概念和组件。 了解 Istio 提供的接口和资源，知道它们的用处，思考如何应用到自己的场景中，然后是熟悉 Istio 的源代码，跟进社区的 Issues，了解目前还存在的 Issues 和 Bug，思考如何规避或者修复。 这一步是基础，需要积累到 Istio 安装部署、核心概念、功能和缺陷相关的知识，为后面做好准备。 第二步，可以考虑接入 Istio 的观察性功能，包括 Logging、Tracing、Metrics 数据。 应用部署到集群中，选择性地（一般是流量比较小，影响范围不大的应用）为一些应用开启 Istio 自动注入功能，接管应用的流量，并安装 Prometheus 和 Zipkin 等监控组件，收集系统所有的监控数据。 这一步可以试探性地了解 Istio 对应用的性能影响，同时建立服务的性能测试基准，发现服务的性能瓶颈，帮助快速定位应用可能出现的问题。 此时，这些功能可以是对应用开发者透明的，只需要集群管理员感知，这样可以减少可能带来的风险。 第三步，为应用配置 Time Out 超时参数、自动重试、熔断和降级等功能，增加服务的容错性。 这样可以避免某些应用错误进行这些配置导致问题的出现，这一步完成后需要通知所有的应用开发者删除掉在应用代码中对应的处理逻辑。这一步需要开发者和集群管理员同时参与。 第四步，和 Ingress、Helm、应用上架等相关组件和流程对接，使用 Istio 接管应用的升级发布流程。 让开发者可以配置应用灰度发布升级的策略，支持应用的蓝绿发布、金丝雀发布以及 AB 测试。 第五步，接入安全功能。配置应用的 TLS 互信，添加 RBAC 授权，设置应用的流量限制，提升整个集群的安全性。 因为安全的问题配置比较繁琐，而且优先级一般会比功能性相关的特性要低，所以这里放在了最后。 当然这个步骤只是一个参考，每个公司需要根据自己的情况、人力、时间和节奏来调整，找到适合自己的方案。 总结 Istio 的架构在数据中心和集群管理中非常常见，每个 Agent 分布在各个节点上（可以是服务器、虚拟机、Pod、容器）负责接收指令并执行，以及汇报信息。 控制中心负责汇聚整个集群的信息，并提供 API 让用户对集群进行管理。 Kubernetes 也是类似的架构，SDN（Software Defined Network） 也是如此。 相信以后会有更多类似架构的出现，这是因为数据中心要管理的节点越来越多，我们需要把任务执行分布到各节点（Agent 负责的功能）。 同时也需要对整个集群进行管理和控制（Control Plane 的功能），完全去中心化的架构是无法满足后面这个要求的。 Istio 的出现为负责的微服务架构减轻了很多的负担，开发者不用关心服务调用的超时、重试、Rate Limit 的实现，服务之间的安全、授权也自动得到了保证。 集群管理员也能够很方便地发布应用（AB 测试和灰度发布），并且能清楚看到整个集群的运行情况。 但是这并不表明有了 Istio 就可以高枕无忧了，Istio 只是把原来分散在应用内部的复杂性统一抽象出来放到了统一的地方，并没有让原来的复杂消失不见。 因此我们需要维护 Istio 整个集群，而 Istio 的架构比较复杂，尤其是它一般还需要架在 Kubernetes 之上，这两个系统都比较复杂，而且它们的稳定性和性能会影响到整个集群。 因此再采用 Isito 之前，必须做好清楚的规划，权衡它带来的好处是否远大于额外维护它的花费，需要有相关的人才对整个网络、Kubernetes 和 Istio 都比较了解才行。
Service Mesh的概念 Service Mesh 是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，Service Mesh 保证请求可以在这些拓扑中可靠地穿梭。 在实际应用当中，Service Mesh通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但应用程序不需要知道它们的存 在。 关于这个定义有以下两个值得我们关注的核心点： Service Mesh是一个专门负责请求可靠传输的基础设施层； Service Mesh的实现为一组同应用部署在一起并且对应用透明的轻量网络代理。 随着云原生应用的崛起，Service Mesh逐渐成为一个独立的基础设施层。在云原生模型里： 一个应用可以由数百个服务组成， 每个服务可能有数千个实例， 而每个实例可能会持续地发生变化。 服务间通信不仅异常复杂，而且也是运行时行为的基础。管理好服务间通信对于保证端到端的性能和可靠性来说是非常重要的。 服务治理 和 请求可靠传输就是Service Mesh这个基础设施层的职能边界。 Service Mesh 解决了微服务架构的哪些问题？ 服务化架构演进 大一统的单体服务 为了保证项目能快速成型并上线，起初的应用可能是一个大一统的单体服务，所有业务逻辑、数据 层依赖等都在一个项目中完成。 好处：开发独立、快速，利用资源合理，服务调用更直接、性能更高等等。 缺点：最致命的问题就是耦合，而且随着业务的不断堆叠这种耦合会越来越严重，项目越来越臃肿。 模块化 下一步通常都会往模块化的服务演进，比如 ++MVC 模式++的使用、++RPC 技术++的引入等，主要解决业务或者功能模块之间耦合的问题。 SOA 随着业务量的增长和组织的扩大，性能和扩展性将是不得不面对的大问题，所以通常会按照SOA的思路进行++面向服务的体系结构拆分++。 微服务 随着云化技术的发展，容器技术的普及，考虑到集群的弹性运维以及业务运营维护成本、业务运营演进效率等问题，微服务架构就显得更贴近现实。 微服务对比之前的各种传统架构模式的好处： 降低了单体服务的复杂性， 随即提升了开发速度， 而且代码更容易理解和维护， 开发团队对技术的选择变得更自由， 每个微服务都独立部署所以能很方便调配部署的方式及规模等等。 尤其是一些新兴的互联网公司，创业初期基于运营成本考虑可能都不会去自建机房、买服务器上架，而是直接走云原生应用的路子，这样既能节省成本又能高质高效地应对快速增长的用户。 但也要考虑这个问题，随着微服务化的逐步发展和细化（这里我们暂且不考虑微服务拆分的问题，因为拆分的粒度往往没有规范可依，我个人认为适合自己的才是最好的，当然更不考虑拆分维度或者康威定律），越来越多微服务，每个微服务部署成倍数以上的微服务实例，这些实例数可能轻轻松松就会达到成百上千个，++各服务间的依赖变成复杂的网状拓扑结构++。 传统基于DNS和中心化的Server端负载均衡来实现服务依赖和治理的形式。 基于注册中心和一个去中心化的Client端负载均衡来实现服务注册发现和治理。 微服务则是复杂的分布式应用，不管是部署形式还是服务的发现、服务依赖调用和请求传输等问题都变得非常难以处理。因为整个体系有太多的不稳定因素，比如网络的分区可能导致服务得不到有效治理。 这里的重点就是要面对微服务架构下服务的治理与请求的可靠传输等问题，这就是为什么需要有 Service Mesh这样的一个基础设施层来对应用透明化地解决这些问题。 下一代微服务Service Mesh 随着云计算技术的成熟和普及以及容器技术的大量应用，为了更快地交付、降低试错风险、更快地拓展业务，云原生应用将会是未来服务演进的方向。与Kubernets 类似的容器调度编排技术的不断成熟，使得容器作为微服务的最小部署单元，这更有利于发挥微服务架构的巨大优势。并且在ServiceMesh方向上不断涌现的各种优秀的项目比如 istio 和 Conduit（Conduit 目前仅支持 Kubernets 平台）的出现补足了 Kubernetes 等平台在微 服务间服务通讯上的短板。 更关键的是，这些优秀项目的背后不乏 Google、IBM 等大公司背书，所以很容易相信未来微服务 架构将围绕 Kubernetes 等容器生态来展开，这也就不难得出 Service Mesh 将是下一代微服务这样的结论。 技术支撑着业务高歌猛进，业务增长反过来又驱动着技术不断向前演化，这是每个互联网公司发展 过程中不变的旋律。 从 2009 年上线至今，微博架构经历了从最初的单体应用到后面的 RPC 服务化、容器化、混合云架构以及现在的跨语言服务化和 Service Mesh等诸多阶段，架构演变支撑着微博业务的一次次华丽转身，也见证了微博的飞速成长。 在业务发展的每个阶段，面临的问题都不尽相同，而问题又有各种优先级，++难免为了解决某些较为迫切的问题而引入一些当时不Care的问题++，这也是日常架构演化过程中难以避免的魔咒。 鱼和熊掌不可兼得，所以架构演化的真谛就在于各种方案评估中的利弊权衡，在以业务为重的前提下进行正向演化。 事实标准 Service Mesh 通过在 传输层 和 应用层 间抽象出与业务无关、甚至是对其透明、公共基础的一层解决了微服务间 连接、流量控制、服务治理 和 监控、遥测 等问题。 社区对这个边界的认知是基本一致的。不管是Istio、Conduit，还是华为的ServiceComb、微博的WeiboMesh，实现方案中都有 数据面板 和 控制面板 这样的概念，这已经形成了 Service Mesh 的事实规范。 数据面板主要以 SideCar 模式与 Service 部署在一起，保障请求数据在Service间进行可靠传输，提供服务治理以及对请求状态数据的提取与检测等。 控制面板主要控制服务间流量流向、请求路由，提供一种对数据面板访问策略实施的干预机制以及对服务依赖、服务状态的监控等功能。