【51CTO.com原创稿件】WOT2016大数据峰会将于2016年11月25-26日在北京粤财JW万豪酒店召开，届时，数十位大数据领域一线专家、数据技术先行者将齐聚现场，在围绕机器学习、实时计算、系统架构、NoSQL技术实践等前沿技术话题展开深度交流和沟通探讨的同时，分享大数据领域***实践和最热门的行业应用。
51CTO记者在会前采访了小米公司研发总监欧阳辰，他是小米公司MIUI商业产品部的架构师和研发主管，是此次WOT2016大数据峰会重要演讲嘉宾之一。他的演讲主题是小米程序化广告交易平台(MAX)的架构实践。
【受访人简介】
欧阳辰·小米公司研发总监
欧阳辰，目前就职小米公司MIUI商业产品部，担任架构师和研发主管，主要负责广告平台系统架构，广告交易系统研发和数据平台。之前在微软工作10年，带领团队从事互联网广告和搜索引擎的研发工作，包括负责微软移动上下文广告系统和数据算法，必应搜索引擎的Index Serve的性能提升，最早在甲骨文公司从事数据库的研发工作。
当问及所处团队当前的规模和业务划分情况，欧阳老师这样说：“小米商业产品部目前是百余人的规模，其中大部分为技术人员，整体团队还在不断增长，不断有广告行业技术专家加入我们。研发部门按业务目标划分，可分为媒体方、系统架构、策略算法、广告主服务和数据平台。媒体方组负责媒体变现对接和用户体验，系统组负责架构演化和可靠性，策略算法组负责点击率预估、相关性等，广告主服务负责提升广告主满意度和ROI，数据平台提供数据洞察和营销数据平台DMP”。
小米程序化广告交易平台(MAX)的架构设计思路
关于架构设计思路，欧阳老师谈到架构设计本身就是一种学习和演化，踩坑踩多了，知道哪些地方不能走，也便成了思路。广告平台的设计思路是从几个方面出发：
首先是对于目前业务和未来业务的深刻理解，一直坚信架构是为现在和未来的业务服务的，减少业务变化而引入的成本，在设计理念上更愿意按照业务分解系统，特别是将需求多变的业务模块隔离出来，减少耦合。
其次，架构设计需要和团队的组织方式是一致的，遵守康威法则，例如在平台建设初期，各个业务小组都飞速发展，放马狂飙，那么架构需要提供足够的灵活性。
另外，广告系统对于可靠性要求非常高，不仅仅涉及到用户体验，也涉及到业务收入，因此系统的预警，报警和错误排除都需要大力投入。广告系统也有业务驱动的特点，不同的广告业务可能需要不同的系统架构来支持，因此架构的扩展性和可演化性也是非常重要的，需要支持业务的小步快跑，敏捷式迭代。
小米程序化广告交易平台(MAX)的演化过程以及对应业
欧阳老师表示平台架构的过程实际上是一个演化的过程，每一步演化都是为业务服务的。其可以分为四个阶段，分别是”加、减、乘、除”。
***个阶段是加法，不断的上线新业务，整个系统不断复杂化，结果造成各个业务之间耦合很厉害，在后期，每一次设计涉及的影响都很大。
第二个阶段是减法，为了解决***阶段的问题，系统的解耦成是一项最重要的工作，将各个模块独立出来，服务化，减少各个模块之间的不必要的联系。
第三个阶段是“乘法”，这一阶段的业务发展脉路较为稳定，各个模块分解的比较合适，各个模块（服务）都可以利用各种技术，高速提高服务质量，例如数据处理方面，通过流式处理，大大提高及时性；算法模块在解耦后，也大大提高了算法上线的速度和种类；架构服务化后，系统的容量和可靠性也大大提高。
***一个阶段是“除法”，整个系统变得非常大且复杂，开发人员也有近5倍的增长，部署的机器也有近10倍的增长，服务模块数量也超过20个，这时候架构的调整涉及到一些抽象，按照业务分为服务群，对于离线的数据流也进行了大规模的优化，整合了一些分散的小模块，使得整个系统更加简单。
值得分享的经验是，架构师的工作不是创建一个静态的，美丽的架构蓝图，更多的工作是在成本、质量、收益和速度中找到长期技术投入的平衡，其目标是支持业务的快速发展。
研发过程中遇到的问题及经验教训
谈到经验教训，欧阳老实说开发过程中踩坑是不可避免的，关键是能从踩坑中吸取教训，不要第二次踩到同一个坑。架构设计上，其个人收获到很重要一点就是：架构及演化一定要坚持为业务服务。这部分，他举了两个例子：
其一：一年前刚刚接触这个平台时，当时感觉平台的层次不清楚，各业务之间的重复性很高，很多代码不忍直视，我的***个直觉就是需要一个周全的架构，统一化的广告检索，可扩展的广告检索元语言等，基于这些想法和过去多个广告平台的经验，设计了一个广告演化的目标架构（所谓蓝图），有些模块沿着这个思路开始了重构工作，有些模块并没有重构，沿着老路发展，半年以后，我们再回首当时的决定。当时重构的模块是业务相对稳定的模块，后期的业务并没有从其中得到太多直接好处，虽然代码很整齐，设计很规范，但是投入和产出比很低； 对于没有重构的一些模块，在各个新业务的冲击，打磨和碰撞下，不断的进行自然演化，反而成为最适宜业务变化的模块，回想过来，其中的很多设计都不是当初能够规划出来的，因为很多新业务都未到位。
其二：关于MySQL的，在项目初期使用MySQL一直很顺利，读访问量大了，就采用、读写分离；写访问量大了，就进行垂直拆库（分表）；数据量继续增长，然后进行水平拆库、水平扩展、引入代理层；然后数据量又长大了，不得不将部分数据移植到HBase里去。整个过程中，我们在MySQL折腾了太多的时间，每一次数据库改进都需要花不少人力，而且容易出错，每次的工作成果只能维持很短的一段时间，总结出一个简单道理， 如果有机会再重新做一次，我会更早的拥抱NoSQL的解决方案，避免在MySQL上很多无谓的投入 。
开发和设计“老司机”给入行新手的忠告
每个人都是从新手成长起来的，新手往往是潜力无穷的。我有几点小建议，也是我成长过程中，在多次经历迷惑后的一些体会。首先，要学会确定自己想去的方向，确定自己想成为架构师还是某个领域专家，一旦确定目标了就可以多向周边的大牛学习，看看优秀的同事都是如何思考问题的。 第二，保持学习的热情，计算机行业新技术层出不穷，需要不断的充电，了解***的技术动态。第三，在学习过程中，要坐的住冷板凳，学会渔而非鱼，对于每种新技术，每一类问题，都会有学习的曲线，往往需要经历过一段黑暗的曲线，坚持下去就是光明。另外，在解决问题的时候，尽量了解问题的原理，把问题想透，学会刨根问底的思考。
***，也祝愿刚入门的新手能够享受计算机技术的欢乐和痛苦，这是一条长长的路，道长且阻，行则将至，加油！
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
