合约广告平台架构演进实践

Connor Binance交易所 2023-01-03 158 0

作者 | 王悦凯

导读

introduction

从事B端业务系统研发多年，不免会有这样的思考：B端系统的技术挑战是什么？什么样的业务架构算好架构？本文结合百度合约广告业务的发展历程，介绍广告投放平台从单体架构到微服务架构演进过程中碰到的问题和思考欧易OKEX合约。希望通过本文的介绍，让大家更全面的理解B端系统的技术挑战。

全文11653字，预计阅读时间30分钟欧易OKEX合约。

一、背景

GEEK TALK

1.1 合约广告概念

合约广告相比竞价广告，最大的特点是预先约定好广告价格，即价格是预先确定的欧易OKEX合约。基于这样的特点，合约广告的投放流程大致可以概括为四个步骤：询价 -> 下单 -> 投放 -> 结算。

通常来说，合约广告这种广告采买方式更适合品牌展示类广告，效果类广告更多会采用实时竞价欧易OKEX合约。相比竞价广告，合约广告在业务流程上更重投前。下面结合品牌广告业务发展的三个阶段，介绍下投放平台的变化历程。

1.2 业务发展

第一阶段欧易OKEX合约，品牌广告业务高速发展期

2011年，品牌专区产品开始平台化售卖，并逐步建立品牌投放平台：锦囊欧易OKEX合约。在2013-2018 6年间，品牌业务高速发展，诞生了Ax、Bx、Cx等10+条产品线，虽然锦囊平台做为投放的统一入口，但各产品线的投放能力仍旧是独立建设，拥有各自的独立投放平台。在这种模式下，快速灵活地应对了市场的变化和需求，但同时也造成了投放平台多，业务流程割裂的问题。

第二阶段欧易OKEX合约，寻求产品整合和流程统一

2019年开始尝试对合约类平台进行整合，统一各产品售卖流程，包括产品线关停并转、投放平台融合、账户统一、资金池统一、标准化下单等项目欧易OKEX合约。逐步落地合约广告一站式平台的建设 - 天启平台，真正实现合约广告的标准化投放流程，提升规模化投放效率，支撑业务发展。在这个阶段，各广告的投放平台入口逐步收敛，实现了操作入口的统一。

第三阶段欧易OKEX合约，满足复杂营销场景，整合营销

随着合约整合售卖（根据营销场景选择不同广告产品的组合售卖方案，即同一个合同下可下单多类广告，并享有对应的优惠政策）整体趋势的加速增长，原本非标断点式的支持方式已经无法满足业务的增长，平台化的解决方案是整合售卖规模化的必要条件欧易OKEX合约。从2021年Q3起正式启动，天启平台正式定位：统一的合约产品整合售卖平台，满足从简单场景到复杂营销场景的全投放链路服务能力。从技术视角看，旨在通过一个平台（天启），实现多资源广告售卖场景下的统一，包括一个流程、一套账户、一套资金体系、一套投放表达。

展开全文

1.3 架构演进

对应上述业务发展的三个阶段，合约平台的技术架构也经历了多个版本的演进，浓缩后，可以概括为2大类，2019年前的单体架构和之后的微服务架构欧易OKEX合约。

单体架构

2019年前的单体架构（简称『1.0架构』）图如下所示，整体上分三层，1）统一入口层，提供用户权限管理功能；2）各类广告投放平台独立建设，服务独立部署；3）抽象并沉淀基础工具库，避免各投放平台的重复开发欧易OKEX合约。

△1.0 烟囱式架构

品牌 1.0 架构本质是一个烟囱式架构，各产品线通过独立平台进行投放，开发、测试、上线互不影响，都能做到产品线维度的隔离，包括开发规范和迭代周期欧易OKEX合约。这种架构配合当时品牌团队的组织架构，在品牌产品野蛮式生长的初期起到了很重要的作用，成功孵化了一些创新产品。但是烟囱式架构一个很大的弊端就是『信息孤岛』，随着业务的发展，各投放平台发散式迭代，逐步形成了一个一个的孤岛。从技术视角看，各平台大流程相似，但在实现细节上都不同，更严重的是，存在大量的重复性建设工作，从维护成本和人效上都有很大的优化空间。从业务视角看，各产品的打法也是各自为阵，横向缺少联动，没有形成1+1>2的局面，缺少整体视角的规划。

微服务架构

业务方面，合约广告场景化营销和精细化服务的需求显著；团队方面，各合约类广告平台深度融合，孤岛边界逐步打破欧易OKEX合约。原本烟囱式架构无论在业务复杂度的应对，还是服务稳定性及质量的保障，亦或是研发效能的提升，都已经遇到了瓶颈。基于软件设计的最大目标：『设计符合业务的构造定律的演进方式，一种可以以最小的开发维护成本，使业务更快更好的流动发展的方式』，19年后，合约平台架构逐步向微服务架构演进，以领域驱动设计为准则，按照合约广告的领域模型划分微服务，构建了业务前台、业务中台、技术组件、基础设施的四层业务架构。另外，基于消息机制解耦各服务，辅以组装式业务流程的理念，拆解各种繁杂的业务流程，抽象并沉淀系统的 meta feature，灵活构造多种差异化的业务解决方案，提升系统的『可玩性』，从架构层面管理了系统风险和业务复杂度（百级别不同类型的售卖和投放场景）。

说到这欧易OKEX合约，有些人会有疑问，对于品牌业务，微服务架构演进是否是必须的呢？是否存在过度设计？

当然，假如不考虑性能、健壮性、可移植性、可修改性、开发成本、时间约束等因素，用任何的架构、任何的方法，系统的功能总是可以实现的，项目总是能开发完成的，只是开发时间、以后的维护成本、功能扩展的容易程度不同欧易OKEX合约。从后验来看（包括系统可用性、扩展性、灵活性三方面），采用微服务架构的决策是正确的，或者说利远大于弊。

在架构的演进过程中遇到了很多技术挑战，后面的内容重点挑了几个方面进行详细阐述欧易OKEX合约。

二、技术实现

GEEK TALK

2.1 服务架构

首先欧易OKEX合约，整体看下合约广告平台的微服务架构，如下图：

△合约广告平台微服务架构

总共分为四层，业务前台、业务中台、技术组件（PAAS）、基础设施（IAAS）欧易OKEX合约。

天启平台：面向广告主，提供合约广告询价、资源预订、资源下单、投放设置、物料制作等核心能力，支持品专矩阵、展示矩阵、品牌全景3大类产品矩阵，多达300+广告资源的售卖欧易OKEX合约。

运营平台：面向销售和内部运营，帮助他们精细化运营广告售卖各阶段，目前售中的投放干预和运营管控能力建设相对完善，在开屏大促和品牌广告日常运营工作中大幅提升操作的效率和安全性，让原本一些『非标』操作通过平台能力让运营实现自助化欧易OKEX合约。

业务前台：主要两个作用，1）对天启平台和运营平台的公共部分进行抽象并下沉，避免重复的业务逻辑和流程散布在两个模块，减少开发和运维成本；2) 对各业务中台的公共部分进行上抽，统一沉淀至此模块，比如批量处理，让各业务中台的职责更加纯粹，关注自己领域的建模欧易OKEX合约。另外，针对跨多中台的读写逻辑也统一在这一层实现，起到业务流程编排的作用。

2.2 模块结构

上一节从整体视角介绍了合约广告平台的业务架构，这节从微观视角介绍每个中台的业务架构欧易OKEX合约。各业务中台采用多模块的代码结构，具体模块划分如下：

各模块的依赖关系如下：

△模块结构

值得注意的是：

通过上面的应用架构划分，统一了各业务中台的分模块和分包策略，成功降低了各模块的学习和上手成本，较好控制了业务架构和模块代码的腐化程度欧易OKEX合约。同时通过顶层模块的划分，灵活实现了同一代码库多应用部署的能力，从物理层面隔离web服务、定时任务、消息消费、rpc服务，使服务具备灵活按需扩展的能力，进一步提升服务的稳定性。

2.3 服务治理

微服务架构后，服务之间的交互通过网络进行而非单体时代的内存方式，所以整体来说系统会变得更加脆弱，服务治理就是为了解决此类问题欧易OKEX合约。常规的服务治理有四板斧：第一，一定要设置服务调用的超时时间；第二，要考虑重试的逻辑；第三，考虑熔断的逻辑，不要被下游拖死；第四，一定要有限流的逻辑，不要被上游打死。即超时、重试、熔断和限流。没错，这四板斧的确是服务治理中的常规手段，但在我看来，服务治理并不局限于此。我们以终为始，看看服务治理的终极目标是什么？我认为主要3个方面：服务可用性、系统可观测、架构防腐化。

可用性

服务可用性的建设包括系统性能优化、服务自愈和自检能力建设欧易OKEX合约。

服务性能

1.微服务框架升级

服务 RPC 框架整体迁移至部门最新的云原生解决方案 gravity+starlight，取代了原先的 zookeeper+stargate欧易OKEX合约。在服务性能和治理方面有了大幅提升：

通信性能提升：starlight采用新版的网络通信库与更灵活的线程池模型欧易OKEX合约。提升2倍通信交互性能

稳定性增强：starlight基于gravity做更高效稳定的注册中心，定制无损升级、异常实例摘除等能力欧易OKEX合约。轻松赋能达标99.99%+稳定性。

跨语言能力：starlight采用设计更合理的brpc协议作为主协议，可跨语言与C++ Go等brpc服务通信欧易OKEX合约。降低跨语言通信学习成本。

云原生治理：starlight+gravity支持更云原生的治理能力，接入统一控制中心增强可控性、实现灰度发布欧易OKEX合约。

日志规范排查提速：规范化的日志欧易OKEX合约。秒级定位超时问题、序列化失败问题

迁移过程中，gravity 与 zk 双向同步服务注册信息，实现业务的平滑无感迁移欧易OKEX合约。

2.系统性能深度优化

对合约广告系统进行了全面的性能盘点和优化欧易OKEX合约，性能整体提升2倍，总结为如下7个优化点：

单元化欧易OKEX合约，对单个服务进行拆分瘦身（模块结构章节中提到的顶层模块，将定时任务、消息消费与web服务剥离），实现资源隔离，降低等待获取连接的耗时

网络传输欧易OKEX合约，统一团队服务部署至北方机房，平响降低60%

循环IO欧易OKEX合约，IO 包括远程服务调用和数据库操作，通过批量化改造、多线程并发的手段大幅缩短耗时

多级缓存欧易OKEX合约，通过本地 + redis 构建二级缓存，大幅降低读接口耗时

异步化欧易OKEX合约，对于耗时的写操作，采用eventlog组件实现异步化 + 自动重试（后面一节会详细展开），例如物料送审、批量创建投放等

慢SQL欧易OKEX合约，基于业务查询场景，优化数据表索引定义

接口拆分欧易OKEX合约，联合前端，对于非主干流程的耗时数据进行接口拆分，实现非阻塞请求

为了更好的保障系统的可用性，服务需要具备自愈和自检能力欧易OKEX合约。服务自愈能力主要通过幂等处理 + 事件持久化 + 逻辑重试来实现，通过自愈能力的建设，可以大幅降低微服务架构升级后带来的 IO 通信不稳定问题，同时让系统对性能和稳定性较差的外部服务有更好的容忍性，有效提升系统的整体可用性。系统的自愈能力主要解决的是『偶发性』技术问题，比如网络抖动导致的远程调用失败、事务并发导致的乐观锁冲突等，对于代码bug、业务逻辑错误、数据不一致等问题无能为力。所以除了自愈能力，服务还需要具备自检能力，能够将错误自动检测出来，并及时通知到对应人员进行处理。

服务的幂等处理这里简单提一下欧易OKEX合约，不做过多展开，主要有几种方案：

利用 springboot-starter 机制沉淀 eventlog 基础组件，让业务方低成本接入，使服务具备自愈能力欧易OKEX合约。组件整体架构图如下：

△eventlog 基础组件

步骤1是同步持久化事件，由业务方引入组件后调用现成方法实现；步骤2是异步消费处理事件，整体处理流程采用模板模式+ 策略模式，通过模板模式实现处理流程的业务编排，对事件处理前、中、后都设置扩展点，兼顾业务模块的接入成本和扩展灵活度欧易OKEX合约。事件处理采用策略模式，将事件类型做为策略路由，实现各类事件处理的互相隔离和高扩展性。另外通过可视化配置（amis配置，即爱速搭，低代码前端页面搭建平台），统一监控事件日志表，对超时处理的事件进行报警、清理等操作。

事件日志实体模型采用 event_type + biz_code 的二级模型，event_type 唯一标识了一类事件，是事件处理时的策略路由key，biz_code 由业务方自定义，用来唯一标识某类实体欧易OKEX合约。attach是扩展字段，供业务方自定义，attach不宜过大，如果过大，建议通过biz_code后反查业务数据。

自检能力 - 核检中心

服务的自检能力主要通过核检中心来实现，核检中心功能上分两部分，核检任务 + 消息中心欧易OKEX合约。核检任务按业务场景对数据进行核对校验，解决微服务架构后分布式事务造成的数据不一致，同时，端到端的核检也可以做为在线监控，第一时间感知系统bug；然后通过消息中心将异常通知到对应人员。同时，面对大量的报警信息（系统错误、数据一致性、业务正确性等），消息中心做为统一的管理端，提供了按场景分组报警、历史报警信息查询、报警优先级设定、误报热屏蔽、报警群进组热修改等功能，提升监控的有效性和处理效率。

核检中心整体模块图如下：

△核检中心模块图

应用层，两块主要功能，客户端接入和可视化管理欧易OKEX合约。

客户端接入，对于 springboot 应用，和 eventlog 组件相同，通过引入starter，低成本实现报警消息的通知（声明式注解和命令式sdk两种方式）欧易OKEX合约。

可视化管理，通过消息中心控制台，将散布的核检任务进行收拢，大幅提升日程维护效率欧易OKEX合约。同时对于历史消息，可以进行查询，做到消息的可回溯和追踪。

能力层，对应核检中心服务端，整体模块结构遵循上述提到的 COLA，并使用CQRS和事件驱动的设计理念，提升模块的可用性欧易OKEX合约。在消息发送事件的处理模块中，采用策略模式实现多种类型的消息发送，大幅提升模块扩展性，遵循开闭原则。

实体层，按照十亿级别数据量进行模型设计和数据库选型欧易OKEX合约。在实体设计中，抽象消息场景的业务概念，较好的聚合了一类共同特征的消息，『共同特征』完全交由业务方定义，很好的平衡了业务灵活性和消息可管理。在数据库选型方面，采用部门开源解决方案BaikalDB（一个分布式可扩展的HTAP存储系统，采用类spanner的架构，支持PB级结构化数据的随机实时读写）。

系统的可观测程度也是服务治理的一个非常重要目标欧易OKEX合约。提到服务的可观测性，大家容易想到的一般都是：微服务调用关系（拓扑图呈现）、接口性能（各种分位值指标，性能优化利器）、系统异常（各种监控配置）、资源利用率、日志链路追踪（线上排查必不可少）等，这部分主要依托于部门的微服务解决方案 Jarvis平台实现，所以在这里不做过多介绍，这里主要想介绍的服务可观测主要是指上层业务应用。

企业级微服务解决方案Jarvis是商业平台部基础技术团队研发的面向复杂业务系统的应用托管平台，为商业应用提供高可用和分布式的微服务架构解决方案欧易OKEX合约。Jarvis提供了一系列强大的功能，充分利用百度资源虚拟化能力，提供分布式服务框架、服务治理、统一配置管理、分布式链路跟踪、容量规划、高可用及数据化运营等功能。

前面其实已经提到过欧易OKEX合约，合约广告的整体业务链路比较长，经历了售前询价 -> 下单 -> 合同审批 -> 物料制作 -> 投放 -> 计费，每个环节都可能成为广告投放的卡点，如果出现问题，比如流程阻塞，如何能够快速定位问题，甚至提前感知问题，做到整个流程的透明化、可观测呢？

整体思路是以业务实体为中心，记录实体全生命周期的变化，当某个阶段（实体状态）停留时间超出预期，就有可能存在潜在的异常，通过服务看板和消息中心，及时通知对应的运营进行处理跟进欧易OKEX合约。通过追踪业务实体的生命周期，实现系统业务流程的可观测性，为后续流程优化、业务提效提供数据分析基础。

业务实体生命周期的追踪实现方案主要如下图：

△业务实体生命周期追踪

总结来说就是三种方案：

最终我们采用了 1 和 3，业务实体的追踪主要通过方案 3来实现埋点，一些额外辅助信息通过方案 1 进行同步欧易OKEX合约。

防腐化

很多科学家提到的熵增定律非常好的揭示了自然现象的本质：任何孤立系统，在没有外力作用的情况下，其总混乱度（熵）会不断增大欧易OKEX合约。当然软件系统也是如此，随着软件系统的功能不断增加，系统的混乱度也在不断增大。为了降低软件系统混乱的速度，必须要对其施以外力。那么这里的『外力』可以从哪些角度入手呢？

防腐化这块工作其实很重要，目前也还处于初级的摸索阶段，需要进一步结合业务实际，沉淀最佳实践欧易OKEX合约。这里先以微服务循环依赖治理为例，做个简单介绍。

当微服务中的循环依赖形成闭环后会造成2类主要危害：

△循环依赖导致的并发问题

上述图中有两个服务，订单和用户中心，蓝色箭头表示订单中心对外提供的服务，实现订单状态更新，其中会调用用户服务更新客户状态，标记此客户已有下单记录欧易OKEX合约。红色箭头表示用户中心调用订单中心，用户服务在标记完客户状态后反过来会调用订单服务，持久化订单上客户信息。上述调用形成了闭环，最终会引起订单数据库中的版本冲突，导致更新失败。那么如何避免这种循环依赖呢？总结以下几个准则：

2.4 服务迭代

微服务架构改造后欧易OKEX合约，原来单体架构的迭代方式已经不再适用，我们看一个实际例子：

从上述例子中可以看到，微服务架构后，一个业务需求会涉及多个模块，复杂度不尽相同，如果中台服务的每个升级无法做到向前兼容，那么势必会导致需求间的耦合，一旦并行开发的分支增多，因模块间的耦合导致的整体回滚概率将会指数级增长欧易OKEX合约。仍旧是上述这个例子，如果需求1中的中台B有BUG，需要回滚，那么是否导致需求2中的所有模块都要回滚，包括中台D，即使它的改动点非常小。

总结以下欧易OKEX合约，造成上述局面的2个主要原因：

针对这两个问题欧易OKEX合约，我们的解法主要有3个方向：

△mock 中心

其中，服务端的可视化 mock 规则配置支持动态规则，对于一些无法用动态规则描述的需求也可以通过低成本的代码开发实现定制化逻辑欧易OKEX合约。

最终期望能够让每个中台服务达到『自治与隔离』欧易OKEX合约，从而解耦各需求点的上线，如下图：

可以看到，上线粒度从需求维度细化到了中台 fetaure，使整体交付风险指数级下降欧易OKEX合约。当然，对于微服务架构系统，如何做到高效联调和测试仍是一个正在不断探索的方向。

三、总结

GEEK TALK

本文主要介绍了合约广告微服务架构演进中的一些最佳实践，做一个简单的总结欧易OKEX合约。

所以回到本文开头的2个问题，B端系统最大的技术挑战我认为是业务复杂度的治理，通过合适的技术选型在赋能业务的同时又能很好地管控技术和业务复杂度欧易OKEX合约。我心目中好的业务架构标准就是提升效率，这里的效率包括交付效率、运维效率以及演进效率。

最后想说：没有完美的业务架构，贴合业务实际的就是好架构，一个好的业务架构一定是结合业务实际演进而来的欧易OKEX合约。

有奖问卷