shop后缀的网站,网站丢失怎么解决,wordpress 密码验证,佛山快速排名优化简介#xff1a;本文主要介绍我们最近在利用 Service Mesh 架构解决海外业务问题中一些实践和价值探索。我们在海外业务引入 Mesh 架构过程中#xff0c;充分利用 Istio 的基于 yaml 来描述和定义路由的抽象能力#xff0c;制定了企业流量治理标准#xff0c;并将集团海外业…简介本文主要介绍我们最近在利用 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 百花齐放的盛况。
原文链接
本文为阿里云原创内容未经允许不得转载。
