小米程序化广告交易平台的架构实践.docx

小米程序化广告交易平台(MAX)的架构实践

欧阳辰，目前就职小米公司MIUI商业产品部，担任架构师和研发主管，主要负责广告平台系统架构，广告交易系统研发和数据平台。之前在微软工作工作10年，带领团队从事互联网广告和搜索引擎的研发工作，包括负责微软移动上下文广告系统和数据算法，必应搜索引擎的IndexServe的性能提升，最早在甲骨文公司从事数据库的研发工作。

当问及所处团队当前的规模和业务划分情况，欧阳老师这样说：“小米商业产品部目前是百余人的规模，其中大部分为技术人员，整体团队还在不断增长，不断有广告行业技术专家加入我们。研发部门按业务目标划分，可分为媒体方、系统架构、策略算法、广告主服务和数据平台。媒体方组负责媒体变现对接和用户体验，系统组负责架构演化和可靠性，策略算法组负责点击率预估、相关性等，广告主服务负责提升广告主满意度和ROI，数据平台提供数据洞察和营销数据平台DMP”。

小米程序化广告交易平台(MAX)的架构设计思路

关于架构设计思路，欧阳老师谈到架构设计本身就是一种学习和演化，踩坑踩多了，知道哪些地方不能走，也便成了思路。广告平台的设计思路是从几个方面出发：

首先是对于目前业务和未来业务的深刻理解，一直坚信架构是为现在和未来的业务服务的，减少业务变化而引入的成本，在设计理念上更愿意按照业务分解系统，特别是将需求多变的业务模块隔离出来，减少耦合。

其次，架构设计需要和团队的组织方式是一致的，遵守康威法则，例如在平台建设初期，各个业务小组都飞速发展，放马狂飙，那么架构需要提供足够的灵活性。

另外，广告系统对于可靠性要求非常高，不仅仅涉及到用户体验，也涉及到业务收入，因此系统的预警，报警和错误排除都需要大力投入。广告系统也有业务驱动的特点，不同的广告业务可能需要不同的系统架构来支持，因此架构的扩展性和可演化性也是非常重要的，需要支持业务的小步快跑，敏捷式迭代。

小米程序化广告交易平台(MAX)的演化过程以及对应业

欧阳老师表示平台架构的过程实际上是一个演化的过程，每一步演化都是为业务服务的。其可以分为四个阶段，分别是”加、减、乘、除”。

第一个阶段是加法，不断的上线新业务，整个系统不断复杂化，结果造成各个业务之间耦合很厉害，在后期，每一次设计涉及的影响都很大。

第二个阶段是减法，为了解决第一阶段的问题，系统的解耦成是一项最重要的工作，将各个模块独立出来，服务化，减少各个模块之间的不必要的联系。

第三个阶段是“乘法”，这一阶段的业务发展脉路较为稳定，各个模块分解的比较合适，各个模块（服务）都可以利用各种技术，高速提高服务质量，例如数据处理方面，通过流式处理，大大提高及时性；算法模块在解耦后，也大大提高了算法上线的速度和种类；架构服务化后，系统的容量和可靠性也大大提高。

最后一个阶段是“除法”，整个系统变得非常大且复杂，开发人员也有近5倍的增长，部署的机器也有近10倍的增长，服务模块数量也超过20个，这时候架构的调整涉及到一些抽象，按照业务分为服务群，对于离线的数据流也进行了大规模的优化，整合了一些分散的小模块，使得整个系统更加简单。

值得分享的经验是，架构师的工作不是创建一个静态的，美丽的架构蓝图，更多的工作是在成本、质量、收益和速度中找到长期技术投入的平衡，其目标是支持业务的快速发展。

研发过程中遇到的问题及经验教训

谈到经验教训，欧阳老实说开发过程中踩坑是不可避免的，关键是能从踩坑中吸取教训，不要第二次踩到同一个坑。架构设计上，其个人收获到很重要一点就是：架构及演化一定要坚持为业务服务。这部分，他举了两个例子：

其一：一年前刚刚接触这个平台时，当时感觉平台的层次不清楚，各业务之间的重复性很高，很多代码不忍直视，我的第一个直觉就是需要一个周全的架构，统一化的广告检索，可扩展的广告检索元语言等，基于这些想法和过去多个广告平台的经验，设计了一个广告演化的目标架构（所谓蓝图），有些模块沿着这个思路开始了重构工作，有些模块并没有重构，沿着老路发展，半年以后，我们再回首当时的决定。当时重构的模块是业务相对稳定的模块，后期的业务并没有从其中得到太多直接好处，虽然代码很整齐，设计很规范，但是投入和产出比很低；对于没有重构的一些模块，在各个新业务的冲击，打磨和碰撞下，不断的进行自然演化，反而成为最适宜业务变化的模块，回想过来，其中的很多设计都不是当初能够规划出来的，因为很多新业务都未到位。

其二：关于MySQL的，在项目初期使用MySQL一直很顺利，读访问量大了，就采用、读写分离；写访问量大了，就进行垂直拆库（分表）；数据量继续增长，然后进行水平拆库、水平扩展、引入代理层；然后数据量又长大了，不得不将部分数据移植到HBase里去。整个过程中，我们在MySQL折腾了太多的时间，每一次数据