导读
从事B端业务系统研发多年，不免会有这样的思考：B端系统的技术挑战是什么？什么样的业务架构算好架构？本文结合百度合约广告业务的发展历程，介绍广告投放平台从单体架构到微服务架构演进过程中碰到的问题和思考。希望通过本文的介绍，让大家更全面的理解B端系统的技术挑战。
全文字，预计阅读时间0分钟。
一、背景
1.1合约广告概念
合约广告相比竞价广告，最大的特点是预先约定好广告价格，即价格是预先确定的。基于这样的特点，合约广告的投放流程大致可以概括为四个步骤：询价-下单-投放-结算。
询价，销售根据客户的营销目标选择合适的营销产品，并提交具体的投放定向和时长，系统结合销售政策，自动计算产出各资源价格
下单，客户按照1中的报价结果，确认需要购买的资源和具体的付款方式，完成下单后生成订单，每个订单的金额是确认的
投放，2中的订单完成审批后，系统按照事先约定的价格进行广告投放，客户在投中可通过系统进行投放和创意的管理，并可以实时获取投放数据
结算，合约广告按照投放模式分为按时间计费和展现量计费，两种计费方式的频次都是天，最终实现在投放周期内逐步地扣除订单全部金额。按天结算是对已产生投放部分的权益保障，毕竟合约广告存在更改甚至退款的场景。
通常来说，合约广告这种广告采买方式更适合品牌展示类广告，效果类广告更多会采用实时竞价。相比竞价广告，合约广告在业务流程上更重投前。下面结合品牌广告业务发展的三个阶段，介绍下投放平台的变化历程。
1.2业务发展
第一阶段，品牌广告业务高速发展期
年，品牌专区产品开始平台化售卖，并逐步建立品牌投放平台：锦囊。在-86年间，品牌业务高速发展，诞生了Ax、Bx、Cx等10+条产品线，虽然锦囊平台做为投放的统一入口，但各产品线的投放能力仍旧是独立建设，拥有各自的独立投放平台。在这种模式下，快速灵活地应对了市场的变化和需求，但同时也造成了投放平台多，业务流程割裂的问题。
第二阶段，寻求产品整合和流程统一
9年开始尝试对合约类平台进行整合，统一各产品售卖流程，包括产品线关停并转、投放平台融合、账户统一、资金池统一、标准化下单等项目。逐步落地合约广告一站式平台的建设-天启平台，真正实现合约广告的标准化投放流程，提升规模化投放效率，支撑业务发展。在这个阶段，各广告的投放平台入口逐步收敛，实现了操作入口的统一。
第三阶段，满足复杂营销场景，整合营销
随着合约整合售卖（根据营销场景选择不同广告产品的组合售卖方案，即同一个合同下可下单多类广告，并享有对应的优惠政策）整体趋势的加速增长，原本非标断点式的支持方式已经无法满足业务的增长，平台化的解决方案是整合售卖规模化的必要条件。从年Q起正式启动，天启平台正式定位：统一的合约产品整合售卖平台，满足从简单场景到复杂营销场景的全投放链路服务能力。从技术视角看，旨在通过一个平台（天启），实现多资源广告售卖场景下的统一，包括一个流程、一套账户、一套资金体系、一套投放表达。
1.架构演进
对应上述业务发展的三个阶段，合约平台的技术架构也经历了多个版本的演进，浓缩后，可以概括为2大类，9年前的单体架构和之后的微服务架构。
单体架构
9年前的单体架构（简称『1.0架构』）图如下所示，整体上分三层，1）统一入口层，提供用户权限管理功能；2）各类广告投放平台独立建设，服务独立部署；）抽象并沉淀基础工具库，避免各投放平台的重复开发。
△1.0烟囱式架构
品牌1.0架构本质是一个烟囱式架构，各产品线通过独立平台进行投放，开发、测试、上线互不影响，都能做到产品线维度的隔离，包括开发规范和迭代周期。这种架构配合当时品牌团队的组织架构，在品牌产品野蛮式生长的初期起到了很重要的作用，成功孵化了一些创新产品。但是烟囱式架构一个很大的弊端就是『信息孤岛』，随着业务的发展，各投放平台发散式迭代，逐步形成了一个一个的孤岛。从技术视角看，各平台大流程相似，但在实现细节上都不同，更严重的是，存在大量的重复性建设工作，从维护成本和人效上都有很大的优化空间。从业务视角看，各产品的打法也是各自为阵，横向缺少联动，没有形成1+12的局面，缺少整体视角的规划。
微服务架构
业务方面，合约广告场景化营销和精细化服务的需求显著；团队方面，各合约类广告平台深度融合，孤岛边界逐步打破。原本烟囱式架构无论在业务复杂度的应对，还是服务稳定性及质量的保障，亦或是研发效能的提升，都已经遇到了瓶颈。基于软件设计的最大目标：『设计符合业务的构造定律的演进方式，一种可以以最小的开发维护成本，使业务更快更好的流动发展的方式』，19年后，合约平台架构逐步向微服务架构演进，以领域驱动设计为准则，按照合约广告的领域模型划分微服务，构建了业务前台、业务中台、技术组件、基础设施的四层业务架构。另外，基于消息机制解耦各服务，辅以组装式业务流程的理念，拆解各种繁杂的业务流程，抽象并沉淀系统的metafeature，灵活构造多种差异化的业务解决方案，提升系统的『可玩性』，从架构层面管理了系统风险和业务复杂度（百级别不同类型的售卖和投放场景）。
说到这，有些人会有疑问，对于品牌业务，微服务架构演进是否是必须的呢？是否存在过度设计？
当然，假如不考虑性能、健壮性、可移植性、可修改性、开发成本、时间约束等因素，用任何的架构、任何的方法，系统的功能总是可以实现的，项目总是能开发完成的，只是开发时间、以后的维护成本、功能扩展的容易程度不同。从后验来看（包括系统可用性、扩展性、灵活性三方面），采用微服务架构的决策是正确的，或者说利远大于弊。
在架构的演进过程中遇到了很多技术挑战，后面的内容重点挑了几个方面进行详细阐述。
二、技术实现
2.1服务架构
首先，整体看下合约广告平台的微服务架构，如下图：
△合约广告平台微服务架构
总共分为四层，业务前台、业务中台、技术组件（PAAS）、基础设施（IAAS）。
业务前台，总共分三个模块，天启平台、运营平台、业务前台。
天启平台：面向广告主，提供合约广告询价、资源预订、资源下单、投放设置、物料制作等核心能力，支持品专矩阵、展示矩阵、品牌全景大类产品矩阵，多达00+广告资源的售卖。
运营平台：面向销售和内部运营，帮助他们精细化运营广告售卖各阶段，目前售中的投放干预和运营管控能力建设相对完善，在开屏大促和品牌广告日常运营工作中大幅提升操作的效率和安全性，让原本一些『非标』操作通过平台能力让运营实现自助化。
业务前台：主要两个作用，1）对天启平台和运营平台的公共部分进行抽象并下沉，避免重复的业务逻辑和流程散布在两个模块，减少开发和运维成本；2)对各业务中台的公共部分进行上抽，统一沉淀至此模块，比如批量处理，让各业务中台的职责更加纯粹，