翰学 阿里妈妈技术

阿里妈妈广告应用团队在平台化支撑业务发展的思路下，启动了对应用系统架构、研发模式、组织阵型各个维度的改革和升级，以期通过打造全新的“广告业务平台”来提升应用系统的工程建设能力、沉淀广告业务资产、建设专业的人才梯队、赋能营销业务的创新发展。

其中，业务中心化是推进应用平台化建设最重要的工作之一，我们将广告业务按照领域进行抽象划分，建成了多个业务中心组成的业务平台，每个中心负责该领域的相关业务，多个中心互相配合横向支撑各业务线的需求。业务中心化后，之前单体的推广服务系统变成了微服务架构下的多个业务中心，之前系统内部的调用变成了系统和系统之间的调用，如何管理好由此带来的大量复杂异构系统间的异步调用和通信，是我们亟需抽象和解决问题。

▐ 1. 问题分析

在微服务架构下，中心之间为了配合完成复杂的业务，系统和系统之间的“耦合”变的不可避免。系统间的调用方式大体分为同步和异步两类，由于中心对外以HSF（RPC）服务的方式暴漏，故同步调用问题已经很好的由HSF（RPC）中间件解决，因此我们需要重点关注异步交互方式。

应用间使用的异步交互方式一般有两种：一种是采用基于消息队列的异步消息处理（如: Metaq，Notify）；另一种是基于数据库的DRC消息变更。举一个异步交互的例子：广告主应用系统和审核系统属于两个不同的领域，团队和人员也是分开的，在系统交互方式上为了避免耦合，大多会采用消息交互这样的方式。比如：一个商品被处罚，审核系统发送处罚消息出来，广告应用系统在接到这个处罚消息之后，需将该商品对应的广告进行下架。

以基于消息队列的方式来搭建异步交互链路为例，我们来看一下发送端和接收端要做的事情：

  1. A系统开发消息发送逻辑
  2. B系统引入A系统的数据对象定义（系统之间耦合度增加）
  3. B系统开发消息订阅、消费逻辑、重试机制、流控机制等

通过这种方式搭建异步链路存在以下几方面问题：

研发效率低： 为了搭建异步链路，B系统的研发人员不得不写消息订阅逻辑、异常重试逻辑、流控逻辑，而这些逻辑与核心业务处理并无太多关系，属于“无效代码”的范畴（既无业务价值又无技术含量的代码）。且联调过程中需要异步链路上下游多个系统的人员进行配合，研发和联调的效率都比较低。

链路运维难： 由于异步链路的代码散落在各个系统中，没有一个集中的平台来进行管理和运维，整体异步链路处于不可见不可管不可控的状态；也没有一个人清楚系统间共有多少条异步链路，每条异步链路流转的情况，尤其是在大促节点，需要排查、限流的时候就会很无助；另外异步链路交接也是个问题，通常只有当时负责开发的同学清楚整个链路，一旦有人员变动，原有链路几乎就会处于无人维护的状态，这无疑给业务的稳定性带来了很大隐患。

问题排查难： 一旦出现问题，排查人员需要把异步链路中涉及到的各个节点从头到尾熟悉一遍，且由于各个系统日志记录的方式、格式、详细程度各不相同，存储的位置分散，这大大影响了问题排查效率。

上述异步链路存在的问题，最根本原因还是链路处于不可见不可管不可控的状态。那么，如何做到可见可管可控呢？我们应该都了解ESB（企业服务总线）的思想，ESB采用了“总线”这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务级别上动态的互连互通，是一种在松散耦合的服务和应用之间标准的集成方式。我们的异步链路正是缺少了这样一个集中的点来进行配置、管理和问题排查，借鉴ESB的思想，我们希望整个异步链路的交互应该由网状结构调整成更便于管理的总线型结构。

▐ 2. 方案设计

本着这个目标，我们打造了工具平台：AMB应用消息总线（以下简称AMB)，来解决应用内部、应用之间基于消息的异步处理请求，由AMB完成消息转换、路由、处理等功能，并提供统一的监控、报警、重试、流控等机制。

AMB的系统架构如下图，主要分为控制台和后端。

控制台主要面向异步链路的开发运维同学，包含“创建任务”和“任务管理”两块。“创建任务”模块可以在上面进行链路的可视化、拖拽式配置，我们抽象了一组标准组件，基于这些组件可以完成流程的配置；

“任务管理”模块主要负责链路的启停管理，链路运行状态及日志的查看。

AMB的后端采用分层的思想进行设计（如下图所示）:

  • 最上面是Connector层，负责对接外部各种协议，如：Metaq, Notify, DRC, HSF等，这一层支持扩展，以便适应需要新增协议的场景。
  • 再往下是链路组件层，包含我们抽象的一组用来搭建流程的标准组件，目前有：过滤器、转换器、处理器、分流器、路由器等等，组件库本身也是可扩展的，根据业务场景的需求可以不断丰富组件库的组件。
  • 再往下是平台服务层，是平台本身提供的一些标准化的公共能力，如：日志、重试策略、监控报警、流控等。
  • 最底层是我们的执行引擎，AMB的运行时是跑在我们另一个任务托管的工具平台鹊桥上的。一条AMB流程占用一个Jstorm的拓扑，流程和流程之间做到了完全隔离。利用Jstorm的扩容缩容机制，我们可以快速响应流程压力的变化。

▐ 3. 技术亮点

从目前实际场景出发，AMB建设有以下几方面亮点：

易用性： AMB的用户是我们的研发同学，在日常研发场景中，用户对于易用性和效率有很高的要求，需要让用户感知到配置流程比开发流程更快更方便。为此，我们研发了自助化的流程配置控制台，基于我们预定义的标准组件，用户通过拖拽式的所见即所得的方式就可以完成一条流程的配置。

丰富的流程组件： 组件相当于搭建一条流程的原子积木，组件之间相互配合来完成一条流程的业务逻辑。目前平台已经抽象了一系列的通用组件，基本能够满足大部分的研发需求，对于组件库不能满足的，我们还支持自定义组件，来扩展组件库的能力。同时标准组件库本身也在随着业务需求的演进而不断的丰富。

隔离性： 对于业务方来说，流程的运行是从自己的应用内部转到公共的AMB 上，如何保证自己的流程不受其他流程影响，如何获得足够的处理能力等是业务方非常关心的问题。AMB底层依赖Jstorm拓扑来运行流程，单个流程独占一个拓扑，完全做到了流程间的物理隔离。同时借助Jstorm的动态扩缩容机制，流程处理能力能够快速的扩张和收缩，做到实时响应业务处理压力的变化。

运维监控： 异步链路的监控和问题排查一直是令研发同�