导读 ：随着业务和团队规模的增长，原来单体利用的技术架构无论从研发效率还是零碎性能来看，都呈现了瓶颈。微服务化的技术架构革新（遵循畛域模型将现有单体利用依照业务边界拆分为多个微服务）提上议程。本文次要分两块，首先介绍品牌广告投放平台的架构演进；其次，结合实际业务，介绍在践行中台化理念和微服务化革新过程中碰到的问题和解决方案。
投放平台的架构演进
品牌广告投放平台（前身是锦囊平台）于 2011 年诞生，至今已有 9 个年头了，期间技术架构次要经验了 3 次大的迭代演进。1.0 版本基于的是单体利用架构，各产品线的投放均集成在同一个利用中。2.0 版本依据产品线对投放平台进行了更细粒度的拆分，不同的产品线都有独立的投放平台反对，同时形象并下沉公共能力，构建了部门级的根底库。3.0 版本针对 2.0 中的各投放平台，从业务模式登程，以业务模型为边界，定义了 7 大业务中台（资源核心、报价核心、竞拍核心、订单核心、投放核心、数据中心、用户核心），笼罩品牌广告业务的全流程，包含售前、售中和售后。技术架构上采纳微服务化理念，并依靠商业平台大部门的基础设施，高效反对了 10+ 产品的售卖和投放。
上面从技术架构视角具体介绍平台的 3 次迭代演进，以及背地的驱动因素全文 7505 字，预计浏览工夫 19 分钟。
1.0 版本
1.0 版本的诞生是在 2011 年，为了反对品牌专区的售卖和投放，零碎取名为锦囊。随着业务的倒退，品牌广告产品状态逐步丰盛起来，对立通过锦囊平台进行广告投放，模块图如下所示：
不难发现，1.0 版本的一个最大问题是：各产品线的投放都由同一个平台治理，导致系统的开发、测试、上线会影响所有产品线。对于 A 产品的一个渺小改变可能会引发 B 产品的一个 bug，存在牵一发而动全身的危险，同时产品线的相互耦合导致研发效力的升高，随着开发人数的增长，项目管理的难度也成级数上涨。于是，为了解决这些痛点，2.0 版本应运而生。
2.0 版本
如上图所示，和 1.0 版本最大的区别是，各产品线通过独立平台进行投放，开发、测试、上线互不影响，即做到产品线维度的隔离，同时将可能复用的性能最大水平积淀到团队的根底工具库中，防止各业务团队反复开发。然而，随着产品线的增多，发现有很多类似的业务流程（比方售前流程中的询量、询价、词包治理等）并未齐全对立，根底工具库的存在仅仅是代码层面的复用，最多也只是是模块层面的复用。对于新接入的产品线，类似的业务流程仍旧须要反复开发一遍，费时费力。针对此问题，借鉴中台化的理念，将品牌广告从售前到售后的全流程进行了拆解，定义了全局的业务模型，并以此为边界形象出 7 大业务中台，即 3.0 版本，心愿能够实现服务复用，甚至是产品复用。
「复用的不同档次」
根据可复用结构图的复杂性，从低到高顺次划分为：代码复用、模块复用、服务复用、产品复用。
1、代码复用，在此处窄化为函数、办法、或类的复用，代码是复用的最低档次，也是服务质量的基石。复用的代码通常无奈脱离本身服务提供独立残缺的性能，不具备模块的规模
2、模块复用，也叫组件复用，模块是基于性能划分的单位。模块复用比代码复用高一层级，是因为它通常能够提供较为独立的性能。
3、服务复用，这里的服务复用能够分为两种：3.1 将 2 中可复用的模块间接抽离成微服务，独自提供性能。3.2 将被多场景用到的业务能力，抽离为微服务，做为底层业务能力。
4、产品复用，产品是对外交付的最终的成绩，产品复用是我的项目体系内最大水平的复用。较为理论的一种产品复用是指：能够间接设计出可组装的产品模块，通过对模块的组装生成不同状态的产品。
3.0 版本
基于 2.0 版本中的抽离思路，品牌广告投放平台拆分为 一个业务前台 + 7 大业务中台（独立提供服务，即达到服务复用档次），如下图所示：
对 7 大业务中台做个简略的介绍。
1、「用户核心」，积淀用户信息，提供不同角色的鉴权能力，不同账户之间的奴才关系。次要的业务实体是：账户和角色。
2、「资源核心」，对立治理售卖资源，包含产品、频道、页面、广告位的治理。同时笼罩售前流程中的询量阶段，提供资源的询量和锁量能力，库存的查问和抵触校验能力以及词包的治理。次要的业务实体是：资源和流量。
3、「报价核心」，面向内部人员的对立售前治理平台。负责报价的审批流程和资源的价格计算。次要业务实体是：报价单。
4、「竞拍核心」，提供标的的治理和竞价能力。底层积淀了多种竞拍策略（有明拍、暗拍；GFP、GSP；单胜者和多胜者等），满足不同产品线的需要。次要实体是：标的、竞价轮和出价。
5、「订单核心」，提供自建合同治理能力（包含合同创立到导入投放的流程框架、合同状态流转全托管）和资金操作能力（为业务方屏蔽底层资金包的操作细节）。次要实体是：合同和订单。
6、「投放核心」，提供两大类能力，一类是投放层级的治理，包含推广、单元和创意；另一类是物料治理，包含物料的增删改查和内容款式审核。同时对接检索端，将投放层级信息实时同步至检索端。次要业务实体是：推广、单元和创意。
7、「数据中心」，对接部门数据中台，为各产品线提供对立的、多维度的数据查问接口。次要实体是：数据表。
须要留神的是，以上 7 大业务核心仅仅是从业务视角进行定义和划分，并不代表每个核心就只有一个服务。基于技术架构和业务职责，每个业务核心能够持续划分为多个模块，例如投放核心又被划分为 检索适配服务、物料审核服务、试验投放服务等。
微服务化革新
简略总结下 1.0–>2.0–>3.0 架构演进的驱动因素。1.0 到 2.0 最次要的驱动因素是品牌广告产品状态的丰盛（售卖投放逻辑互有差别），为了高效反对产品的售卖，从大而全的单个投放零碎拆分为以产品线为粒度的多个独立投放平台。2.0 到 3.0 最次要的的驱动因素是践行公司中台化的治理思维，最大水平的实现服务级能力的复用，反对产品翻新的疾速落地。
「中台化和微服务的关系」
中台是一种企业治理思维和方法论，微服务是技术架构形式。中台化的落地，须要应用微服务架构。微服务化是践行公司中台理念的一种技术实现伎俩。
单体利用的毛病
在介绍微服务化革新之前，先来看下单体利用的毛病。咱们从研发效率、技术架构、组织构造三个角度来探讨。
5.1 研发效率
研发效率能够从 3 个方面来看，零碎复杂度、开发并发度以及沟通老本。
- 「零碎复杂度」
在团队创立初期，我的项目刚起步阶段，” 单体优先 ” 的办法会更加实用。对于小型团队来说，没必要一上来就应用微服务架构，徒增复杂度。然而，随着业务的增长，零碎的性能会更加简单，一个最直观的点就是业务逻辑。所以如果不及时对系统进行拆分的话，研发人员就要忍耐在一个日渐臃肿宏大的单体利用中进行日常迭代开发，一个渺小的改变甚至会触发陈年老坑。这样的恶性循环就会导致每次预估开发排期的时候研发人员会特地审慎，因为他不晓得可能的影响面，须要花工夫进行评估，研发效率低下可想而知。
- 「开发并发度」
当研发人员集中在一个单体利用中进行迭代开发的时候，很难做到较高的开发并发度。因为各功能模块耦合在同一个零碎中，所以不可避免的会存在串行开发，当然你也能够并行开发，然而须要花更多的工夫去解决各 ci 或者不同分支间的代码抵触，记住：在解决代码抵触的时候要审慎，小心引入 bug。所以，过渡耦合的技术架构，会升高研发效率，这也是为什么很多紧急我的项目不是光靠减少研发人员就能缩短交付周期的一个起因。
- 「沟通老本」
对于小型团队来说，沟通老本很低，很容易就能做到让团队所有成员理解把握零碎，这个时候单体利用的形式运行成果会十分好，这也是为什么简直每个零碎都是这样开始的（锦囊零碎）。然而随着团队的增长，沟通和协调老本会一直加剧，为了让团队内的泛滥研发人员信息共享，就须要额定组织一些会议来做信息对齐，沟通老本的减少间接升高了研发效率。
5.2 技术架构
技术架构也从 3 个方面来看，零碎的高并发（吞吐量）、零碎的高可用（稳定性）、零碎的可运维。
- 「高并发」
高并发指的是零碎的吞吐量，即解决性能。比方询量、锁量、询价、竞拍等业务场景都有对系统吞吐量的要求。然而通常状况下，业务场景对于零碎中的不同功能模块有着不同的性能要求，各功能模块须要应酬的 qps 也有高有低，解决的业务逻辑有简有繁。如果是单体利用，那么服务的程度扩大必然是整个零碎级别的，会造成不必要的资源节约，甚至对于某些模块不必要的扩大，会导致内部服务的压力增大（比方对于数据库的连接数），零碎整体的吞吐量晋升可能不合乎预期。因而，要想进步整体零碎的吞吐量，首要前提是将整个零碎按性能职责进行服务拆分，而后对有性能瓶颈的服务做针对性的优化和程度扩大，补齐零碎中的性能短板，和木桶实践有相似之处。
- 「高可用」
高可用也就是零碎的稳定性，对于单体利用来说，集成了所有的功能模块，零碎的整体稳定性受各功能模块的稳定性独特决定。在非凡状况下，无奈依照服务的重要性做服务级别的降级解决。
- 「可运维」
思考零碎的运维老本，次要指零碎部署老本、线上问题排查老本。一个零碎中的不同功能模块迭代的频率必定是不同的，有些模块绝对稳固（越底层的模块越稳固，离业务越近模块变更越频繁），每次迭代降级只须要上线有变更的服务，如果没有拆分微服务，这是无奈做到的，你只能承受每次上线整个零碎的事实。另外线上问题排查、报警接管、问题修复等场景，微服务化的技术架构老本更小，危险可控性更强。
5.3 组织构造
一般来说，很少会呈现多个团队独特负责一个零碎的状况（沟通老本高，ownership 不明确），当然一个团队是可能负责多个零碎的，即通常状况下，团队和零碎的对应关系是一对多，多对多的状况很少产生。联合品牌广告的理论场景，每个零碎都是一个独立的广告产品投放端，即每个产品会由独立的团队负责，组织构造上是依照业务线进行垂直划分的。当然，这也不肯定不好，在产品孵化初期，须要疾速实现落地，验证想法，这类组织构造的划分是十分正当的。然而随着团队业务的一直稳固，团队间的业务壁垒会加深，如果没有按业务能力（微服务）划分的横向团队，很多业务线间的类似业务组件甚至服务是很难形象下沉，做到复用的。最终的后果是越来越多山头林立，各山头之间某些业务流程又十分类似，再拆分、再交融的老本将会随着工夫的推移呈指数上涨。
微服务化的难点
正如上节所述，随着团队规模和业务领域的扩充，对各零碎进行横向微服务的拆分势在必行，即技术架构 3.0，积淀了 7 大业务中台。在整个微服务化的落地中，遇到了不少的难点，概括来说：
6.1 团队组织架构，每个微服的 owner 是否明确
驰名的康威定律「设计零碎的组织，其产生的设计和架构等价于组织间的沟通构造」论述了架构和组织构造的关系。组织和零碎架构之间有一个映射关系（一对多），两者不对齐就会呈现各种各样的问题。可见，每个微服务都须要有明确的团队来负责，这点须要从上到下来执行。目前大商业通过团队组织架构的调整，每个服务的 ownership 都十分明确。
6.2 微服务拆分粒度
这个难点在品牌广告的微服务实际中解决的比拟好，团队在 cpt、cpm、cpm\_gd 等合约类广告售卖模式上深耕多年，对相干畛域的业务模型有粗浅的了解。因而，微服务的拆分依照投前、投中、投后划分为 7 大业务中台，各业务核心所承当的职责依照业务模型进行边界划分，不同服务负责业务实体的不同生命周期，职责明确、边界清晰。
6.3 自动化构建部署以及可测性
微服务化后，服务数量比原来单零碎要多的多，在 rd 联调和 qa 测试中，不同环境下的多服务部署十分令人头疼。比方要测试某次迭代，须要残缺部署七大业务中台和一个业务零碎，大概波及 10+ 模块。同一时间若有其余业务迭代也须要测试，那么同样须要部署一套 10+ 模块的残缺环境，且不同产品的测试环境须要相互隔离（例如音讯、db 等），如果没有自动化构建部署的工具，手动一一模块部署将消耗大量人力。依靠公司的基础设施能够疾速搭建一套残缺的拓扑环境，反对不同场景的测试需要。
6.4 微服务治理
微服务治理包含服务的变更（包含：公布、降级与版本治理）、服务的发现、服务的健康检查（包含：日志、监控与报警）、服务的故障解决（包含：）等，正如前文所述，整个微服务的治理均托管至部门级的基础设施，在此就不做赘述了。
6.5 微服务和分布式能力紧耦合
上图是微服务体系的逻辑架构，由两局部组成（紫色局部是集成在微服务中的提供分布式能力的共享类库和网络客户端）：
- 内层架构（图中浅蓝色局部），是每个微服务的实现架构；
- 外层架构（图中黄色局部），是构建弱小微服务架构所须要的各种能力，即分布式能力，如服务注册发现、消息中间件、redis 等 key-value 存储、数据库、日志监控追总零碎等。
微服务和分布式能力的强耦合会减少运维的复杂性（如提供分布式能力的各客户端版本）和服务自身的体积（某些微服务自身可能规模很小，然而须要引入的外层分布式能力的客户端相比之下就规模惊人了）。因为微服务的解决方案采纳的是部门级的基础设施，目前一部分曾经做到了无侵入，比方应用凤睛实现了业务无侵入的微服务监控。
6.6 分布式事务
从单体利用革新成微服务化后，势必会引入分布式事务的问题。针对不同的业务场景，次要落地了 2 种解决方案。
同步计划
如图所示，品牌广告下单过程中的典型业务场景，冻款 + 锁库存，在 rpc 的调用过程中可能会遇到如下问题：
冻款胜利，锁库存失败
冻款胜利，锁库存上游胜利（黄色检索端服务），上游超时（蓝色资源核心）
冻款和锁库存均胜利，业务方失败
冻款 + 锁库存的操作次要产生在客户下单的时候，从业务方的视角来看是同步调用服务，其后果会影响到主业务服务的抉择。针对此类执行工夫确定且较短的业务场景，采纳了通用型 TCC 的思维，落地了分布式解决方案 BTCC。下图是 BTCC 的架构图：
异步计划
如图所示，业务场景是客户在公示期交付标的的保证金（T+1 0 点截止），获取竞拍资格，而后 T + 1 的 10 点能够参加此标的的竞拍。对于业务方来说，须要调用两个服务的 rpc 接口，冻款 + 确认竞拍资格。但此类业务场景对工夫上并无实时要求，对于客户来说 T + 1 的 10 点能力感知到竞拍资格，因而能够采纳异步化的解决方案，本地音讯表。同时配上定时工作，监控未被胜利解决的音讯，重试发送，起到了兜底计划。
6.7 RPC 调用代替过程内办法调用
微服务架构革新过程中，在遵循畛域模型将现有单体利用依照业务边界拆分为多个微服务时，往往抉择用 REST 或者 RPC 等近程调用形式简略代替原有的过程内办法调用。
- 在微服务之前：应用程序由多个耦合在一起的模块组成，这些模块通过内存空间进行办法调用；
- 在微服务之后：应用程序由多个耦合在一起的微服务组成，这些微服务通过网络进行近程调用。
抛开调用形式的差别来看微服务化前后的零碎架构，会发现两者简直齐全一样。如下图所示：
而微服务版本在某些状况下可能体现的更蹩脚：因为调用形式更软弱（网络远比内存不牢靠）。而咱们将网络当成“胶水”来应用，试图把扩散的业务逻辑模块（曾经拆分为微服务）依照单体时代的同样形式简略粘在一起，这当然比单体在同一个过程内间接办法调用更加的不牢靠。也就是说，简略用近程调用代替过程内办法调用，服务间的强耦合并未失去改善，反而让调用形式变得更加软弱。
解决方案是引入「事件」（Event），解除不必要的强耦合。联合畛域模型的设计理念，将 Event 了解为畛域中曾经产生的事件：通常意味着有行为（Action）曾经产生，有状态（Status）曾经扭转。RPC 的调用形式更加像「命令」（Command），用于传递一个要求执行某个动作（Action）的申请，代表将要产生的事件。
上面举一个应用 event 机制的理论原理，同时对比 command 形式，劣势不言而喻。
下图是应用 RPC 调用的形式（以进入竞拍期为例），外围业务流程：创立标的 –> 标的审核 –> 标的报价 –> 标的进入公示期 –> 标的进入竞拍期 –> 标的竞拍中 –> 标的竞拍完结 –> 下单
以标的为外围业务实体，标的生命周期的变更做为事件触发源，采纳消息中间件实现事件的播送和订阅，服务间的交互图如下所示：
和 RPC 调用形式相比，服务之间解耦了，不再有循环依赖和调用的状况，做到了「高内聚，低耦合」的设计理念。同时，基于实体生命周期的监控更加天然，任何环节有问题或者提早，都会在第一工夫发现，服务的稳定性和线上运维效率大幅晋升。
业务组件的积淀
介绍完微服务化革新后，再来聊聊中台化实际中，对于某个服务而言，如果做到更好的复用性。这里提出「业务组件」的概念，业务组件是指一类可能被复用的独立业务性能，从粒度上看，能够比功能模块更细。比方竞拍核心比价服务中的标的排序策略；资源核心的询量、锁量性能；订单核心的冻款、冻结性能等。下图解释了业务组件的应用，概括来说，业务组件自身不和产品线间接关联，从组件性能自身来定义边界，即做到高内聚，业务组件定义的越形象，将来复用的可能性就越大。而后在应用层，针对不同产品线拆卸组件，这个步骤能够形象为配置化。
对于业务中台来说，须要反对多类产品线的需要，各产品线之间有类似的逻辑也有本人定制化的，而且对于业务模块来说，惟一不变的就是变动。那么在这种多变且需要不可预知的场景下，如何预知哪些业务能力将来可能被复用，须要形象为业务组件呢？集体认为在理论开发中，不强求一次就能设计出通用的业务组件，而是采纳实用主义的态度，即只对那些须要在多个场景中被复用的能力进行形象下沉，而不须要复用的，就临时放在各产品线独有的解决逻辑中。具体如下图所示（不同的 use case 能够看作是不同的产品线逻辑）：
按产品线隔离和形象业务组件各有利弊。前者能够最大水平升高产品线之间的耦合，各产品线的降级迭代互相独立，升高危险。然而没有深刻开掘产品线之间的共性，和中台化的理念南辕北辙。业务组件的形式更加贴近中台化理念，最大化通用能力的复用性。但同时危险也更大，一个业务组件的性能降级会影响所有产品线，所以对业务组件进行形象和定义的合理化水平间接决定了降级代价和危险。从这个意义上来讲，定期的部分模块重构显得尤为重要。
总结
本文首先介绍了品牌广告投放平台技术架构的历史变迁，从 1.0 到 3.0 版本的演进过程和背地的驱动因素。接着结合实际业务，重点介绍了微服务化革新中碰到的难点和应答形式。最初，在践行中台化理念的过程中，探讨了通用能力下沉的机会和办法，同时联合业务组件的概念，使各产品线在流程独立和能力复用中找到均衡。
————————END————————
举荐浏览：
百度 APP Android 包体积优化实际（二）Dex 行号优化
百度 APP Android 包体积优化实际（一）总览
百度 APP iOS 端内存优化实际 - 大块内存监控计划
百家号基于 AE 的视频渲染技术摸索
百度工程师教你玩转设计模式（观察者模式）
Linux 通明大页机制在云上大规模集群实际介绍