简介：本文次要介绍咱们最近在利用 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 百花齐放的盛况。
原文链接
本文为阿里云原创内容，未经容许不得转载。