网易严选ServiceMesh实践

​

本文做者：国云（网易严选中台技术团队负责人，容器化负责人）

2008年加入网易，长期从事一线的研发与管理工做，擅长技术架构及技术体系建设，曾参与或负责过网易博客、网易邮箱、网易有钱等多个核心产品的研发工做，现任严选中台技术团队负责人，负责严选的容器化及Service Mesh演进。

背景

Service Mesh在严选的探索与实践大体分了如下几个阶段：

第一个阶段：探索期（2015年末~2016年4月）

网易严选从2015年末开始内部孵化到2016年4月正式面世，这个阶段严选的技术团队规模很是小，差很少10人左右，核心业务采用的是单体架构，同时会依赖少许业务基础服务，如推送服务、文件存储服务、消息中心等等。

在这个时期，若是咱们将视野扩大到孵化严选的网易邮件事业部，当时采用的主流架构是面向服务的架构(SOA)，但实现上并不统一，有使用中心化的ESB技术提供的服务、也有使用去中心化的Spring Cloud框架提供的服务。

无论是ESB仍是以Spring Cloud为表明的分布式服务框架，都有一些典型的问题须要解决，而严选做为一个现象级的电商产品，其能够预见的业务复杂度使得咱们不得不重视此次关键的选型，稍有不慎，就有可能会带来很是大的技术负债。

此次基础架构选型过程当中，咱们主要从三个维度进行了思考：

• ****服务治理：****RPC框架 vs 服务治理平台

  经过RPC框架提供服务治理能力仍是将服务治理能力平台化？
  经过框架将服务治理能力集成到业务在当时还是主流，但从内外部诸多的实践结果来看，这种思路扔须要解决大量的问题，其中尤其显著是框架升级问题，业务团队和中间件团队诉求不一样，每每推进起来费时费力，一方面影响业务的迭代节奏甚至业务服务质量，另外一方面也严重制约中间件的演进效率。

• ****服务治理：****RPC框架 vs 服务治理平台

  服务治理能力建设是否应该考虑非Java技术栈？
  严选核心业务采用的是Java技术栈，但仍然存在很多非Java的应用系统，好比使用Python技术栈的推荐服务、使用C++技术栈的接入服务以及大量的NodeJS应用，相对而言，Java技术栈的生态更为丰富，若是要拉齐各语言栈的服务治理能力，须要投入大量的研发成本，若是不投入，这些语言栈的服务治理短板将来颇有可能成为整个系统的短板。

• 开源 vs 自研

  无论采用哪一种基础架构，都须要问两个问题：
  1）是从0开始建设仍是基于成熟的开源项目进行扩展？
  2）若是从0开始建设，是否属于重复造轮子？能额外外社区为公司带来哪些价值？

第二个阶段：小规模试验期（2016年4月~2017年初）

2016年7月份，咱们发布了第一代Service Mesh架构，并陆续在网易邮箱、网易有钱以及网易严选的部分业务进行试点，得到了不错的落地效果，也积累了宝贵的运维经验，同时管控平台也基本成型。

第三个阶段：全面落地期

伴随着严选业务规模的不断增加，业务的复杂度不断提高，团队规模也迅速增加，从最初的10余人，到2016年增加到了50人，到2017年迅速突破200人。

从2017年初开始，严选第一代Service Mesh架构在严选逐步铺开并最终全面落地。2019年，基于容器云的网易轻舟微服务平台逐渐成熟，严选也正式启动云化战略，Service Mesh架构做为应用系统云化的核心技术，也进入了全面升级阶段。

今天为你们带来的分享主要包括三个部分：

• 严选Service Mesh架构演进

• 混合云架构落地实践

• 规划与展望

严选Service Mesh演进

严选第一代Service Mesh架构

严选的第一代Service Mesh架构是基于Consul和Nginx进行扩展：

• Consul

  一种基于服务的网络解决方案
  提供了服务发现、服务注册、服务路由等基本服务治理能力

• Nginx

  一种高性能反向代理服务器，具有负载均衡、限流、容错等特性
  具有良好的扩展性

因为Consul和Nginx自带的特性基本能知足咱们的服务治理需求，所以，咱们的主要工做是将Consul和Nginx融合成一个Local Proxy（代号：cNginx），同时开发一个管控平台将这些能力提供出去。

来看下总体架构：

​

• 数据面

  cNginx与Consul Client组成咱们的Sidecar, 使用Client Sidecar模式

• 控制面

  控制面咱们提供了服务注册/发现、调用控制、治理控制这三大块能力

服务治理能力

从功能视角来看，Service Mesh架构为咱们提供了服务注册/发现、健康检查、路由控制、负载均衡、故障转移、服务调用方限流、超时控制、重试等基本的服务治理能力，其余的服务治理能力如访问控制、资源隔离、监控及故障诊断则经过中间件或日志平台完成（以下图所示）。

​

服务治理能力的完善过程也反应了严选现阶段技术平台建设的核心思路：由点带面，小步快跑，完善能力矩阵。

Service Mesh为严选带来的架构收益

那么Service Mesh架构的实践与落地为严选带来了哪些架构收益，相信也是你们比较关心的问题。

首先是解决了严选的历史包袱，Service Mesh架构使现有的服务能够在不改造的状况下引入了服务治理能力

严选在2016年推出后业务和团队规模增加都很是快，技术基建出现明显的滞后，这也形成了一个局面：

• 因为严选技术团队内部没有彻底融合，技术栈选择上会有明显的差别

• 同时，每一个技术团队对服务治理能力的理解也是不一致的，一方面形成了服务质量良莠不齐，另外一方面也致使了一些重复造轮子的状况，无形中加大了技术团队横向协做的成本

而Service Mesh做为一个基础设施层，能够处理并管理服务间的通讯，这种对应用无侵入的特性，使落地过程以及后续的升级过程都无需业务研发团队对服务进行改造，极大的下降了落地阻力，释放了研发团队的生产力。

其次，大大下降了中间件的研发投入和演进成本，也下降了业务和中间件的耦合成本

因为严选采用了Service Mesh架构，不少依赖传统中间件（如RPC框架）的服务治理能力从业务中解耦出来，下沉到Sidecar中，从而使中间件变得更加“轻量”。

因为这种能力的下沉，业务须要依赖的中间件的数量及重量都大大下降：

• 对基础技术研发团队来说，大大下降了中间件的研发投入和演进成本

• 对业务研发团队来说，也无需把大量的精力投入到中间件的学习与使用，下降了业务和中间件的耦合成本

再次，基础架构与业务架构能够独立演进

在中间件大行其道时，令基础技术研发团队比较头疼的事情是推进中间件的持续演进，每每一次很小的迭代，即便基础技术研发团队认为通过充分的测试，要推进业务研发团队升级也须要投入极大的心力与体力，同时消耗大量的开发和测试资源，这种与演进价值不对等的投入致使了中间件演进速度慢、效果差、历史包袱愈来愈重。

Service Mesh架构能够很完美的解决这个痛点，使应用与基础设施层解耦开来，带来巨大的工程价值：

• 使业务研发团队能够专一于业务领域与业务架构自己

• 使基础技术研发团队也能够专一于技术领域，因为Service Mesh架构与应用自然隔离，其演进价值更容易被量化，而有了量化数据的支撑，基础架构的演进速度才会更快、演进效果也会更好

最后，Service Mesh架构为多语言栈提供了服务治理能力

Service Mesh架构出现以前，因为相同的语言栈有明显的协同优点，这显然会致使研发团队在选择语言栈时会有所顾虑，甚至不是按照适用的场景选择语言，好比初创团队一开始选择使用了Java、PHP、Golang，通常后续大部分项目都会采用相同的语言，但每种编程语言都有本身的优点和适用场景，随着业务规模的扩大、业务场景的丰富或者多团队业务的整合，就会出现多语言栈的协同与服务治理问题。

Service Mesh架构自然能够解决多语言栈的问题，使得非Java语言栈，尤为是新兴的语言，优点更容易被挖掘，技术生态的劣势不至于被放大。

持续演进的诉求

虽然严选第一代Service Mesh架构为严选带来了很是大的工程价值和架构收益，但仍不完美，须要持续演进。

一方面，咱们须要更丰富和更高质量的服务治理能力，好比：

• 加强流量管理能力，好比流量染色、分流控制等

• 将更多治理特性（如限流、熔断、故障注入）与业务架构解耦

• 支持更多的协议

• 加强控制面能力

另外一方面，咱们也须要支持应用系统全面云化战略以及混合云或多云架构。

行业技术演进——通用型Service Mesh出现

在严选实践Service Mesh架构的时候，咱们注意到，伴随着云原生浪潮和微服务浪潮，通用型Service Mesh开始出现。

2016年9月29日，Service Mesh的概念被第一次公开提出，这要感谢Linkerd的CEO William及Buoyant公司，他们提出并定义了Service Mesh，并将Service Mesh的第一个开源项目Linkerd贡献给了CNCF。
这以后出现了多个开源项目，比较知名的如Lyft公司的Envoy和Nginx的nginmesh，其中Envoy在2017年9月也加入了CNCF。

早期的Service Mesh主要聚焦在数据面能力，同时附带简单的控制面，与沉淀多年的中间件相比并无明显的功能优点与性能优点（甚至性能上还有劣势），所以在业内并无引发太大的反响。但这一切，随着Istio的出现发生了扭转，Istio为Service Mesh带来了史无前例的控制力，并迅速成为了Service Mesh领域的事实标准，Linkerd、Envoy、nginmesh都已经主动拥抱了Istio。咱们的轻舟微服务团队也迅速跟进了Istio和Envoy，成为社区的早期参与者之一。

云原生Service Mesh框架——Istio

Istio由Google，IBM和Lyft联合开发，与 Kubernetes 一脉相承且深度融合：

• Kubernetes 提供了部署、升级和有限的运行流量管理能力

• Istio 补齐了 Kubernetes 在微服务治理能力上的短板（如限流、熔断、降级、分流等）

• Istio 以 Sidecar 的形式运行在 Pod 中，自动注入，自动接管流量，部署过程对业务透明

Istio提供了完整的Service Mesh解决方案：

• 数据面

  • 数据面支持多种协议（如HTTP 1.X/2.X，GRPC等），控制服务全部进出流量，同时负责控制面制定的策略执行，并上报遥感数据

  • Istio默认的Sidecar是Envoy，它是基于C++开发的L4/L7高性能代理（对标NGINX）

  • 具备强大的流量管理能力、治理能力与扩展能力

• 控制面

  • Pilot：提供服务发现与抽象能力，负责配置转换与分发（如动态路由等）

  • Mixer：访问控制、接收遥感数据等

  • Citadel：提供安全证书与秘钥的下发和管理能力。

  • Galley：提供配置校验能力

​

接下来咱们将从功能和性能两个视角来看下基于Istio的Service Mesh解决方案。

功能视角——服务治理能力（基于Istio+Envoy）

从功能视角来看，相比于严选第一代Service Mesh架构，在流量管理能力方面（如流量染色、路由控制、流量复制等）有明显的加强，在治理控制方面的能力也更为丰富，提供了如熔断降级、资源隔离、故障注入等能力，在访问控制方面也提供了更多选择。

​

性能视角——cNginx vs Envoy（优化前）

在Service Mesh架构实践和落地过程当中，你们最关心的问题是性能问题，Service Mesh架构虽然解决了不少基础架构的痛点，但相比于原来的一次远程调用，会额外增长1~2跳，直觉告诉咱们这会带来额外的延时。

根据咱们的压测数据，主机配置为8C16G（严选应用服务器的规格，与cNginx共享），在40并发、1600RPS的状况下，与直连相比，cNginx的延时增长0.4ms（相比直连），Envoy（社区版本，优化前）Client Sidecar模式延时增长0.6ms（相比直连）。

cNginx和Envoy Client模式对性能的影响都比较小，在可接受范围以内。另外，传统的带服务治理能力的中间件（如Spring Cloud/Dubbo等）一样会带来性能开销和资源开销，所以，实际的性能影响其实更小（从前面蚂蚁和酷家乐分享的性能数据来看，Sidecar模式与SDK模式相比，蚂蚁应用场景的平均延时增长约0.2ms，而酷家乐应用场景的延时甚至还有下降）。

性能视角——cNginx vs Envoy（优化后）

因为Service Mesh架构的Sidecar和应用不在一个进程中，所以针对Service Mesh数据面的优化路径会更丰富，优化的可持续性也更强，同时因为优化效果的干扰因素更小，优化数据会更有说服力。

咱们的轻舟微服务团队对容器网络和Envoy作了初步的优化：

• 采用 SRIOV 容器网络

• Envoy：将1.13版本中 connection loadbalancer 特性移植到 1.10.x 版本

根据咱们的压测数据

• 在并发较低（<64）、1000RPS的状况下，Envoy优化后的版本在容器网络下开启Client Sidecar表现要优于虚拟机网络的直连，相较于容器网络直连开销增长0.2~0.6ms

• 在并发较高（>=64）、1000RPS的状况下，Envoy优化后的版本在容器网络下开启Client Sidecar表现要远远优于虚拟机网络cNginx的性能，与虚拟机网络的直连性能几乎至关；但相较于容器网络直连1~5ms左右的延时

​

因为严选绝大部分应用的并发在40如下，这个性能表现可谓是至关不错，也极大提高了咱们对Service Mesh架构进行升级的信心。

当前演进方向

所以，严选当前Service Mesh架构的演进方向是基于 Istio+Envoy 的方案：

• 数据面以 Envoy Proxy 做为代理组件

• 控制面以 Pilot 为核心组件

• 平台开放与扩展主要经过 Kubernetes CRD与Mesh Configuration Protocol（简称为 MCP，一套标准 GRPC 协议）

• 高可用设计主要基于 Kubernetes 及 Istio 机制实现

​

混合云架构落地实践

2019年，严选正式启动云化战略，并明确使用容器化和Service Mesh技术对严选应用系统进行云化，因为严选当前虚拟机集群采用的是Service Mesh架构，所以，在应用系统云化过程当中，咱们也充分体会到了与业务解耦的基础设施层带来的工程价值，目前严选已经有超过90%的B端业务完成了容器化改造及Service Mesh架构升级。

严选上云Roadmap

来看下严选上云 Roadmap，主要分红三个阶段：

• IDC（私有云）时期：应用系统部署在虚拟机集群

• 混合云时期：部分应用系统部署在容器环境，部分部署在虚拟机环境，且存在同一个服务部署在多个运行环境的状况；这也是目前严选所处的阶段

• 云化/多云时期：应用系统彻底云化，部署在多个容器环境，甚至部署在多个云服务商

​

落地关键步骤

根据咱们的实践，混合云架构的落地须要处理好四个关键步骤：

首先是要坚决的拥抱云原生

• 应用全面云原生化能够最大化的发挥云的优点，已是大势所趋，所以，不管企业仍是我的都不该该忽视这种趋势

• 以容器、Service Mesh、微服务、Serverless为表明的云原生技术相辅相成

  • 容器化是云原生的重要基石，是微服务的最佳载体，同时也使Service Mesh高效落地的基石

  • Service Mesh架构能够从流量管控层面消除虚拟机和容器这两种运行环境的差别性，能够很好的支持混合云或者多云模式，是混合云或者多云架构能够高效落地的关键步骤

其次是要建设好服务治理平台

• 借助服务治理平台，能够无缝衔接虚拟机环境和容器环境的服务治理能力，整合Service Mesh的控制面能力，最大化的发挥Service Mesh的优点

• 借助服务治理平台提供的流量管控和路由控制能力，能够透明的控制应用系统在混合云架构下的服务形态，使应用系统能够平滑的从私有云迁移到混合云或者多云

• 借助服务治理平台整合混合云架构的监控和告警事件，使Service Mesh的可用性被实时的监控起来，可运维性也更好

再次是建设统一的部署平台

• 统一的部署平台能够从部署层面消除虚拟机和容器这两种运行环境的差别性，从而向业务研发团队屏蔽混合云架构的底层复杂性

• 统一的部署平台能够自动注入Service Mesh的Sidecar，使业务无需感知基础架构

• 统一的部署平台能够整合Service Mesh的控制面能力以达到混合云架构下部署过程的平滑以及部署完成后的灰度引流能力，从而加速应用系统的云化进程

最后是要作好灰度引流

灰度引流包括服务间调用的灰度引流和外域调用（用户流量）的灰度引流，经过灰度引流，能够从私有云架构平滑迁移到混合云架构，而平滑迁移的能力也是Service Mesh在混合云架构落地的关键。

平滑迁移

这里重点讲下咱们如何作到私有云架构向混合云架构平滑迁移：

• 经过边缘网关实现各个LDC（LDC是一组应用、数据和网络的逻辑单元）相互联通

  • 边缘网关屏蔽了每一个LDC不一样的基础架构，能够简化迁移的流程

  • 边缘网关同时也能够用于流量认证鉴权，在混合云架构中跨LDC的访问场景发挥重要做用

• 兜底路由设计

  • 兜底路由使流量在尽量不从当前AZ逃逸的状况下，提供了一种高可用的解决方案，使同环境的LDC能够互相备份

• 访问控制：从私有云架构迁移到混合云架构的过程当中，访问控制的平滑迁移是个难点，严选目前主要采用两种手段

  • IP池化技术：主要面向数据库等依赖IP管控权限的基础服务

  • 经过Service Mesh的能力实现基于服务的权限管控

• 提供灰度引流能力，使基础架构及业务的迁移状态对调用方透明；这个过程须要处理好内部流量和外域流量

​

API网关

外域流量的灰度引流能力须要API网关作好能力支持，混合云架构下的API网关须要在控制面融合虚拟机环境和容器环境的API网关管控能力。

• 总体基于 Envoy+Pilot 方案

• 数据面

  • 容器环境以 Envoy Proxy 做为代理组件

  • 虚拟机环境以Kong做为代理组件

• 控制面以 Pilot 为核心组件

• 平台开放与扩展主要经过 Kubernetes CRD与Mesh Configuration Protocol（简称为 MCP，一套标准 GRPC 协议）

如图所示，具体的技术细节这里不作展开

​

质量保障体系

Service Mesh做为基础架构，其自身的交付质量也很是重要。

要提升Service Mesh架构的交付质量和运维质量，主要从如下几个方面入手：

• 创建CICD流程，完善单元测试和集成测试

• 完善性能基准自动测试，并持续跟踪性能数据

• 完善监控报警，使基础架构的运行状态是被监控的

• 完善版本升级机制

  • 支持Envoy热更新

  • 提供灰度发布机制，作到业务可灰度和流量可灰度

  • 提供多级环境，建设基础架构的演练、测试、灰度及发布的规范流程

• 引入业务回归验证流程

踩过的坑

固然Service Mesh架构的落地过程也并不是一路顺风，仍是有些坑须要绕过去，好比：

• Envoy 目前编译版本存在 Bug

  • 在 Istio Pilot 升级到加入 accesslog 相关配置下发功能版本后，Envoy 在必定压力访问或有客户端主动断开请求时，会进入一段存在问题的断言（assert）逻辑，致使 envoy crash，此时请求方表现为 502 异常

  • 社区将在新版本中清理这段问题断言逻辑（github.com/envoyproxy/… envoy 编译选项使用 -opt（默认为 -dbg）

• Mixer 性能陷阱

  • Mixer的性能问题一直被诟病，好比打开 Mixer 的策略执行功能，每一次调用 Envoy 都会同步调用 Mixer 进行一次策略检查，致使性能衰减很是迅速，固然社区也已经意识到这个问题并在着手进行优化

  • 做为 Mixer 策略执行的替代品， Istio 的 RBAC 也是能够知足一部分功能的，好比服务白名单咱们就是经过 RBAC 来实现

规划与展望

Service Mesh架构发展到如今仍有较大的发展空间，严选和轻舟微服务团队后续将主要从性能和功能两个维度进行持续的探索与演进。

性能优化方向

性能方面，目前主要有两个研究方向

• 方案1: 采用 eBPF/xDP(sockops)，优化路径为 SVC <-> Envoy，保守预计，延迟性能提高10-20%。Envoy 部署方式 per-pod，跟社区方向一致，也是目前严选采用的部署方案。

• 方案2: 采用 DPDK+Fstack 用户态协议栈，优化路径为 Envoy <-> Envoy，延迟性能提高0.8-1 倍。Envoy 部署方式为 per-node，功能和运维层面的限制还在评估当中。

结论：Sidecar 模式采用方案1进行优化，gateway 模式采用方案2进行优化。

服务治理平台——升级严选服务治理能力

功能方面，咱们主要经过轻舟微服务治理平台来提供更丰富、更高质量的服务治理能力。

• 加强调用控制和治理控制能力

  • 好比经过平台化能力为业务提供限流、熔断和故障注入能力，下降业务研发团队的学习成本

• 提供平台化的访问控制能力，使访问控制不是做为一个技术需求，而是做为服务的产品化运营能力

• 根据精细化的运维能力

总结

今天的分享首先为你们介绍了Service Mesh架构在严选的演进历程，而后分享了Service Mesh在严选混合云架构落地过程当中发挥的关键做用、遇到的一些问题及咱们的经验，最后概述了一下目前咱们正在作的两块工做：Service Mesh性能持续优化以及服务治理平台能力持续加强。

严选的实践说明目前Service Mesh架构成熟度已经具有了大规模落地的条件，但愿咱们的工做能够为社区带来借鉴意义。

网易技术热爱者队伍持续招募队友中！网易严选，由于热爱因此选择， 期待志同道合的你加入咱们， Java开发简历可发送至邮箱：lizhuo01@corp.netease.com