文章｜张华仁（花名：华伦）网商银行基础技术架构部架构师校对｜阚光文（花名：孔门）本文10分钟阅读4832字｜简介｜微服务架构下，服务之间的调用错综复杂，一个应用可能承载着多种不同的业务流。因为它们运行在同一个应用进程中，所以各个业务流程之间必然会相互影响。如果某个业务的流量激增，导致应用进程负载激增，导致请求排队，其他业务流量也会受到影响。大多数时候，这种相互影响是在容忍范围内，或者是可以避免的。在某些场景下，我们可能需要考虑隔离某些业务流量，以消除业务之间相互影响的风险：例如，当后台调度流量影响在线用户请求时；另一个例子是当低敏感性甚至可故障的服务影响需要重新保护的高敏感性服务时。业务链路隔离的需求在业界普遍存在。通常的解决方案是创建一个新的应用，然后将需要隔离的业务迁移到这个新的应用中。新的应用方式、研发、运维等都需要成倍的成本，相关应用也需要配合改造迁移。对于只需要创建单个应用程序的情况，可能勉强可以接受。网商银行的部分应用，如高安全简化网关、高安全客户视图等，目前都在采用该方案。这种方式非常繁琐，如果我们期望在与特定服务关联的整个链路上有多个应用程序进行服务隔离，这种方案的成本将呈非线性增长，变得难以接受。在云原生架构下，可以更精细化地管理和控制容器和流量。针对以上业务流量隔离场景，我们有一个更简单、更灵活、更通用的方案——我们称之为“业务单元隔离”。,无需创建新应用即可实现上述需求。该方案已应用于包括核心环节在内的多个电商业务场景，并顺利通过了今年双十一大促的考验。那么到底什么是“业务单元隔离”呢？我们如何使用“业务单元隔离”来隔离业务环节？本文将对其进行详细介绍。部分。1概念和基本原理概念和运维模型“业务单元隔离”是一套流量着色和资源隔离的解决方案，可以帮助业务相对容易地实现业务链路隔离。在研究验证的过程中，我们也提出了优化改进方案并推动实施，最终进一步降低了业务接入成本。“业务单元隔离”需要结合“AIG”和“业务单元”两个新概念来阐述。AIG是由应用程序隔离的一组资源，用于支持某些服务。由一个或多个应用AIG、一项服务和某一类具体业务组成的业务环节称为业务单元。保证只有符合特性的流量才会被引流到某个业务单元，我们称之为“业务单元隔离部署”。主要任务及配套从“业务单元隔离”的概念中不难看出：要实现某个业务环节的流量隔离，至少需要做以下几件事：1.业务单元建设：为链路应用单独创建一个AIG，形成一个业务单元，必须保证没有流量流入新创建的业务单元。2、业务流量识别：需要通过某种方式识别从上游应用流出的具体业务流量。3、特定业务导流：对于识别出的特定业务流量，需要有机制让这些流量流向新创建的业务单元。显然，上述的事情必须要通过基础设施端和应用端的合作才能实现。如下图所示，相关基础设施和功能如下：1.事业部建设：AIG需要提供完善的研发/运维/监控支持；2、流量识别（RPC）：业务单元在链路上游的应用（A）需要接入打标染色SDK，以便通过打标管控平台下发打标染色规则；3.流量识别（调度）：将复杂的调度（消息触发、单个LDC内批量任务自主分发）转化为基于SOFARPC的流式任务，实现染色和隔离。4、具体业务导流：MOSN侧的细粒度路由需要支持AIG，让流量流入新的具体业务单元。业务单元构建业务单元其实是一个比较抽象的概念，对应一个业务环节。在线上商户的实践中，为了让业务单元更加具体，我们规定一个业务单元中多个应用的??AIG名称（appname-aigcode）的aigcode部分必须尽可能保持一致。因此，构建特定的业务单元，本质上就是创建资源组（AIG），为链路上的相关应用服务特定的业务隔离。对于单个应用，构建AIG包括两部分：一是初始化AIG元数据；另一个是围绕这个AIG进行各种运维操作（扩容、下线、重启、sidecar注入升级等）。可以看出，要支持AIG，几乎所有PaaS端的运维操作都需要适配，工作量非常大。所以PaaS端在支持AIG的时候也不得不做出取舍，决定只在最终的工作负载运维模式上支持AIG，这也造成了AIG强烈依赖现有镜像的应用迁移模式到工作负载模式。在工作负载运维模式下，PaaS将发布和运维内容整理成CRD资源，交给底层sigma（K8s）运维。切换到工作负载运维模式，有利于集团统一发布运维系统，也能更好地支持弹性伸缩、自愈等场景。但是相对于镜像模式，工作负载模式对用户的使用习惯和体验影响很大，前期也存在很多相关问题。因此，虽然线上业务工作负载一直在有序推进，但在后续核心业务接入AIG的项目中，为避免强制切换到工作负载运维模式，影响应急运维。维护核心业务，我们也提供PaaS的支持，只对AIG机器开放。已经满足了工作量的要求，针对这种情况做了完整的混合运维验证。创建RPC流量隔离业务单元后，如何保证新业务单元默认没有RPC流量流入不分流？应用机器之所以有RPC流量流入，是因为机器IP挂载在注册中心（SOFARegistry）和跨机房负载均衡（AntVip）：应用进程启动成功并被MOSN检测到后，MOSN会进行注册服务信息到SOFARegistry。发布运维过程中机器健康检查通过后，PaaS端会调用接口将机器IP挂载到AntVip上。所以要保证AIG新机默认没有流量流入，需要在MOSN和PaaS端进行调整。整体调整方案如下图所示：如何识别具体业务的RPC流量？上游应用访问印染SDK后，作为服务端或客户端被其他应用调用时，可以被SDK中的RPC拦截器拦截。拦截器将RPC请求与发送的打印Marking和着色规则进行比较，一旦匹配就会在RPCHeader中添加一个业务请求标识。最后是将流量导流到特定的业务单元。借助MOSN强大的细粒度路由能力，我们可以将流量路由到指定的业务单元，并在业务单元内汇聚。业务单元隔离主要是利用MOSN的客户端路由能力。当客户端应用发起调用，请求流经当前Pod的MOSN时，可以根据我们下发的路由规则来控制流量的走向。调度流量隔离调度本质上是消息，简单的调度场景通常不需要隔离。目前很多有隔离需求的场景都是“消息任务+三层分发”的模式，使用调度来触发批处理逻辑。三层分发协议基于tb-remoting协议分发请求，而不是标准的SOFARPC协议，不经过MOSN，因此MOSN无法控制此类请求的方向。为了解决这个问题，AntScheduler推出了一种新的流式调度模式，通过将三层分发模式转换为多个标准的SOFARPC调用，可以与MOSN无缝配合，满足流量隔离的需求。对于需要将调度流量直接路由到AIG的场景，可以直接在AntScheduler界面进行配置。配置完成后，平台会下发服务级别的MOSN客户端路由规则。对于全链路隔离的场景，调度平台接入标记染色平台，发起的RPC流量会自动标记，下游应用可以根据这个标定选择做进一步的染色引流。部分。2异步充值账户链路隔离实现“业务单元隔离”基础设施后，逐渐将几个业务场景打通。异步充值链路隔离是“业务单元隔离”在核心链路的首次应用，实现了实时交易流量与异步充值流量的隔离，避免相互影响。今年双十一大促异步补号事业部承载了10%的异步补号流量，表现平稳。接下来，我将以这个项目为载体，详细介绍我们如何使用“业务单元隔离”来实现业务环节的隔离。项目背景项目相关应用在电商业务的核心环节上，属于再保险对象，后续业务有望快速发展，因此该环节的高可用保障面临着巨大的挑战。当前链路上主要有两种流量，一种是实时交易的流量，一种是上游异步发起的补账流量。对于附属账号的流量，因为已经入库，所以容忍失败。实时交易的流量必须重新保护。后续业务发展异步账户充值流量将激增，实时交易流量存在受影响风险。因此，业务方希望有办法将异步充值流量和实时交易流量进行资源分离，保证实时交易的高可用。整体方案由于链路涉及多个核心应用，如果采用传统的新应用方案，初期改造和后续维护成本极高，因此业务希望采用“业务单元隔离”方案。与业务方深入沟通后，确认新建一个异步补账业务单元，承载以下流量：1、来自上游应用U的异步补账流量（RPC）；2、后续从上游应用UTraffic进行账户补单调度（调度->RPC）；异步充值RPC隔离上面提到的异步充值单元上游应用U需要稍微修改一下，接入流量标记着色SDK，这样我们就可以识别异步充值流量。应用U连接SDK后，作为服务端或客户端被其他应用调用时，会被SDK中的RPC拦截器拦截，可以进行标记和染色。流量标识会携带在染色流量的RPC请求或响应头中，可以被MOSN路由识别，从而将流量引导至异步充账业务单元。下图为异步补货RPC流量标记、着色、引流逻辑图：异步补货调度和隔离调度流量的识别需要应用从“消息任务+三层分发”模式切换到流式task模式，转化为多个SOFARPC调用，然后可以借助MOSN精细路由到指定的AIG。本项目中已经标记了补货调度的RPC请求，所以只需要在上游应用U端进行着色和下发MOSN引流规则即可。整个逻辑图如下图所示：压测和灰度机制标记着色SDK在对流量进行标记着色时可以识别压测流量，但是我们在这个项目中并没有使用这个方法，而是在MOSN路由规则中添加了限定条件.一方面是因为SDK暂不支持网络业务压测流量识别；另一方面，发布MOSN规则的过程更简单。MOSN路由规则支持配置多条规则。每条规则由有效范围、条件条件、路由目标destination组成。支持任意比例灰度，也支持限流试压，保证整个引流过程的安全。下图为上游应用U灰度引流1/1000压测流量（shadowTest=T）到应用A的异步附属账号AIG（A-vostro）的MOSN路由规则：单元内流量从汇聚流量流向businessunit之后，以后还会继续调用其他应用，需要下发MOSN路由规则，保证流量在businessunit内部汇聚，否则还是会默认回流到defaultbusinessunit。初步解决方案是继续使用标染SDK编写的流量标识进行路由，如：scope:app=U；条件：sl_biz_unit=xxx；目的地：mosn_aig=A-vostro。但是，此规则与客户端应用程序和服务器应用程序密切相关。对于像本项目这样复杂的场景，每个调用关系都需要下发一条规则，整体整理和维护的工作量非常大。的。我们在研究和验证中发现了这个问题，经过与相关同学的讨论，我们最终提出了一个更简洁可行的解决方案（AIG自收敛）。在MOSN这边，它支持识别自己的aigcode，并发送给所有调用这个应用的应用。规则可以简化为只与当前应用和aigcode相关，例如：scope:aigcode=vostro；目的地：mosn_aig=A-vostro。简化后规则条数与单元内申请条数相同。本项目自收敛规则如下：｜总结与展望｜本文主要介绍电商企业应对业务流量隔离场景的一种新的解决方案和业务实践流程。与传统繁琐的新增应用方案相比，基于容器、ServiceMesh等云原生技术的“业务单元隔离”方案更加轻量、灵活。目前我们已经实现了RPC、调度、HTTP流量的隔离，未来会进一步完善支持消息等流量的隔离。欢迎有类似投诉或对相关技术方案感兴趣的同学随时交流讨论。本周推荐阅读未来五年云原生运行时蚂蚁集团技术风险编码平台实践（MaaS）还在为多集群管理发愁？强迫症来了！中国工商银行ServiceMesh的探索与实践
