开放平台两三点感悟

有淘宝的同学在旺旺上和我说，你最近很少写blog了哈，是不是忙着照顾孩子啊，我尴尬的笑了笑。是的，照顾“小孩”，自己家的小孩和开放平台这个小孩。以前人家说，三十而立，我今年虚岁33了，儿子就快能够“立”起来了，一直想写点技术和生活的体会，但是总少一些冲动。今天就下面这张图，让我突然想写点什么。

 

看到一篇文章的这张图，立刻在新浪“围脖”上晒了一把，留言道：“骑车运动中，稍后解释”。结果同僚回应道：“不用解释，一目了然”。其实如果真的就这些数字，的却是一目了然，但是如果你经历过开放服务的发展的话，其实这些数字仅仅只是现在的一个快照，你能看到的也就是现在的一个现状，对比昨天，才能知道今天的数字发生了什么变化，将来意味着会发生什么样的变化。

08年初，Ben的一句“两周能搞出一个雏形来，两个公司就合作开放服务”，我就误打误撞的开始研究和构建开放平台。当时国外Yahoo算是有一个像样的开放平台，Flickr API是Yahoo开放平台使用最广泛的服务，在服务开放流程，安全性和服务接口设计上成为我设计借鉴的范例。但这仅仅是开始，要开放，其实有着更深层次的要求。看看下面两张服务市场占有率的图，比较一下08年和10年的情况

 

08年中旬 2010年

Amazon PAAS类的服务，今天已经成为服务类型中占据第一位的服务，Social服务也随着Facebook占据了第二位。最近又开始热炒地理经纬的服务，其实就是Map服务的一个演变。上面的变化其实可以发现两点：

1. 技术的成熟使得PAAS的服务在高门槛背后成长的更加快。

2. 业务的成熟也会推动开放服务的不断发展，因为开放的目的就是用最简单有效的技术方式来实现业务创新。

上面的图片和信息都是来自于一篇关于GlueCon大会的报道，Glue？没错，胶水，我记得最近几次在淘宝技术大学介绍开放平台的技术体系架构的时候，都谈到快餐式的应用构建方式。在互联网创新需求的推动下，需要利用类似于麦当劳的快餐方式来Glue那些面包，生菜，牛肉快速满足用户需求变化。淘宝当年把线下开店搬到线上来，最终吸引客户的是什么？低风险，小投入（今天就未必了），尝试创业。今天要做一个互联网应用，是否也能够类似的有一个平台，不需要再关心域名，站点，推广，基础服务，那么就需要不同层次的服务提供商，从PAAS，到数据服务提供商，到流程服务提供商等等。

看看GlueCon的首页写的一些技术点：

一些老面孔，一些经历过的事，后面将讲述自己在做开放平台的经历，我只是一个技术人员，分享的也就是技术学习的过程，没有创业的辉煌，没有专家的深度，有的就是一些感悟。

雏形

ASF，嗯，没看错，不是apache软件服务联盟，是应用服务框架。当你第一天觉得你要开放内部服务的时候，就需要审视一下你的后台架构体系，是否是能够开放的。也许有人会觉得开放无非就是将一些API封装一下以Http的某种方式暴露出去。对，“暴露”，当你内部就只有一条“遮羞布”的时候，一旦被人扯掉，你就真的暴露了。

因此，在阿里软件早期做SAAS的模式下，希望对内部架构做一次完整的服务化改造。其实今天的淘宝在开放初期也是经历了服务化改造的。服务化改造，在当时我学习的是OSGI和SCA两种框架模型，在模块化理念上两者基本上是一样的设计思路，但是OSGI在我看来更加适合应用模块化而非架构体系的服务化，因此在开源项目Tuscany 0.91版本的基础上构建了适合于开放服务体系的ASF，基于配置将业务模块化，服务的依赖和发布通过模块来申明。（其实到了Tuscany 1.0以后很多实现就是ASF定制改造的功能，具体对ASF感兴趣的可以看看我blog以前的说明，源代码估计随着Alisoft的结束而消失了）。模块化的推行并非一帆风顺，很简单，不论是开发人员和架构人员对于框架约束模块化的开发模式并不是很适应，同时由于框架本身也在不断成长，总会受到一些抱怨。其他不多说，这个阶段学到的几点：

1. 多一些业务性的指导要比冷冰冰的技术文档来的更有利于框架的推广。（很多时候模块化最大的问题就是粒度，拆分过细，导致依赖复杂，调试成本大，拆分过粗，服务隔离效果差，模块化作用淡化）一句话，没有不好的技术或者框架，只有不适合的技术和框架，任何好的技术和框架都要知道什么时候怎么用，不然就好比期望要一个能医百病的灵丹妙药一样不靠谱。

2. 邀请参与好过自上而下的推广。老大起先可能会很支持的帮你去自上而下的强制推广，但是任何一个产品或者框架的成熟需要使用来反向驱动改进，因此邀请更多的人参与，会让后期由被动转为主动。（这点说起来比较容易，但是做起来比较难，因为很多技术人员喜欢自己创造成就感，就算和别人一样挖同样的洞，深1cm也算是种成就感#_#）。不过在淘宝这边，感觉氛围还不错（不是广告，呵呵），有人愿意参与，有人愿意学习。简单来说这里的人有产品的观念，而非简单的技术观念，满足用户需求是基本，把自己的力气用在自己最擅长的地方，其他的借鉴或者使用兄弟团队的技术和产品。

SOAP到REST。最早SAAS平台采用的是Web Service的方式来对外开放服务，原因是WS有成熟的多语言体系框架，同时WS配套的WS-Security是安全的基础保证。因此服务化都是采用WS的方式，身份认证也采用X.509证书的方式来认证，当然当时也采用平台颁发X.509证书（没有搞授权中心去授权），并且将证书内容保存到数据库和内存中，便于校验。但这个过程中，我们认为成熟被多语言支持的WS，却给我们搞了很多麻烦，.net和java及php对于SOAP的理解在细节上还有很多偏差，特别是对复杂的对象类型，当然在证书上.net的技术专家一起陪着我们搞了许久，最后还是我们自己通过比较蹩脚的办法绕过了问题。

逐渐的将服务都转变成为REST的方式，轻量化的服务体系对于服务发布者或者使用者来说都是一种解脱。下面的图是当前REST方式和SOAP方式的使用量对比：

 

学到的：

1. 啥都要靠自己去实践才知道是不是真的靠谱。

2. 作对了99%是应该的，但是1%的问题没有处理好，那么就会降低用户体验，因为用户容易看到问题，而正常服务是被认为理所应当的。

成长

服务差异化。随着服务平台的成熟，接入的服务也各自呈现出他们的特点，一成不变的Http请求相应的交互服务模式在业务和性能上不能满足需求。类似于短信服务的异步消息，RSS类型的订阅消息，就需要平台支持异步回调。大数据量的服务（视频，文件上传下载），如果在经过服务平台中转数据流，就会导致带宽浪费，因此需要将安全校验和业务交互流程分离。

服务安全体系的变化。WS-Security到简化的OAuth 0.1 。没看错，OAuth0.1的简化版，那个年代什么东西都是新的，就和前面谈到的OSGI，SCA，OAuth等等，因为国外的服务体系也是这一年半发展起来的。现在很多网站都标榜自己支持OAuth，支持Open ID等等，但其实去看看Google，Yahoo的大量API的安全体系，其实都是做了定制化，原因很简单，就是要在安全的同时尽量降低复杂度，提升可用性，多一次交互就会带来不稳定的因素。TOP和以前的阿软开放平台都是采用了一次令牌授权的方式，而OAuth则是采用了2种令牌，3次交互。其他优点没看出来，不过将安全信息放入到Http头中确实很好。我记得上次回邮件的时候说：“如果能够让我重新做一次协议制定，那么我会让平台安全逻辑完全无侵入业务协议”。一来保证业务协议的无侵入，二来在性能方面来说消息头的处理会极大降低异常服务判断及丢弃的应用系统资源损耗。

服务分流与隔离。很多技术我在以前的blog中都有描述，因此这里也就轻描淡写的说一下。后端服务者看来服务开放平台就是为他一家服务的，但是其实所有的服务在服务开放平台上是对等的，而服务当前多数以Http的应答模式开放，当后端服务处理出现问题时，那么服务平台的前端资源将被耗尽，间接影响到了其他正常的后端服务，因此需要对服务能够做分流和隔离。这里学习了LVS和Haproxy的设计理念，在四层以简单的ip分流做对应用粗粒度的保护（大ISV有固定的一些ip），在七层两方面通过URL的服务名称做服务分流，再通过集中式缓存协同集群判断后端服务的可用性，在必要时部分切断中转，来保证其他服务的可用性。

Memcached成为基础组件。高速系统必须要有缓存来支持，因此当时选择了刚刚被推出广受好评的Memcached，系统运行期的服务访问控制和服务路由都靠集中式缓存来支持。但是集中式缓存最大的问题就是如何容灾，数据丢失就去数据库取，那么就会导致一些攻击使得系统奔溃，因此只能让集中式缓存有类似于服务器一样的HA冷热备份。考虑在服务端做基本不靠谱，一来我不熟悉C，二来如果在服务端做，那么就会演变成为分布式缓存，分布式缓存最大的问题就是数据一致性的问题。（几阶段提交，数据节点分区等等，复杂的设计带来的就是可用性和效率的降低，CAP就不再赘述了，看见几个缓存或者NOSQL的设计者一直都在谈CAP及RWN数值关系的问题）因此变相考虑实现客户端来支持集群，客户端支持集群很简单的思想，就是多放一份，但是需求是，不影响效率（因此多放一份就不应该同步做），也要保证简单的数据一致性（根据算法优先获取或者存储固定节点数据，即同等节点在客户端来看不等同）。因此就搞了一个Memcached的客户端组件，本来只是希望做客户端集群效果，不过看了原始的BIO的效率不高，就顺带优化了一把，不过后来我现在的同事用NIO又做了一版。（NIO早期不适合用于老版本的Memcached协议，因为没有会话码）

服务流控。资源不收钱，那么自然不用白不用，因此有很多应用疯狂拉数据，从阿里软件的角度或者淘宝的角度都是不希望这样的情况发生的，因此出现了服务流控。对应用的频率和总量控制，一来保证了应用本身不会因为程序问题击垮后台服务，二来也提供了应用的层次设计，为应用良性成长奠定了基础。（当然商业上也有更多的想象空间）

以上都是自己还想得起来的一些技术点，感悟到的内容如下：

1. 量体裁衣，适用就好。有时候在做设计的时候容易陷入盲区，总认为流程就是这样走的，就好比第一个点中提到的关于业务数据流是否真的必须经过开放平台一样，其实安全校验通道和数据通道可以是不同的两个通道，数据通道在获取了安全认证以后可以拿着令牌去建立，这样就可以既满足需求，又降低了系统消耗。（其实和LVS的三种模式的演变很类似）

2. 系统先做繁再做简单。记得小学的时候老师总是和我们说，书是先读厚，然后读薄。这和我们设计系统一样，开始的时候我们往往会想得很全面，然后不断的增加复杂的设计来保证我们的业务可用性，但是后续会发现，复杂本身就是降低业务可用性的罪魁祸首，因此不断的审视需求，重构设计，最后以简单易扩展的方式满足业务需求。我上次和淘宝技术大学的新入职的同学说，我比在坐的优势就在于可以较快的从复杂的设计跳出做到简单的设计，这其实就是积累的经验，但是他们的优势在于可以看到一些经验背后的不足。

3. 从需求的角度看问题。分布式缓存最大的问题是什么，就是数据一致性，为了这个一致性不得不牺牲性能。而对于性能要求很高的场景下如何保证一致性和可用性，则可以从客户端实现数据冗余来做文章。另一个例子，现在TOP的分布式即时日志分析模型中数据获取部分是每个Slave主动请求去“拖”服务器的日志，而淘宝的监控系统则是在应用服务器上设置了Agent计算和收集日志并“推”送给单点，这一推一拖的差别在什么地方，监控系统也好，日志系统也好，最基本的前提是不能影响业务系统，推会导致谁都无法掌握主动权去控制非业务性需求对业务系统的影响，而拖则将主动权交给了非业务性需求，根据业务的适应情况，调节频率和处理内容的数量，有效的利用资源。（这其实就是需求角度看问题）

4. 技术并非无业务性。其实类似的流控，服务范围限定等等，都是提升业务想象空间的技术基础。这年头卖软件不赚钱了，卖服务，而卖服务也是差别化的服务，低层次的免费体验，高层次的增值收费，产生良性循环。

5. 不要盲目崇拜。有同学和我说TOP支持OAuth么？这么流行的不支持，不太好吧。咋们是实在人，在没有服务好用户以前先不想着贴牌子在身上。我自己也是G的粉丝，但是很多时候对于新技术而言需要的是一种嗅觉和辨别能力，不然闻到G拉屎都觉得香了。我虽然转到淘宝才10个月，但是是3个同学的师兄（淘宝的新人都需要一个师兄），其中有个大学刚毕业的同学，开始的时候写代码就开始套模式，有新技术就考虑学一把。代码被我要求返工了4次。和他后来谈起的时候，说到对于新技术的学习，其实为了看见牛的时候能够记得起有一把牛刀可以用，而不是整天提着一把牛刀满大街砍小鸡。还是那句话，找到合适的场景，在去深入学习和了解技术背后的思想。

困顿

淘宝“出逃”。09年初，淘宝开始搭建自己的开放平台TOP，原因很简单，淘宝需要的是淘宝服务开放平台，而非一个服务集成平台，服务集成平台对于专业化和产品化运营API是较为不利的。于此同时产品化服务这个词开始慢慢进入我的脑子。

北京的搜索团队，支付宝都和我交流过关于开放的考虑，但是一系列问题却问倒了我，也问倒了他们，为什么要开放，客户群在什么地方，应用形态是怎么样的？其实就是API产品化的问题，对于没有开放过的服务提供者来说都是抱着尝试的态度去做开放，但是基本上不靠谱（国内的技术能力和创新意识都还处于初级阶段）。看到早期的SNS开放出来其实还是以传统意义的桌面版游戏结合SNS的互动产生效果。而类似于搜索，支付这些专业化程度较高的服务，开发者如何去使用，安全性如何保证，其实都还很模糊。

到了09年4，5月份，开放平台逐步转变成为内部服务平台，技术驱动力随着商业目标的模糊越来越弱，5月底我要求做最后一个版本SIP5.6，然后就暂时终止继续开发。

产品化

09年8月，阿里软件被多家子公司合并，我主动要求从云公司来到淘宝，因为我还有没有完成的目标，开放平台，同时也只有在这里我才会体会到产品化的含义，踏踏实实的在我30岁的时候经历一个产品，而不在存粹的技术实验室中打滚。

虽然以前和淘宝的同学一起合作走了大半年，但是进入TOP团队的时候，其实对整个团队和技术格局并不了解，所以从最基础学习，给大家打杂解决问题为先。TOP的技术氛围要比阿软好，少了“牛人”（我自己这牛脾气也希望在这一两年内完全改掉），少了抱怨，大家都有明确的目标“把开放平台做成大淘宝的基础平台”。

TOP从我进来之前就有很明确的商业目标和商业规划，这里不得不提到“黑羽”同学，一个比技术更懂业务，比业务更懂技术的产品经理。从TOP的发展方向上来就很明确的解答了我前面提到的几个问题：为什么要开放，客户群在哪里，应用形态将会怎么样？TOP与SIP不同在于，它不是一个服务集成平台，而是淘宝服务的开放平台，开放的服务都是基于淘宝基础数据和流程，开放的目的就是为了让淘宝走出自己的“一亩三分地”，由“made in taobao” 转变成为“power by taobao”。TOP的客户群如下图：

 

淘宝越来越大，公司内部有很多部门和子公司，之间最有效的合作方式就是通过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，很多东西可以写，不过实在吃不消……，有兴趣想了解细节的同学可以直接和我联系。