Open API分析、实践和思索(后半篇)

该文前半部分在程序员1月刊上,由于杂志篇幅有限,因此后半部分没有被刊登,这里就在blog上增加一下：

 

三. 服务集成平台

经过前面的介绍和实践两部分，在Open API在概念和实际操作上都有了一定的理解和认识，这里就再谈谈服务集成平台的作用、角色和定位。这里大致描述一下集成平台当前的实现点，这些实现点也就是服务集成平台的价值所在。

服务集成平台（SIP）的角色和作用

 

图 3 SIP Role

ISV（独立软件开发商）最关心什么？

1.       服务资源是否丰富。这关系着是否能够创新。

2.       服务质量是否有保证。这关系着是否能够满足用户最基本的需求。

3.       开发集成是否便利。这关系着开发成本。

ISP（独立服务提供商）最关心什么？

1.       服务安全性是否可靠。如果损害到自身或者用户利益，则就失去了原来开放的初衷。

2.       是否有足够多的应用开发者使用服务。

3.       服务的非业务性需求是否可以满足。（服务监控告警，计费，统计分析等）

SIP是连接ISV和ISP的“桥梁”。它能解决什么双方最关心的什么问题？

1.       丰富的ISV资源以及丰富的ISP资源。这其实是一个良性循环的过程，就好比一个建材市场，买家和卖家数量远远要比在单独一家实体店中多，从淘宝的B2C模式就可以看出，市场大了以后传统的“大鳄”都要聚集人气。

2.       统一安全标准和多种控制策略，即保证了ISP的安全，又能够让ISV开发起来方便。在前面实践过程中可以很明显的看到，众多的应用id，各自的安全流程，让开发者Mash up无形中增加了很大的开发成本和维护成本。

3.       SIP目的就是让ISP专注于业务服务的开发，而将非业务性的需求，如安全，服务监控预警，日志分析统计，计费，社区等都一揽子解决。这样既解决了ISP的第三个问题，同时也为ISV关心的服务质量无形中作了促进。

在年初的时候，分析和研究国外的Open API时，感觉类似于SIP形态的产品在国外还没有，大家都是各做各的，但这阵子回过头来看，YouTube和Google开放平台，Flickr和Yahoo开放平台，这些平台都属于SIP形态的产品，而且Google要比当前我们做的SIP还要更进一步，那就是数据格式规范化(GData)，而SIP当前仅仅只是做到流程规范化。

那是否任何公司都适合去做SIP这类形态的平台呢，这不仅仅是技术问题，还是一个资源的问题。阿里巴巴每一家子公司都有实力去做一个这样的开放平台，但各自独做一套的结果就是资源浪费，同时技术没有得到积累（SIP技术积累是在ISV和不同形态的ISP接入中逐渐产生的），最重要的是这些子公司其实真正需要关注的是如何将业务和数据开放给开发者，吸引更多的开发者来构建出围绕Open API的创新应用，最大化数据和服务的商业价值。

服务集成平台功能特性

服务路由

         服务集成平台就好比硬件里面的“路由器”，服务调用者只需要提供服务注册的名称，就可以调用到某一个服务提供商提供的服务，对于调用者来说无需关心此服务的地址以及提供者。

         根据现阶段的服务集成来看，主要分成四类的服务路由，同步服务路由，异步服务路由，订阅服务路由，大数据量上传服务。同步服务路由就是普通的Http无状态单次请求和响应。异步服务路由应用于服务提供商提供的服务无法在当时处理完毕，先返回一个请求响应，当服务处理结束以后再将服务处理结果返回给服务调用者（短信业务就是一种异步服务）。订阅服务和互联网上RSS之类的订阅十分相似，服务调用者只需要订阅服务即可获得服务提供商推送的服务内容。大数据量上传服务其实也是属于同步服务，但是由于消耗资源和性能压力不同，因此被单独作优化处理。

         对于服务形态不同，服务路由需要支持REST风格的服务路由和类REST风格服务的路由，但对于开发者来说，调用的方式都是用服务名称来路由。

正式环境和测试环境的隔离和切换

         对于服务开发者来说，在应用开发期间需要有外部测试环境的支持，在商用以后需要有正式环境支持，同时两个环境的切换需要尽量的简单。

         服务集成平台支持服务提供商提供测试环境和正式环境的不同服务路由，同时两套环境切换成本低。当服务提供商只有一套环境的时候可以根据策略配置的不同，对调用者访问的范围，频度，次数作限制，保证测试服务不影响正式服务。

安全

         提供对应用身份认证以及服务提供商身份认证的支持，采用多种数字签名算法实现基本的身份认证，支持IP白名单和动态算法更新后端插件提供更高级别的服务安全保证。

         细化了用户授权流程。对于用户Token细分为请求级别和会话级别，同时对于会话级别的权限操作，失效时间可根据服务提供商的配置自定义。同时平台托管维护每个应用每个用户的多身份绑定Token，降低服务提供商开发维护成本。

         服务提供商可配置服务访问量控制和频率控制（所有应用或者单个应用）。也支持配置需要订购才可以使用的服务（有限次数订购，无限次数订购）。

         支持多级服务安全策略配置，为服务配置（无授权，应用授权，用户授权，可选用户授权）等多种级别的安全策略。注：可选用户授权是指如果没有被用户授权的情况下使用接口将返回部分公开数据，而在用户授权情况下使用则返回全部的私有和公开数据。

         对服务提供商多级分类，提供不同的安全策略组合。

监控与告警

         服务使用者服务使用出错监控和告警。

服务提供商提供的服务可用性，超时状况的监控和告警。

服务集成平台服务处理状况，内部模块运行状况监控和告警。

日志采集与统计分析

         高并发下日志采集异步处理，采集服务正常访问和异常访问日志，采集用户绑定类，异步服务类，平台内部服务类等特殊日志。

         每日，每周，每月访问日志统计分析，基础报表和趋势分析图的创建。

         支持分析结果预警配置。

         历史统计数据管理和归档。

 

平台内置服务

         平台为服务提供商以及服务调用者提供了平台级别的服务，为开发商和服务提供者获取平台业务数据以及运行期配置安全策略提供方便。

         平台提供一系列平台模块监控、配置、重置服务，支持在线问题查找、定位、解决的一套机制。

非功能性需求（当前情况）

         性能：压力测试单机500并发用户1600+的tps，多机处理能力线性增长。

         模块化：内部处理模块化结构，支持运行期配置、装载、卸载。

容错：服务集成平台核心数据都缓存在Memcache中，因此Memcache集群以及容错策略的扩展都为平台稳定和容错作了基础保证。

配套支持

         通过ISV,ISP,Admin三个Portal，使开发者，服务提供商以及后台维护人员能够自主维护基本信息和查看相关数据。

         为开发者提供社区，测试区的支持，并且提供开发工具包和文档，方便开发。

扩展集成

         支持不同平台的服务集成。支持Google,Flickr,Yahoo等等不同的服务平台的服务集成，当前还没有完全将安全体系集成，只能够支持安全流程透传，消息数据完整过滤。

服务集成平台的一些发展趋势

1.       数据集成和流程集成

当前很多服务都是基础的数据型服务，使用者通过数据筛选获取相应的数据，然后展现给用户，这些服务的集成相对来说功能比较单一，流程也不复杂。但随着服务提供商的发展，数据类型服务将会作为基础服务的一部分，而越来越多业务处理型服务会成为使用者的首选，此时，如何让服务和服务之间数据互通，服务可以通过一定的描述编排，就会变得越来越有价值，就如前面提到的，Google采用GData作为数据规范格式，同时对于安全流程的统一制定，为第二阶段的集成打下了基础。

2.       服务基础平台间的互通

最近Open ID也再次由于各大网站的支持而被人们广泛关注，在未来Open API体系中，伴随着Open ID的发展，服务基础平台之间的服务互通也将会变得越来越容易，但是数据的安全性也会对每个服务平台要求更高。

3.       服务集成平台的层次化

在这篇文章的介绍中仅仅介绍的是最基础的Open API的Mash up，其实当前已经有更高层次的Mash up被广为使用，JavaScript、ActionScript、Flash/Flex这些技术使得展现更为灵活和丰富。因此未来的服务集成平台将会层次化，从数据集成到流程集成到UI集成，会成为一套自下而上的解决方案，适合各种场景的裁剪选择。

四. 对Open API的一些思索和感触

不同角色，不同收获

平台开发者：

         这是我的本职工作和角色。当淘宝等服务提供商的服务接上来以后我就要为它的安全和稳定负责。当SIP一旦出现问题，那么服务提供商和软件开发商将都无法再正常工作，套用蜘蛛侠的一句话：“能力越大，责任越大”。作平台的尤为如此。

服务提供商：

服务提供商接触的最多的就是淘宝的同学，首先看到的就是做一个服务提供商很不容易，要把原有系统中复杂的逻辑抽象出来并不是抽象一个公用函数那么简单，同时对于模块化，边界性，容错性方面的要求要远远高于封闭系统开发本身，因为你现在要面对的是倍于原有访问量上百甚至上千的调用者，对任何一个小疏漏都可能带来灾难性的影响。

软件开发商：

         在写这个文档以前，最多也就是写几个测试的Demo来测试SIP环境中的服务，在淘宝API讨论群中会看到很多新的或者老的ISV在抱怨或者询问一些自己觉得很简单的问题（例如签名等等），同时在监控中也看到很多及其简单错误统计数都会有很高的比例。但是经历过这次对于各种各样国内国外的API的开发，让我深刻体会到了开发者的一些痛苦（当然我没有去使用各个开发社区的第三方语言开发包，这也增加部分的开发难度），我也曾因为签名问题在豆瓣API测试的时候折腾了半天，在调试Google Calendar的时候不得不跟踪开发包代码才找到了一些隐晦的设置通过测试。其实Open API在国内国外都没有完全可以称得上成熟，因此开发者其实是最容易受到影响的。同时他们面对着最难应付的客户，平台或者服务提供商出现问题，客户最先抱怨的也是服务开发商，因此作为平台开发者和ISP其实都要给与一定的支持和帮助，这样才会走向更好的良性循环。

其实上面说的那些无非都是大家最长说的换位思考，一个新兴的开发模式需要各方合作才会走向良好的发展方向。

创意就是财富

         记得前一阵子支付宝能够在上海交水电费引起了很多人关注，杭州本地论坛中都有很多人在问：“什么时候杭州能够也用支付宝交水电费就好了”。其实如果开放了支付服务和水电缴费服务，这种Mash up的应用又有什么难的呢？你都可以直接每个自然月通过Google Calendar设置好日程安排，自动缴完所有的费用，然后短信提示一下即可。未来当各行各业发现了自身资源的潜在价值以后，以服务的方式通过平台互通，那么创意就是财富。