简介：本文主要介绍我们最近在利用 Service Mesh 架构解决海外业务问题中一些实践和价值探索。我们在海外业务引入 Mesh 架构过程中，充分利用 Istio 的基于 yaml 来描述和定义路由的抽象能力，制定了企业流量治理标准，并将集团海外业务发展多年的多种路由模块统一成使用 Mesh 的统一路由框架，且在今年双十一支撑了全量的海外业务。也希望通过我们的经验介绍，可以给其他还在探索如何落地 Mesh 的同仁一些参考。

作者 | 深简、天千

背景

Service Mesh 从 2016 年被提出来到现在，无论是应用探索，还是技术演进，都已经有了长足的发展，国内也有多家互联网大厂进行了 Mesh 化的落地实践。阿里巴巴做为早期在 Mesh 领域投入的厂家之一，在集团内部经历过技术验证，价值探索，规模落地，技术红利释放等阶段，期间解决了不少和阿里集团规模化相关的难题挑战，也见证了这一技术带来的革新变化：一方面阿里巴巴的服务和节点规模特别大，istio + envoy 方案难以支持如此大规模的服务，因为我们在性能优化上做了很多工作；另外在技术支撑体系上，阿里巴巴很多基础实施都是基于 Java 技术栈的，为了接入阿里巴巴相对较完善的技术体系，我们也花了很大的精力用 C++和 Golang 重写了很多内部的组件；在价值探索方面，我们在短期价值和长期价值上和业务方做了很多平衡和取舍。

本文主要介绍我们最近在利用 Service Mesh 架构解决海外业务问题中一些实践和价值探索。我们在海外业务引入 Mesh 架构过程中，充分利用 Istio 的基于 yaml 来描述和定义路由的抽象能力，制定了企业流量治理标准，并将集团海外业务发展多年的多种路由模块统一成使用 Mesh 的统一路由框架，且在今年双十一支撑了全量的海外业务。也希望通过我们的经验介绍，可以给其他还在探索如何落地 Mesh 的同仁一些参考。

海外业务的路由复杂性

在阿里巴巴集团，海外业务对于路由的要求远比国内业务更为复杂，因此海外业务团队基于现有微服务框架定制了很多路由能力，每一种路由能力都独立实现了一个模块，比如切流、容灾、演练、灰度等各种维度的流量调度，这样形成了很多独立的模块，使用方式也各不相同，如有的是通过配置调度，有的是修改代码调度等。维护这些模块的成本很高，路由方式不够灵活且粒度较大，基于这样的一个大背景我们开始在海外业务引入 Mesh，通过 Mesh 化的统一路由来解决这些业务痛点。

通过对业务抽象我们归纳出海外业务路由的三个基本过程：流量打标、集群归组、条件路由，可以简单描述为符合某些条件的流量，路由到对应集群下的某个组。这样问题本质就变成了如何划分集群节点组以及怎么识别符合条件的流量。对应到 Isito 就是 Virtual Service 和 Destination Rule。前者可以根据请求中的一些 header、上下文等条件来选择一个预先定义好的分组，而后者则是根据机器的 label 来划分组。路由模型有了，接下来就是将海外业务的各种路由模块映射到 Virtual Service 和 Destination Rule。但事实上的路由比我们预期的还要复杂，除了需要支持路由叠加，还需要有各种条件的 Fallback，最终就像一个大漏斗一样，每一个路由模块都要在上一个路由模块的基础上再根据自己的条件过滤出一批符合要求的节点。因此我们在 Istio 的基础上进行了改进，提出了 RouteChain 和 RouteGroup 的概念，一组 Virtual Service 和 Destination Rule 是一个 RouteGroup，用来定义一类路由，多个 RouteGroup 通过 RouteChain 进行任意编排形成一个大漏斗（如下图）。

在标准 Istio 实现上，Destination Rule 实际上是通过在控制平面根据一些 label 划分出一个组，然后给这个组创建一个集群再下发给 Envoy。如果一个集群要划分多个组，而且每个组之间会有一些相交那么实际上会导致下发给 Envoy 的节点膨胀，例如一个节点属于三个组，那么这个节点在 Envoy 内部会保存三份。在阿里巴巴内部节点数的规模一般都很大，叠加 Istio 这种归组方式就会导致 Envoy 内存膨胀，因此我们在内部也针对这种情况做了一个优化，将整个 Destination Rule 归组的逻辑进行了下沉，由 Envoy 在集群内部自己来完成归组。整套方案和 Envoy 社区的 Subset LoadBalancer 机制很类似，节点只存放一份，每一个归组实际上只是一组指向节点的指针。通过这样的方式最后我们成功将海外业务的所有路由都成功映射到我们的这套统一路由的方案中。

分层构建统一流量调度

对于业务方来说，始终关注的是路由功能和场景，例如灰度场景、切流场景等；而 Mesh 底层提供的是一个个路由原子能力，可以将一个集群按照机器分组、按照地域、按照环境等等分组，可以根据请求中的 header、上下文等信息进行路由到某个分组。这两者之间存在一个 gap：如何使用 Mesh 提供的路由原子能力，构建出有业务语义的调度场景。为此我们和业务方一起实施了基于分层的统一流量调度方案，整个方案分成了三层：最底层是提供原子路由能力的 Mesh 化底座，包括 RouteGroup、RouteChain 等基本的原子路由能力；中间一层则是具有平台属性的产品能力，封装了 Mesh 提供的底层原子能力，针对业务场景提供定制化的标准模型，可以定义路由策略，编排路由组合等；最上面一层则是具有业务属性的一个个流量调度场景。整个统一流量调度的架构如下：

通过这套统一流量调度方案使得整个海外的路由都收敛到一个平台上，并且后续新增路由场景都可以做到不需要代码变更就可以完成，切流的粒度也可以做到服务粒度。相比于之前只能做到应用维度，粒度更细，效率更高。

路由可视化

除了价值探索之外，我们在 Mesh 化过程中也解决了许多工程实践问题，例如Mesh路由过程可视化就是其中一个例子。在引入 Mesh 之前，业务方的路由问题都是由各个功能团队解决，而 Mesh 化之后，所以路由维护的责任都转移到了 Mesh 团队，这样 Mesh 团队答疑和问题排查的工作量变得很大，再加上海外业务路由可叠加与自由编排的属性，如何确保路由配置符合预期也是一件非常耗时的事。为了解决这个问题，我们开发了路由仿真平台，通过该平台可以对线上流量进行镜像、解析和回放并生成选路过程记录，最终再返回给路由平台，通过这样的一个闭环仿真过程，内部经过了哪些 RouteGroup，匹配到了哪个路由分组，最后选择了哪台机器都在一个选路图上呈现，路由过程直接图形化。

例如有如下路由请求：

通过仿真平台模拟，可以得到与线上选路完全一致的路由执行图，选路过程和结果都一目了然，效果如下：

结束语

通过落地业务增量价值，与业务方共同探索和解决 Mesh 化进程中的各种问题，从而共同成长，这给规模化落地 Service Mesh 提供了可行的推广路径。目前我们已经围绕 Service Mesh 构建了完善的产品体系，除了支持阿里集团内部大量电商业务，也在开源和云上进行了多项能力输出；未来，我们会持续在价值探索、落地路径、流量治理标准、高性能服务网格等方面持续投入，并及时将阿里巴巴在 Mesh 领域所积累的经验与业界共享，在构建这一面向未来的新技术的道路上，期待看到 Service Mesh 百花齐放的盛况。

原文链接

本文为阿里云原创内容，未经允许不得转载。