Istio进入1.7版本，Service Mesh 落地还有什么障碍？

2017 年，Google 联合 IBM、Lyft 推出了 Istio，因为有 K8s 的成功经验在先，Istio 一出生就引人注目，其受到的关注度甚至远超最早提出服务网格概念的 Linkerd。只要有关注度，就有溢价存在，业界为 Istio 买账更像是买一种预期，认为 Istio 能像 K8s 一样，快速成为服务网格领域的事实标准。

当然，除了独特的出身优势，Istio 自身也品质过硬，有着非常漂亮的架构设计，着重解决了微服务间通信的连接、保护、观测、治理等问题。此外，Istio 将 Envoy 作为标准数据面组件，借力 Envoy 社区确定了数据面方向的竞争优势。Envoy 是基于 C++ 开发的 L4/L7 高性能代理，在功能、性能、扩展性、可观测性等方面表现出色，是云原生时代服务代理的最佳选择。Istio 和 Envoy 所代表的技术栈可以说是服务网格（Service Mesh）技术中影响力最大的，虽然持续也有一些关于 Istio 开放性的质疑，我们相信这个社区会朝着一个开放、健康的方向发展。

Istio 的架构演变

自 1.5 版本开始，Istio 的架构迭代回归务实。此后的相继推出的 1.6、1.7 版本也持续往简化、易用方向演进。

从设计之初，Istio 就遵循良好的架构设计模式，有清晰的控制面和数据面边界，其中控制面又由 Pilot、Citadel、Mixer、istio-sidecar-injector 等核心微服务组成，这些服务被设计单一职责，每个服务看似都有不可或缺的存在理由。但经过了近 3 年的社区发展和企业实践，Istio 在企业里大规模落地并不顺利，这导致其在易用性、可运维性、性能等方面受到了一些质疑，这些质疑声认为 Istio 看似漂亮的微服务化设计有过渡设计之嫌。

举几个简单的例子，比如我们轻舟服务网格（基于 Istio）在实际生产支撑过程中，控制面的多个服务通常会作为一个整体并由一个团队开发或运维，这会让微服务倡导的“2-pizza”规模团队独立负责单一服务失去优势，因为 Istio 控制面服务由多个团队来负责并无管理的便利；再比如控制面组件的主要资源消耗在 Pilot 的 xDS serving 上，其他组件的损耗相比 Pilot 微乎其微，这意味着控制面组件不用考虑独立的可伸缩性。

基于此，Istio 社区从 1.5 版本开始做出的最大的架构调整就是把控制面组件合并为一个 istiod 单体应用，牺牲掉 istio 控制面并不刚需的微服务特性以此换来单体应用的易用性和可运维性。这是一次非常务实的架构演进。

我们分析，驱动 Istio 进行这样架构演进的原因是面临服务网格标准化的竞争。Istio 由 Google 联合 IBM、Lyft 推出，与 K8s 可以说是同源的，有 K8s 在容器编排标准化方面取得的巨大成功经验在前，Istio 一经推出就受到了业界极大的关注，在 Istio 1.0 版本还没发布的时候就有声音认为它是服务网格的事实标准。但是开源软件的最大生命力来源是给用户带来价值，换句话说是 Istio 想要成为标准必须要有大量的生产环境实践案例来支撑。在这一点上 Istio 与 K8s 有很大不同，K8s 设计理念和架构都来自 Google 内部稳定运行了 10 多年的大规模容器集群管理系统 Borg，有 Borg 的背书，K8s 成为容器编排标准化几乎没有太大阻力。于是过去 5 年成为了 K8s 发展最快的 5 年，至今基本上已经成熟，而 Istio 在这方面优势并不明显。Istio 在市场上有较多的竞争者，比如 AWS 上的 App Mesh，Buoyant 推出的 Linkerd，Kong 推出的 Kuma，HashiCorp 推出的 Consul Connect 等，其中也不乏有一些比较优秀的开源项目，这些项目有一个共同的特性，背后企业的主营业务都有深厚的群众基础，比如 Kong 公司的 API 网关、HashiCorp 公司的 Consul 注册中心，服务网格产品只是他们在拓展自己业务边界，作为入侵者进入到这个领域，带着非常明显的 Second Act 意图扩张潜在市场。另一方面，早在 2019 年 5 月，微软联合了除 Istio 外几乎所有的服务网格厂商，共同推出 SMI（Service Mesh Interface），意图很明显，就是提出一个通用的服务网格抽象，定义标准 API，屏蔽各厂商服务网格具体实现，标准化服务网格控制面，以此降低 Istio 的商业化价值，而这是 Google 不愿看到的。

Service Mesh Interface 规范

以上种种原因都驱动着 Istio 要加快生产案例的积累，这也代表了 Istio 近几个版本持续演进的方向：把控制面组件合并为 istiod 和完善 istioctl 的集群生命周期管理能力来降低运维复杂性；将 Mixer 组件能力下沉到 Sidecar 降低服务东西向网络延时；增加对虚拟机的原生支持，便于非容器化业务平滑迁移……等等，这其中的每一项都是业务生产落地 Istio 时面临的痛点问题。

为什么要使用服务网格，落地难点在哪里？

服务网格技术是伴随着传统微服务框架难以解决的痛点问题而出现，这些痛点问题包括：

1）多语言服务治理

微服务化架构允许企业用最合适的编程语言实现业务逻辑，虽然市面上有一些跨语言的 RPC 框架，但几乎没有生产级的跨语言微服务框架。这导致企业要么牺牲微服务的多语言优势，要么花几倍资源投入建设多语言服务平台，不仅出现系统重复建设，还面临着服务抽象不统一导致上层系统设计复杂的问题。

2）SDK 升级

微服务化系统离不开各种 SDK 和胖客户端，专门处理与各种中间件、技术平台等基础平台的交互，这种 In-Process 的耦合导致 SDK 升级必须重启业务系统。业务团队从稳定性和上线节奏等方面考虑，一般很抗拒基础平台团队提出的升级 SDK 需求，这导致基础平台的 SDK 推进进程非常缓慢，根据我们的经验，从 SDK 升级需求提出到线上全量更新，这个时间间隔可能要三个月甚至更久。

3）精细化灰度发布

传统微服务基于主机实例数或者容器副本数实现灰度发布，发布系统只能按实例数或者副本数比例控制灰度流量比例，比如一个 10 副本应用，灰度流量的步进就是 10%，无法做更精细化的灰度流量管理。这会导致业务灰度发布版本的风险无法有效掌控。

4）跨云级别的弹性伸缩

在混合云和多云趋势下，业务希望在大促、大事件营销等关键时期能把流量从本地机房导到公有云，或者从容灾角度希望能把业务负载跑在多家公有云上，以尽量少的成本实现最灵活的弹性架构，传统微服务框架无法解决弹性架构下的流量治理问题。

通常，面临上述复杂应用场景的企业都拥有较大的服务规模和业务体量，对架构的灵活性的要求很高，所以现阶段我们看到服务网格技术在头部互联网企业，尤其是 ToC 业务企业中有较多的先行实践。

服务网格技术对企业现有分布式系统架构的影响主要体现在系统分层和能力下沉。传统微服务框架以 RPC 框架为基础，提供服务目录、注册发现、服务治理、流量管理、配置中心、全链路追踪等核心能力，并且向外延伸到安全审计、监控告警、统计分析、知识库等平台化能力，服务网格技术要做的事情就是把这些微服务架构支撑能力下沉到 Sidecar 里，并且在这个改造过程中不中断业务。要做到这个过程平滑，除了在服务网格数据面和控制面组件中对服务注册发现、RPC 协议、配置下发进行扩展之外，还要对现有的上层的研发工作台、运维效能平台等支撑平台进行兼容。

虽然企业在积极实践服务网格技术，但是其在生产环境中落地还是比较少，而造成这种情况的原因是多方面的，我们可以从内因和外因两个角度来分析。

在内因方面，首先很多企业的微服务建设处于较早期阶段，服务刚拆分完，用 Spring Cloud 或者 Dubbo 把服务跑起来，微服务架构支撑所需的基础能力建设还非常薄弱，比如服务实例节点分散排查问题效率低，依赖关系复杂带来的服务雪崩问题，服务规模变大之后的部署运维复杂性，面对突发流量时弹性能力不足等等，一步到位落地服务网格几乎要求重建微服务基础设施，而企业更希望在经验积累、基础系统建设方面循序渐进。

其次，以 Istio 为代表的开源服务网格技术本身在易用性、可运维性、性能等方面还在有待改进的地方，使得企业中不少对可用率、延时敏感的业务在落地过程中存在风险。

而在外因方面，服务网格作为一种全新的云原生技术出现在大众视野，目前仍有不少观点认为其中有商业炒作因素，网格技术本身还不够成熟，因此企业还在谨慎评估这项技术投资的风险。

另外，服务网格技术引入后，企业组织会面临研发和运维职责体系的重新界定。在传统模式下，开发和运维有清晰的边界，开发人员负责服务运行稳定，运维人员负责服务运行的基础设施稳定。而在服务网格落地之后，服务框架、服务治理、灰度发布等开发人员更关注的能力都作为基础设施往下沉了，开发和运维的边界开始变得模糊，此时如果因为服务网格挂了影响业务，是开发责任还是运维责任呢？运维人员能否搞清楚一条服务治理规则对业务全局的影响？开发人员的关注点还是在服务网格这一层的话，那引入的服务网格的价值又在哪呢？

一种技术的发展会遵循技术成熟度曲线规律，目前服务网格技术正处于期望膨胀期。服务网格技术本身存在的问题需要开源社区和企业共同解决，企业提供丰富的复杂场景，开源社区进行持续改进。在这个过程中，企业从组织文化上要接受过程混乱，这是新技术新标准落地的必要路径。过程越痛苦，新标准的建立越有价值，这是萨提亚变化模型告诉我们的。当企业能持续从服务网格实践中获得收益并形成共识，那就可以认为服务网格技术进入了生产成熟期。云原生社区目前处于高速发展阶段，从期望膨胀期到生产成熟期预计不会太远。

企业如何落地服务网格？

作为一个被贴着“能力下沉”、“业务无侵入”等标签的新型技术架构，服务网格从架构模式上来说，就能极大提升微服务研发效率和运维效率，所以早早引起了业界基础技术平台研发和架构师们的注意，因为这部分人对新技术最为敏感，能理解其中的技术价值。

而具体到落地阶段上，大家的目光就会聚焦于服务网格应该从“容器平台”上长出来还是从“微服务框架”上长出来。传统观点认为，容器平台解决的是运维域的问题，而微服务框架解决的是开发域的问题。对运维人员来说，依托服务网格技术打通的服务、基础设施边界以及对服务统一的抽象，可以使他们可以更好的从全局视角进行服务质量、依赖管理、容量规划、端到端监控等来保障产品稳定性。而对开发人员来说，他们是从服务网格技术中获益最多的一群人，原本需要关注的服务框架、服务治理、环境一致性、遥测数据、客户端 SDK 版本升级等等都可以不用关心，可以只专注于业务本身的逻辑开发，心智负担和能力要求大大降低，所以开发人员有非常强的意愿尝试服务网格。

服务网格作为云原生时代微服务架构的基础设施，实际上需要对企业的 IT 人员职责进行重新划分才能更好地为产品可用率服务。从网易轻舟支撑客户的落地实践过程来看，从开发团队和运维团队中抽调经验丰富的架构师形成基础架构团队，作为服务网格平台的责任团队，新的职责要求他们必须要非常理解业务，要清楚地知道业务的服务依赖和服务治理规则，故障后能从业务视角进行排障和快速恢复，此外他们也要重新审视现有的技术架构和支撑平台建设，从业务视角出发进行设计，避免做出来的基础平台无法满足业务需求，或者不好用。

同时，安全也是服务网格落地不可忽视的一个环节，企业往往会更注重外网安全而通常忽略内网安全。实施微服务架构时，企业通常会在流量入口的地方，比如负载均衡器或者 API 网关上实现认证和签权，微服务框架层面很少有提供认证鉴权能力，因为在微服务东西向通信上实现一个灵活又安全的认证授权体系成本非常高。而服务网格的 Sidecar 可以非常方便地在微服务调用链路上实现透明的安全认证和鉴权，并且通过控制面灵活下发策略。以 Istio 为例，Istio 提供了全面的安全解决方案，解决微服务流量加密、双向 mTLS、服务访问控制、证书管理、审计等问题。使用服务网格技术，可以快速搭建一个企业级零信任架构的网络基础设施。

企业的技术领先度，要看该技术是否很好的解决了某些极端业务场景下的问题，比如系统的性能、承载能力、稳定性等。技术最终是为业务服务的，企业实践服务网格技术或者对外提供服务网格产品，首先要回到真实业务的生产场景里去，通过技术选型、可行性验证、平台演进方案、运维体系、平滑迁移等系统性建设，伴随业务快速发展不断碰到新的问题再解决问题。只有经过大规模复杂业务场景磨练的产品，才能在实用性和技术先进性两个方面做到兼顾。

国内外的服务网格技术差异

目前国内对服务网格技术发展做出推动、贡献的企业大致可以分为两类：

• 一类是云厂商，对于云厂商而言，服务网格作为云原生应用架构的重要组成部分，是吸引用户上云的重要产品。相比其他服务网格产品，Istio 有着无厂商锁定、标准化、受众广等优势，更容易被云厂商所接受，并作为服务网格标准产品对外提供服务。云厂商对 Istio 的推广和布道为服务网格技术发展发挥了重要作用。
• 另一类是有较强技术储备的互联网头部企业，他们将服务网格看做是传统微服务架构的一种自然演进技术。由于这类企业往往会有历史遗留系统，所以他们会自己重新实现数据面或控制面，深度绑定企业原有私有技术栈，这类方案的重点是贯彻服务网格架构中能力下沉的理念，将服务发现、RPC、配置同步、服务治理等能力以 Sidecar 或者 In-Process 技术从业务系统中解耦出来。网易严选的 cNgnix Mesh、微博的 Weibo Mesh、美团网的 OCTO2.0 等都属于这一类型。当然，还有一些企业尝试用 Per Node 部署的 API 网关作为 Sidecar，配合 API 网关管控服务，在一定程度上也能获得服务网格架构带来的收益。这些先行者企业通过自身业务落地证明了服务网格的技术价值，也因此最早享受到服务网格技术红利，帮助公司业务快速发展。

国内外主流的开源服务网格技术包括 Istio 和 Linkerd，两者在性能、扩展性、流量治理、成熟度等方面各有优劣，但如果是从关注度的维度来看，Istio 遥遥领先，根据 Google 搜索趋势数据显示，Istio 几乎领先了一个数量级。

除此之外，还有一些小型的开源服务网格产品，例如 Kuma、Consul Connect、Maesh 等，这类产品虽然不是一个完整的服务网格解决方案，但都是从一个用户基数庞大的应用市场延伸出来的，比如 API 网关、注册中心、LB 等，可落地性较强，拥有一定的细分市场。

除了 AWS 的 APP Mesh（数据面采用 Envoy）之外，国内外主流云厂商基本都是提供基于 Istio、Linkerd 等开源产品的集成服务，但目前阶段这种云服务同质化较为严重，缺少场景化的产品形态封装，更是难以满足用户对于平滑演进的诉求，未来还需要靠更多贴近业务的最佳实践来打磨产品。

Istio 的未来发展

毫无疑问，Istio 作为目前 Service Mesh 领域的主流技术在市场和产品方面都有很大的发展潜力。

针对 Istio 当前版本的不足做增强，提供传统微服务架构平滑升级支撑，以便更好的为业务落地服务，这是目前市场上急需的一种服务网格产品形态。以网易轻舟服务网格服务为例，除了提供标准 Istio 能力之外，在性能方面，通过 SR-IOV 和用户态协议栈优化 Sidecar 间网络数据面，相比开源 Istio 降低了 50% 以上的延时，通过 xDS 配置优化降低 Sidecar 启动延时；在可观测性方面，通过 APM 实现端到端的链路追踪和排障支持；在可运维性方面，通过 Sidecar 版本管理系统（SVM）实现业务流量无损的 Sidecar 热升级；在平滑迁移能力方面，提供容器和虚机、物理机的混合部署能力，提供基于 Envoy 网关的兜底路由，提供 Istio 兼容 Dubbo、Thrift 协议的服务治理能力，保证业务能平滑迁入和安全回滚。通过这一系列的能力增强，网易轻舟支撑集团内网易严选、网易传媒等业务完成了大规模的服务网格技术落地。

而在产品方面，Istio 经过最近两个版本的迭代之后，易用性、可运维性、性能、扩展等都得到了很大的提升。正如 Istio 在 2020 年的 Roadmap 里提到，“为了商用”，未来的 Istio 会继续在用户体验和应用落地方面发展。

围绕这个目标，后续几个版本会持续完善的企业特性也非常令人期待：

• 通过 WebAssembly(Wasm) 重新定义 Envoy 代理的扩展性。随着 Wasm 技术完善，服务网格的扩展需求（增加协议支持、安全集成、自定义度量等）可以通过多种语言实现，以满足用户的多样性需求。
• 持续完善非容器工作负载和非 K8s 平台的兼容性。目前仍有大量企业在基于虚拟机、物理机等混合基础设施上运行工作负载，Istio 必须解决好非容器工作负载和非 K8s 平台的兼容性问题，才能让企业更好更平滑地演进微服务架构。
• 完善边缘基础设施和多集群管理能力。在混合云和多云的企业 IT 架构趋势下，需要 Istio 提供更好的边缘基础设施能力，连接、治理集群边缘流量，使业务服务真正对基础设施和 IT 架构无感。
• 中间件 Mesh 支持。在 Istio、Envoy、UDPA 各层实现中间件胖客户端、代理层、控制端逻辑，通过 Sidecar 代理业务对中间件的调用，全面解耦业务和基础设施。

作者简介

冯常健，网易数帆轻舟业务部架构师、技术专家，2012 年加入网易，目前担任网易轻舟微服务平台负责人，十多年服务端开发经验，主要研究方向是云原生技术、高可用 / 可扩展架构设计、分布式系统等，在微服务、容器化、服务网格、DevOps 等领域，具备大规模的落地实践经验。