蚂蚁金服流量投放平台的AIG改造

1. 概述

对于多租户场景的服务应用，在做系统架构设计时经常离不开的话题就是租户隔离设计，这里的租户隔离不限于实现隔离、数据隔离、资源隔离等。实现隔离通俗的讲就是一套代码实现是否被多个租户共用，还是每个租户一套单独的代码实现；数据隔离就是租户的数据在数据库中的存储隔离方式，常见的有字段隔离、表隔离和库隔离；而资源隔离则是不同的租户是否在同一个服务器硬件环境提供业务服务能力。

我们流量投放平台的业务定位是为A+、B+、港澳钱包、GPA、GOL等国际营销业务场景提供丰富的用户触达能力，包括展位的数据供给和优化、通过短信/push等通知渠道的主动触达等产品化工具，是一个典型的多租户场景的服务应用。

对于资源隔离，当前现状是A+和香港钱包两个租户的流量占流量投放平台的90%以上，日常流量中两者之一出现线上故障，可能就会引起连锁反应降低整个平台的吞吐量，从而对所有业务方提供的服务稳定性造成波动；而大促期间则需要对两个租户的大促活动排表错峰，防止同一时间两个租户的大促活动带来的流量打垮服务应用。因此我们期望落地资源隔离，让两个租户各自独占一组资源。

2. AIG流量隔离原理

AIG即AppService InstanceGroup应用服务实例组，是一个应用配置概念，是应用为了支撑某些业务而单独隔离出来一组资源（Pod、应用基线、流量）。通过AIG能力，可以将应用在物理层面划分成多个实例组，让不同的业务在各自的实例组里单独运行，实现各个业务之间相互不影响，如下图。

简单地讲就是将一个应用的集群按某种维度例如租户分成若干个实例组，当上游应用请求该应用的服务时，按路由规则将请求路由到指定的实例组中，从而实现每个维度的请求只会请求到指定的实例组并执行处理。

2.1 普通链路

蚂蚁金服的技术栈中RPC服务使用的是SofaRPC框架，支持的服务路由方式主要是软负载和硬负载：

• 软负载是服务提供方将提供的RPC服务注册到注册中心，然后服务调用方从注册中心获取调用服务的地址列表。当调用方调用服务时，根据软负载策略从地址列表中选择一个地址做RPC服务调用；
• 硬负载是服务提供方在ZPaaS平台发布完成后自动将机器ip注册到AntVip的应用域名下，然后服务调用方通过AntVip获取服务提供方域名下的可用机器ip，直接点对点直连做RPC服务调用；

2.2 SPaaS方案

SPaaS对于AIG隔离有一流量染色和隔离的方案，即先识别某类业务的流量（染色），识别后再通过路由让这部分流量能实现独占应用机器资源（隔离）。

RPC流量染色，要求链路上游应用接入染色SDK（serverlesssdk）、并通过对应的管控平台(bizops)下发染色配置，实现对满足某种条件的流量打标，打标信息会通过sofa rpc baggage的机制会一直携带在随后的调用链路中。

RPC流量隔离，则要求应用必须接入Mosn，并通过servicegov下发对应引流规则，依托Mosn的客户端路由能力，将带特定标识的流量引到服务端应用的某个AIG内。

流量染色如下图，在管控平台上配置好流量染色规则配置后，SDK可以通过RPC服务的接口、方法、参数等信息做规则匹配，对于匹配成功的RPC请求的Trace上下文添加业务标识。

流量隔离如下图，在管控平台上配置好流量隔离规则配置后，平台将配置下发到对应应用的Mosn中，由Mosn做规则匹配，计算出需要路由的AIG分组后指定RPC寻址的mosn_aig参数，实现流量路由到下游应用的指定的AIG。

2.3 玲珑方案

在SPaaS方案中应用的最小运维单位是AIG实例组，而玲珑平台有另一套方案，在AIG的实例组上抽象出一个更细粒度的场景概念，将场景作为最小运维的单位。应用有且只有一个默认场景，并且可以创建多个业务场景，如下图，每个资源组中可以部署多个玲珑场景，每个场景只能部署到一个资源组下。

按玲珑的设计方案，每个新维度例如租户的调用方接入玲珑平台时，由玲珑平台创建分配一个新的玲珑场景，在逻辑设计上就将每个接入方设计成最小的运维单位：场景。

该设计将流量隔离与AIG资源组解绑，SPaaS的方案中，服务调用方必须强感知服务提供方应用的AIG资源组概念，在RPC隔离配置中强关联AIG资源组，一旦服务提供方的AIG资源组发生修改，则需要服务调用方和服务提供方都需要做变更操作。

而玲珑的方案中，通过抽象一个玲珑场景的概念，让服务调用方只需要感知到场景的概念，而不需要关联AIG资源组。当服务提供方需要将一个玲珑场景单独隔离到一个AIG资源组时，仅仅需要服务提供方在玲珑平台将该玲珑场景部署到新的AIG资源组集群下，而不需要服务调用方做任何变更。

2.4 方案对比

方案	SPaaS方案	玲珑方案
接入成本	接入应用无需代码改造，但AIG隔离时需要推送MOSN路由配置	接入应用无需代码改造，业务初步接入时推送MOSN路由配置，AIG隔离时不需要再做配置变更
通用性	上游应用必须安装高版本的MOSN	上游应用不强依赖MOSN，可以通过指定SofaRPC服务的uniqueId请求到预期AIG集群
AIG机房切换	业务流量与AIG物理集群绑定，每个业务流量做AIG隔离时需要执行配置变更	AIG机房切换 业务流量与AIG物理集群绑定，每个业务流量做AIG隔离时需要执行配置变更 玲珑将AIG流量单位与物理集群解耦，可以简单方便一键将业务流量在默认集群和任意AIG集群上做切换
全链路AIG隔离	流量入口执行流量染色，全链路上下游应用基于流量染色做统一的AIG隔离	需要链路上下游应用透传统一个参数，然后基于该参数做AIG隔离

3. 其他中间件

3.1 MQ消息隔离

3.3.1 MsgBroker

MsgBroker本身已经实现了AIG隔离能力，当订阅端向MsgBroker订阅消息时，会带上机器的AIG信息。MsgBroker则通过订阅端的AIG信息做分组，当需要向订阅端投递消息时，先通过配置中心的引流配置决策消息匹配的分组，然后再向分组中的订阅端实例机器投递消息，如下图。

3.3.2 SofaMQ

SofaMQ目前不支持AIG隔离，且短时间内没有支持的计划。

3.3.3 玲珑方案

遗憾的是，各个消息中间件对于AIG支持能力不统一，且技术栈不一定相互兼容（MsgBroker的AIG能力和玲珑技术栈不兼容），因此玲珑平台自身实现了一套简单粗暴的消息隔离方案，并且不需要依赖消息中间件的AIG实现。

玲珑有且只有一个默认场景和多个业务场景，默认配置下只有默认场景会启用消息监听能力。玲珑发布业务场景后，可以通过配置启用业务场景的消息监听接管能力。业务场景的消息监听的group会在原先基础上加上场景标识，如下图，即通过区分消息监听的group，令每个启用消息监听接管能力的场景从消息中间件消费重复的消息。然后由业务代码中做过滤，只处理该场景对应的维度例如租户的消息，当然可以通过例如MsgBroker自带的客户端Client的Header过滤的方式做消息过滤，而不用业务代码改造。

3.3.4 方案对比

方案	MsgBroker	玲珑方案
接入成本	接入应用无需代码改造，但应用强依赖高版本的MOSN	需要理解玲珑的设计思路，并且需要改造业务代码做过滤逻辑
通用性	仅MsgBroker支持，其他消息中间件不支持	由玲珑平台提供的能力，不依赖中间件本身的实现，支持多种消息中间件如MsgBroker、SofaMQ
备注	与玲珑方案不兼容	与MsgBroker方案不兼容

4. 落地

我们流量投放平台接入的业务线众多，因此上游应用技术栈繁杂，有标准的SofaBoot应用也有非标准技术栈不再维护的存量应用，有接入各个版本MOSN的应用也有直接裸奔未接入MOSN中间件的应用。面对技术栈不统一甚至连MOSN中间件都未必安装的上游应用，不强依赖MOSN的玲珑方案显然更适合我们，另外虽然玲珑提供的MQ消息隔离能力需要代码改造且需要一定的理解成本，但至少能解决我们流量投放平台当前所有使用的消息中间件的AIG隔离问题。

由于流量投放平台的技术栈是一个已经不再被维护的非标准技术栈，因此我们第一步先将流量投放应用改造成标准的SofaBoot应用，然后再接入玲珑平台使用玲珑技术栈。作为第一批由标准SofaBoot应用接入玲珑技术栈的应用，而非直接在玲珑平台创建的应用，在接入过程中遇到了各种问题。感谢玲珑平台的技术同学提供的技术支持，能够快速定位并解决接入问题，并听取我们接入方的诉求对玲珑平台新增了不少新功能。

经过开发改造，如今流量投放平台已经成功改造成玲珑平台应用发布上线，对香港钱包开量了AIG隔离能力。另外通过玲珑平台提供的模块服务，对业务线开放了扩展点能力，减轻了业务同学在流量投放平台的业务开发成本。

5. 总结

流量投放平台通过接入玲珑的AIG能力，对香港钱包业务线落地了流量隔离和消息隔离，并且后续其他业务线接入AIG能力时只需要做简单的配置变更就可以快速完成。另外基于玲珑的模块能力，流量投放平台应用作为平台向各业务线开放了扩展点能力，将原先各行业层的定制化需求改造都收口到了玲珑模块的扩展点实现中。不仅减少了平台代码的历史厚重感，更是大大降低了原先各业务线定制化需求的开发周期和人力成本。

短短一年我们对流量投放平台的底层技术栈进行了两次大升级，虽然过程是痛苦的，但终于将流量投放平台从一个难以维护的非标准技术栈应用改造成了开发简单易于维护的玲珑技术栈应用。基于现有的经验，接下来会对我们组其他应用推广玲珑技术栈，统一底层技术栈，为各个业务线提供更稳定的系统服务环境和统一的行业扩展能力。