放翁（文初）的一亩三分地

         淘宝越来越大，公司内部有很多部门和子公司，之间最有效的合作方式就是通过TOP平台低耦合的集成淘宝基础服务能力。同时，如何将淘宝的能力和电子商务的能力渗透到传统行业的方方面面，如何结合各种终端来展现给不同层次的用户，都需要将服务以不同的方式集成到已有的形态各异的系统或终端中。但到发展到今天的情况来看，在普通开发者这块的成长是低于预期的，这类应用现在创新力度很低，大部分人都开发收益较快，投入较少，开发维护成本较低的淘客类应用。国内的开发者真的需要多学习国外的一些Mashup的创新精神（也许是国外的API资源丰富），淘客类应用，卖家工具，其实这些应用饱和程度十分高，同质竞争激烈，最后能够给开发者带来的收益当然也很低。

系统透明化

         今年我们团队的定位是服务化团队，我们需要去探索新的模式，关注新的技术发展，但是最根本的是要做好当前，服务好我们的客户，系统透明化就是服务化团队的基础。系统透明化的作用是什么，拿过去卖跌打膏的一句常说的话：“有病治病，无病防身”（没有问题的时候知道可能那些地方已经处于非正常状态或者可以找到一些瓶颈所在，在出了问题，可以迅速防止问题扩大，高效的解决问题）。对于开放平台来说，服务可用性和服务效率其实是最更本的非业务性需求，当一次请求2-3秒才会返回，请求10次有4次是不通的，那么后面的服务就算再吸引人，都很难让开发者做出吸引用户的应用。说一下我在做这块的几点收获：

1.       数据为王。最初透明化的工作就是分析每天的访问日志记录，得到系统数据统计报表和业务数据统计报表。通过系统数据统计报表的结果来找到系统的瓶颈，通过业务数据报表来指导业务规划。例如分析整个服务安全校验和路由过程，最消耗时间的就在服务请求解析上，因此就考虑如何去减少服务解析带来的系统消耗：Lazy Parser通过采用流的方式分段解析参数，当发现系统参数校验失败时将不再继续分析整个Http包，减少在错误情况下由于载入全部数据带来的损耗。同时参看Jetty的Continuation的设计，学习在基于事件模式下，如何最小化连接资源分配（复用资源，带来的问题就是复杂度增加）。另一方面，发现淘客类应用对于服务的请求会反复调用多个接口来拼装成为一个完整信息，因此优化了淘客类服务，使得应用大幅度减少访问请求，减少无谓的系统压力，提高外部应用的效率。简单来说，啥都需要数据说话，最怕今天跑过来和我说我们要重构和优化了，但是又无法说出为什么这就是我们的瓶颈，优化完有啥指标可以证明有效。只有在系统透明化以后，数据能够说明一切。优化需要从全局去看，而不是局部，并行处理提高了非关键路径的性能，没有什么太大的意义。

2.       按需设计，抽象分层。在最初的时候，透明化的目标通过一个单机版的报表分析器就可以完成。（一天6千万条的访问日志，3个多G的文件，系统报表3-4张，业务报表5-6张），逐渐数据量不断膨胀（一天5亿左右的访问日志，8-90个G的数据文件，系统报表和业务报表常规就有20张，还有不少零时的需求提出），因此演变成为一个多机版的报表分析器，与此同时，每日一次的分析不能满足对于业务系统即时的监控和告警，因此多机版的报表分析器，支持非静态文本数据源的方式，Slave不断主动从应用服务器端增量获取日志数据，演变成为一个即时分析系统。

但整体结构如下：

                                               

           整个体系的演进只影响到任务管理组件和数据传输组件。在单机版的时候，数据传输组件不存在，都是多线程之间的任务分配和数据合并。多机版就是增加了数据传输组件，业务性统计规则引擎都采用已有的抽象设计。即时分析系统则在任务管理组件上扩展了数据源获取的方式。

           首先我并没有直接去考虑多机版的实现，因为我的设计可以满足当前的需求：灵活（基于配置在运行期创建规则分析各种弱数据类型的日志），高效（任务切分，多线程并行计算分析）。最重要的是在短时间内给出了一个可用的版本，解决了当务之急。（很多时候就是要权衡时间和设计，不断的迭代产出阶段性成果，才能够降低风险，不断提升成熟度，通过反馈指导设计的方向）。其次，整个演进过程中，业务抽象设计部分一直保持较为稳定的状态，将底层的任务管理和传输不断的根据需求去扩展和优化。（这其实就是要求在设计上有分层的思想，业务领域的设计需要与非业务性需求分开考虑，便于扩展，同时降低不同层次的耦合度，增加未来多系统复用的可能性），下图是当前即时分析的一个简单的部署图：

                                               

Master的工作很简单，就列出的4步。Slave是一个纯粹的“劳动者”，根据Master给的任务去执行分析。（任务中包括了资源的来源描述，可能是静态文件系统（ftp，分布式文件系统）等，也可能是一些应用服务器。任务中也包括了分析规则引擎数据）

客户第一

         今天在业务统计分析中，淘客应用占有的比例很高。为什么？开放平台需要让开发者“简单的赚钱”。“简单的赚钱”，两个词说明一切，投入少，回报高，站在开发者角度多考虑一些问题才能够指导ISV去开发出更多更有价值的应用。当前通过API来开发应用成本较高，同时周期也较长，因此针对这些问题，TOP平台有在业务创新上的一系列规划，降低应用开发者开发和维护成本，让开发者更多关注在业务创新上，而不是基础服务的使用上。如下图：

                            

         从服务的使用者和服务的提供者两方面去提升用户体验，在某些时候工具类或者辅助类的服务并不仅仅是锦上添花，它可能成为产品化成败的关键点。（细节决定成败，老生常谈），但是实际中需要去了解和体会用户的需求，一来自己就去用API开发，二来从业务分析数据上来分析不同用户群的行为和趋势。

平台要死，哪里会是致命的一击

         几周以前，整个TOP的技术和业务团队的部分同学在西溪湿地开了一个会议。目的是让大家说出自己工作中的问题和难处，同时为将来的TOP发展明确方向。其中提到了整个阿里巴巴和淘宝都会找自己失败的问题所在，因为只有你自己知道了自己在什么情况下会失败，才会去改进自己的不足，避免走到无可挽回的地步。

         TOP如果要死，那么什么是它的致命一击？对我来说，如果每个人心里少了产品化的理念，那么TOP就会失败。产品化意味着什么，对研发人员来说，意味着你每一个技术实现都需要清楚的理解它背后的商业需求和客户需求，在PD和运营同学提出想法的时候需要从一个客户的角度多考虑易用性，扩展性。（简单来说，不要做一个“死”写代码的，做个临时演员都要有职业素养，做一个程序员更要有程序员的“修养”）对于一个PD来说，需要协同技术团队做好产品规划，用数据来指导产品设计，用技术提升用户体验。（简单来说，除了多说，更要多听多看，开发团队也有很多同学对商业和产品有自己独到的见解）。对于运营团队来说，要将用户的声音“过滤”并“转化”，让开发和PD能够收取到更多有用的信息。

         因此，TOP要死，前提是在每个人心里面“TOP”已死，我记得凤先同学一直说一句话：“每个人心中都有一个TOP。”当大家心中的“TOP”不死，产品化思想不死，那么TOP就总会有希望，因为TOP就是我们这么一群人不断奋斗的目标。

太累了，搞完代码再写blog，很多东西可以写，不过实在吃不消……，有兴趣想了解细节的同学可以直接和我联系。