淘宝构建开放平台的技术历程(2)

　　另一方面，Hadoop的MR问题也日益突出，一大堆MR的class维护成本高，性能问题也随之出现。此时我们开始尝试抽象分析业务场景，想到的是是否能够通过配置就可以完成各种统计分析需求。要用配置替代code，其实就看是否可以穷举code所实现的各种统计需求。当回顾SQL的理念时，发现其实所有的统计在切割成为KV作为输入输出时，所涵盖的需求无非是max,min,average,sum,count,distinct(这个是12年实现的，用了bloomfilter和AtomicLong)，再复杂一些无非就是上述几个操作结果的数学表达式运算，因此KV输入和KV输出的离散统计配置需求已经抽象出来了，接着就是把统计完的一组组KV根据K来做Groupby，就生成了传统意义上的报表。(K，v1,v2…)从此以后，每天的统计需求都通过配置来改变，再也没有一大堆MR代码，同时一次数据输入就可以完成所有分析的处理，性能上得到了极大的提高。(后话，当后面有人推荐我们去看 hive，pig的时候，我们发现原来路都是这么走过来的)

　　虽然Hadoop每日分析抽象出模型配置解决了性能和易用性的问题，但是对于即时分析却不太适合，当时出于监控的需求，希望能够一个小时就可以对数据做一次增量的分析，用于监控服务整体的调用情况，保证对异常问题的即时排查。由于一天4000w的量还不算很大，因此当时就直接考虑采用Mysql分库分表的方式然后定时的去做SQL的查询，结果发现效果不错。当然这个过程又产生了一个小组件，要直到4000w的日志数据写磁盘和DB双份必然会带来不少的IO 消耗，同时这个系统并不是帐务系统，丢掉一点日志也没关系，因此就采取了异步批量数据外写的设计(多线程守护各自的一块Buffer页，定时外刷或者满页外刷)，这样在双写的情况下，单机的Load也没有超过0.7。

　　但快到年底的时候，发生了一件事情让我们头痛不已，同时也成为了开放平台的一个“隐形炸弹”。一天晚上，突然发生平台大规模拒绝服务的告警，半夜爬起来观察了一下整个集群，发现业务处理时间从平均的30-40ms，上升到了1s，仔细观察了一下，某一个业务的响应时间大幅攀升，从原来20ms的响应时间飙升到了1s以上，此时由于Http请求的同步性，导致前端服务路由网关的集群线程都释放的非常慢，阻塞处理这个业务的请求，而其他正常的业务(淘宝开放平台背后的服务是不同团队维护，处理时间从1ms到200ms都有)也无法被访问，因此才有了开始的全线告警的产生。当晚后面发现是这个业务团队的一次发布中忽略了数据库索引建立导致服务耗时增加，但这个问题开始时不时的来拜访开放平台，开放平台稳定性受制于任何一个业务方，这是不可接受的～～～对于这个问题，起先考虑集群拆分，将重要业务和不重要业务拆分，考虑到实施成本(不同服务的利用率差异很大)和业务隔离是否彻底(重点业务也会相互影响)放弃了这个想法。当时又想到了软负载切割，Haproxy和LVS，一个是七层的网络软负载切割，一个是四层的负载切割，由于涉及到业务，于是还是考虑走七层的软负载切割，尝试一台Haproxy挂7台虚拟机，然后运行期可动态调整配置在出现问题的时候可人工干预切割流量。就这样，我们有了告警以后可以手动切割的半人工方式干预措施，起码不在心惊肉跳时手足无措了。但我们依然晚上睡不踏实… (期间考虑过Web请求异步化，Servlet3的模式来规避同步Http带来的平台阻塞，但当时唯一支持Servlet3的jetty和 tomcat做压力测试，效果都很不稳定)

　　10年：平台化。这一年到年底，平台开放淘宝服务300多个，每天调用量8亿，这一年淘宝正式开始对外宣传开放，淘宝开放年，赢在淘宝，很多今天年收上千万的TP在这个时候成为了先锋(10年以前的可以叫做先烈)，产品层面上，这一年除了卖家工具的继续发展，SNS热潮的兴起带动了淘江湖的买家应用，游戏应用的淘金者蜂蛹而入，开放的服务也继续保持300%的增速，覆盖面从卖家类延伸到了买家类，从简单的API提供，到了淘宝网站支持深度集成应用到店铺和社区。

　　8个亿的访问量下再用Mysql做流式分析已经不靠谱了，分析时间要求也从一个小时提升到了20分钟，此时经过快1年半的Hadoop使用和学习，再加上对分布式系统的了解，正式开始写第一版的流式分析系统，MR的抽象依旧保留，而底层的数据计算分析改用其他方式，这个“其他方式”和Hadoop的差异在于：1.分析任务数据来源于远端服务器日志。(主要通过pull而非push)。2.任务分配和调度采用被动分配(有点类似于volunteer computing的模式)，mater 轻量的管理任务，slave加入即可要求执行任务，对任务执行的情况不监控，只简单通过超时来重置任务状态。3.任务统一由Master来做最后的 Reduce，Slave可以支持做Shuffle来减少数据传输量和Master的合并压力，Master负责统一输出结果到本地。总的来说就是数据来源变了，数据不通过磁盘文件来做节点计算交互(只在内存使用一次就丢掉了)，简化任务调度，简化数据归并。这样第一版本的流式分析出来了，当然后面这些设计遇到的挑战让这个项目不断在演进，演进的各种优化几年后发现都在hadoop或者Hive之类的设计中有类似的做法。(参看一下文章最顶部的blog地址根据时间轴可以看到各种结构优化和性能优化的过程)这个系统3台虚拟机抗住了8亿的日志即时分析，Mysql日志分析就此结束。

　　这一年另一个重大改变就是更多人对开放的价值有所认同，淘宝从一个部门的开放走到了淘宝公司的开放，什么叫做部门开放?就是在10年以前大部分的API开放都是开放平台这个团队来做封装维护，30个api还可以支撑，100个api已经让一个专业的小团队应接不暇(当然不得不承认，迄今为止淘宝最有全局业务知识的还属这个团队的成员)，300多个api这种势头基本上就无法由一个团队来作了，业务变更带来的接口不稳定经常被投诉，因此我们启动了服务轻量化的“长征项目”，逐渐通过工具和平台将服务接入变成自动化的方式，将原来开放一个服务需要点对点，手把手花一周时间实施完成的过程，通过自动化服务发布平台，一个人一天时间就可以发布一个服务，并且服务的文档，多语言版本SDK都自动生成。这样就具备了服务轻量化的基础，然后将各个新开放的业务采用这种模式接入，而老业务逐渐的归还给各个业务方去维护。这样一来，服务的“稳定性”(业务方面)得到了非常大的提升，用户对于服务的满意度也得到了极大的提高。

原文转自：http://www.ltesting.net