开放平台两三点感悟

开放平台两三点感悟

Author:放翁（文初）

Mail:[e-mail]

围脖：http://t.sina.com.cn/fangweng （多加一个围脖，也潮一把）

有淘宝的同学在旺旺上和我说，你最近很少写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岁的时候经历一个产品，而不在存粹的技术实验室中打滚。

有点晚了，明天继续写…（可能要写如下）

1. 透明化（系统，业务）

2. 客户第一（服务可用性，易用性，商业价值）

3. 平台要死哪里是致命的一击