马 琳 ,宋俊德 ，2，宋美娜

（1.北京邮电大学计算机学院 北京 100876；2.北京亿阳信通科技有限公司 北京 100093）

开放平台：运营模式与技术架构研究综述*

马 琳1,宋俊德1，2，宋美娜1

（1.北京邮电大学计算机学院 北京 100876；2.北京亿阳信通科技有限公司 北京 100093）

对于现有开放平台的运营模式和技术架构进行了分析，并给出了开放平台的发展建议。首先，介绍了开放平台的发展背景，并指出开放平台的相关定义和分类方式。其次，对于国内外主要开放平台的运营模式进行了一一分析。再次，对于国内外主要开放平台的技术架构进行了较为详实的介绍。在上述分析的基础上，指出了我国现有开放平台存在的主要问题。最后，对于开放平台的发展从运营模式和技术架构两个方面给出相关建议。

开放平台；开放服务；运营模式；技术架构

* 国家科技支撑计划基金资助项目 （No.2008BAH24B04，No.2008BAH21B03，No.2009BAH39B03），国家自然科学基金资助项目（No.61072060），新世纪优秀人才支持计划基金资助项目（No.NECET-08-0738），国家科技重大专项（“863”计划）基金资助项目（No.2011AA100706），教育部信息网络工程研究中心资助项目

1 开放平台发展简介

随着国内互联网发展的不断深入，越来越多的互联网企业意识到，通过单一的自身力量提供多种多元化的应用服务来快速满足用户的各种需求是很难做到的。于是，开放自身能力，借助广大的第三方力量不断丰富和完善应用，进而提高用户黏性，成为广大互联网企业的近期发展的必经之路。开放平台带来了整个互联网生产方式的变革，原来的独立网站式的小作坊生产走向基于开放平台的大规模协作，无数身居幕后的开发者、服务提供商、内容提供商走到台前，直接参与到开放平台的运作中，带出新的开发者经济时代，为整个互联网以及移动互联网行业的长足发展注入新动力。

1.1 发展背景

开放平台伴随着互联网的发展应运而生，是互联网成熟到一定阶段的必然产物。纵观互联网发展，大体可以分为3个时代：导航时代、搜索时代和开放时代[1]。

（1）导航时代

在互联网发展初期，网站数目不断增多，于是为满足用户便捷“冲浪”的需求，产生了以“分类导航”为主要特点的门户型公司，该时代的典型代表为Yahoo。目前国内的hao123、265等网站依然在以该方式为用户提供导航服务。导航时代的主要特点是通过“链接”的方式，来维系网站与网站之间的关联。

（2）搜索时代

随着互联网内容的不断增加，仅仅通过导航很难帮助用户在众多内容中快速定位所需要的信息，于是“搜索”应运而生。这个时代的到来以Google的兴起为主要标志。在搜索时代，各个网站上的内容以搜索词为中心被重组，网站与网站之间的简单链接关系被打破，内容的关联性成为网站间关系的主要表现，同时，投放搜索广告也成为企业盈利的一个重要方式。

（3）开放时代

目前，随着信息量的爆炸式增长，基于内容的单一维度搜索已经无法准确定位用户需求，同时很难快速满足多样的个性化需求。很多信息之间存在关联，但是这种关系无法通过关键词简单地表示，于是这些信息就像一个个碎片，散落在各处，并不能被很好地利用；同时，随着Web 2.0应用的兴起，越来越多的系统中拥有与用户相关的信息，而这些系统本身又是独立封闭的，于是引发了各种问题[2]。

·信息/资源碎片化：信息与信息之间缺乏多样化的关联组织。

·应用碎片化：用户所使用的各种应用在不同的网站上，应用之间缺乏关联，使用不便。

·关系碎片化：用户需要在不同的网站上注册ID，并在其中拥有各自独立且不同的关系。

·用户碎片化：由于与用户相关的信息、应用、关系的分裂，造成用户本身也呈现为碎片化特点。

这些碎片分布在网络中，不仅造成了大量冗余，而且为用户的使用带来很多不便。于是，“开放平台”应运而生，通过“打破封闭，全面开放，整合碎片”的方式，实现以“用户”为中心的全周期、一站式服务。

1.2 开放服务简介

所谓开放服务，指把网络上的服务能力封装成一系列计算机易识别的数据接口开放出去，供第三方开发者使用，即 OpenAPI（open application programming interface）[3]。其实这并不是一个新概念，在计算机操作系统出现的早期就已经存在了，但区别在于，当前的开放服务范围更广，开放的机制也有所不同。

目前，开放服务工作在国内外各大公司中进行得如火如荼，开放的深度和广度也在不断增加。在Google开放API之前，已经有Amazon和eBay等公司开放API，但是对应的数据集中在商品上，与人们的日常互联网应用有一定的距离。真正推动整个互联网开放的发端，应该是Google在 2005年开放Google Maps的 API。至此之后，各类OpenAPI如雨后春笋般开放给广大用户，主要包括搜索类（Google Search API、Yahoo Search API 等 ）、文 字 咨 询 类（Google Reader、抓虾、鲜果等）、多媒体类（Flickr、Youtube等）、地理信息类（Google Earth、Google Maps等）、用户关系类（Open Social、Facebook、MySpace 等系列 API）、电子商务类（Amazon、淘宝开放的系列 API）等[4]。

开放服务的实现机制主要包括3种形式[5]：RPC（remote procedure call，远程过程调用）协议形态的开放服务，REST（representational state transfer，表述性状态转移）形态的开放服务和RPC-REST混合服务。RPC的目的在于实现类似于调用本地服务或方法一样调用远程服务器的服务或方法，具体的实现方法有XML-RPC、JSON-RPC等；REST是作为一种全新的服务调用框架，可以降低开发的复杂性，提高系统的可伸缩性。该框架采用基于资源的架构，操作对象为互联网一系列已有的资源，通过URI（统一资源标识符）访问已被标记的资源，这些资源可以是不同格式文件或文件集合，如 HTML、XML、PDF、JPG、PNG、Text等；采用无状态通信，服务状态信息保存到客户端或者具体的服务中，服务器端无需为客户端保留服务的状态；采用HTTP通信方式，HTTP 的操作接口包括 get、post、put、delete、head和options等。

当前OpenAPI的类型主要可以分成3种：数据型、应用型、资源型[6,7]。

1.2.1 数据型OpenAPI

数据型OpenAPI，就是将自身的数据开放，让应用开发者根据已有的数据进行二次开发。SNS网站的OpenAPI就是属于数据型。

（1）Facebook API

Facebook的核心是由人与他们关心的事物之间的联系组成的社交图。Graph API是Facebook平台的核心，使用户能够读取和写入数据到Facebook。它提供了一个简单持续的社交图的视角，统一了人、照片、事件页面等对象和如友谊、照片标签等此类对象之间的联系标识。社交图中的每个对象都有一个唯一的ID。可以通过https://graph.facebook.com/ID提取与对象关联的数据。另外，具有用户名的人和页面可使用用户名作为ID获取。

Facebook通过3种方式向外提供服务。Social Plugin是Facebook提供的一种插件，用户可以用几行简单的HTML代码将Facebook的插件嵌入网页。通过插件，用户可以跨网站评论、分享。另一种方式使用Facebook提供的API构建基于Facebook框架的应用程序。Facebook还提供可用于外部程序、桌面程序使用的REST风格的API。上述中的开放API均基于Graph API实现。Facebook开放API是基于HTTP的。通过OAuth协议的验证后，使用HTTP方法调用API。

（2）Twitter API

Twitter的 OpenAPI由 3 个部分组成，REST API、Search API以及Streaming API。Twitter REST API允许开发者访问Twitter包括更新时间表、状态数据、用户信息在内的核心数据。调用该API应用可以是用户操作自己的Twitter。Twitter的Search API提供公共Twitter的实时更新以及当前的热门话题。Streaming API通过采样和过滤的形式提供近实时大容量的Tweets访问。

Twitter的 API是完全基于HTTP的，从 Twitter API获取数据需要一个get请求；提交、修改或者删除数据的方法是发送post请求；发送一个delete请求可以删除数据。API方法需要使用相对应的HTTP方法，如果没有使用正确的API请求方法将会返回一个错误代码。HTTP的响应代码对应于不同的实际含义。

除了 Streaming API，Twitter开放的 API都是 REST风格的，只需要简单修改请求扩展上的格式就可以取到指定的格式。目前 API支持的数据格式有：XML、JSON、RSS、Atom，个别方法只支持其中的某些格式。

要使用Twitter的API，首先需要注册一个客户端应用程序，每个客户端应用程序都会提供一个consumer key和secret。Twitter使用OAuth认证用户，除了部分API（如公共时间线 （public timeline））外，所有的API方法都要求用户认证，所有的返回都与认证用户相关。通过认证获得权限后，用户才可以调用API。

1.2.2 应用性OpenAPI

应用型与数据型的结合比较紧密，Flickr的图片搜索，Google的日程、地图等都是属于应用型。应用型的数据输入可以是外部的数据，也可以是基于已有的数据资源进行处理。

（1）Flicker的图片搜索 API

Flickr的API包含3种风格，不同的请求格式为REST、XML-RPC以及SOAP，3种请求方式都通过方法名称来调用 API。API的响应格式有 REST、XML-RPC、SOAP、JSON以及PHP，格式可在发送请求的参数中进行设置。Flickr API支持多种语言开发工具。

Flickr的图片搜索API为flickr.photos.search，用于返回符合匹配标准的图片列表，只返回对请求用户可见的照片。如果需要返回私有或半私有的照片，用户通过验证以获得读权限。未经证明的调用将只返回公开照片。Flickr API通过认证、参数、响应以及错误代码来定义。

（2）Google Maps API

Google Maps是Google公司提供的地图服务，包括局部详细的卫星照片。它能提供多种图：一是矢量地图；二是不同分辨率的卫星照片；三是后来加上的地形视图，可以用以显示地形和等高线。Google Maps可以在浏览器中展现包含地理信息的数据，并且地图可拖动缩放。

Google Maps拥有非常多的 API，包括 Google Map API、Google Earth API等，可以利用它们在用户的网站和应用程序中嵌入功能强大且实用的Google Maps，并在地图上叠加用户自己的数据。Google Maps API使用JavaScript、HTML和CSS在用户网站创建交互式地图。

1.2.3 资源型API

资源型API提供的是数据的存储和检索功能，其中代表是 Amazon S3(Amazon simple storage service)，Flickr的图片存储服务等也可以属于资源型。在云计算的背后就需要提供这么一个资源型的服务，Amazon EC2如果离开了S3，也就无法存在。

Amazon S3是一个提供在线存储的Web Service，它的目的是使网络规模计算的开发更容易。Amazon S3提供一个简单的Web Service接口，可以用来在任何时间，从网络的任何地方存储和检索任意数量的数据。开发人员可以访问具有相同程度的可扩展、可靠、安全、快捷、廉价的基础架构。Amazon自己运行的全球网络就是使用的这个架构。这项服务旨在最大限度地提高效益规模以及开发人员的效益。Amazon S3同时提供REST API以及SOAP API，返回XML格式的响应。同时，返回不同的代码标识错误。

1.3 开放平台简介

通过开放服务的方式，开发者可以对众多的信息和应用进行再加工，使得之间的关联得以显现，但是用户层面的碎片化问题仍然没有得到有效的解决。这就需要一个平台能够在不改变用户原有使用习惯的基础上，透明化地整合用户的信息、应用、关系，于是“开放平台”应运而生。

1.3.1 相关定义

对于“开放平台”目前还没有一个明确的定义，以下是几个得到业界普遍认同的定义。

在维基百科中指出，在软件和面向Web的架构中，开放平台主要指基于开放标准的软件系统，比如通过面向第三方开发者发布编程接口来允许外界使用其功能（但不允许改变源码）。通过使用这些接口（比如API），第三方可以为平台整合功能。一个开放平台本身并不意味着要开放资源，但是大多数的开放平台对于API有多种实现方式。比如CGI主要是通过开放Web资源服务器 （如Microsoft Internet Information Server）来实现。一个开放平台中既包括一些对外开放的模块，同时也可以存在一些封闭的功能[8]。

在百度百科中指出，开放平台是指软件系统通过公开其应用程序编程接口（API）或函数（function)来使外部的程序可以增加该软件系统的功能或使用该软件系统的资源，而不需要更改该软件系统的源代码[9]。

谭晨辉和刘青炎等人认为[10]，所谓开放平台就是首先提供一个基本的服务，然后通过开放自身的接口，使得第三方开发者得以通过运用和组装其接口以及其他第三方服务接口产生新的应用，并且使得该应用能够统一运行在这个平台上，这样的一种网络服务模式叫做开放平台。这个基本的服务可以是已有的，例如门户、博客，也可以是新创的，例如用户关系。无论是哪一种，开放平台模式成功的要点在于通过自身服务和第三方应用的互惠互利，提高用户对平台网站的粘性和使用程度，进而提高获利；同时，通过利益分摊，达到平台自身和第三方应用循环刺激而产生的滚雪球式的增长。

1.3.2 分类方式

依据不同的分类标准，开放平台具有多种分类方式。

开放平台按照平台自身是否提供一个有显著应用模式的服务可以划分为两类[11～13]。

（1）应用型开放平台

应用型开放平台的特点是自身依赖一个基础的应用模式（如用户关系、博客等），然后开放平台供第三方开发者扩展，这一种的开放平台大致有以下几类：

·基于用户关系的，例如Facebook；

·基于个人门户的，例如Myyahoo、iGoogle和Netvibes。

·基于博客的，例如Sohu Blog。

并不是每一种基础应用模式开放出去都能最终建立起“平台—应用—用户”的循环刺激，从而使整个开放系统良性循环发展。就上述几种开放平台而言，只有类似于Facebook这样的基于用户关系的开放平台很好地解决了用户碎片化的问题，而基于个人门户和基于博客的开放平台，只是停留在简单的应用组装层面，难以让用户很好地控制不同的数据；在应用推广上，也由于缺乏基于用户关系的链式传播路径，带来很多问题。

（2）服务型开放平台

服务型开放平台本身并没有一个基础的应用模式，而是把计算资源作为一种服务，通过开放API提供给开发者，让开发者能够以极为低廉的服务费拥有大量、稳定的计算或存储资源，这类开放平台即为云计算中的“PaaS平台”。这方面的典型代表有 Amazon S3（http://aws.amazon.com/s3），Google App Engine（http://code.google.com/appengine/），微软的 Azure以及 Sina App Engine（http://sae.sina.com.cn/）等。

应用型和服务型两类开放平台并不矛盾，反而相得益彰。第三方开发者通过运用服务型开放平台提供的计算和存储服务，可以不再为机器、软件的运维所烦扰。融合各类OpenAPI，专心做好应用的业务逻辑和界面逻辑，然后部署到服务型开放平台中去，以其低廉的成本快速开发和部署应用，服务于应用型开放平台中的大量用户，进而为整个平台和开发者自身都创造了更大的利益。

李大伟等人[14]指出开放平台按照提供的功能、数据和服务大致可以分为以下5类。

（1）云计算平台

云计算平台解决了开发者建立应用时开发、部署和运营的问题，使得运算和存储资源能够按照需求动态进行分配。

（2）网络服务平台

这类开放平台提供网络服务模块，让开发者能透过API调用功能，快速地集成不同的模块，进而建立新的应用。

（3）在线业务平台

这类开放平台是ERP、CRM等服务以电子商务提供商的形式通过API的形式开放平台中的数据，让第三方开发者提供新的功能，进而满足用户多样化的需求，如Salesforce的force.com、eBay和淘宝提供的开放平台。

（4）移动应用平台

随着iPhone和iTune平台的成功运营，广大终端厂商和运营商纷纷建立移动应用商店，降低了传统移动应用于运营商和终端商合作的门槛，开放了更多的创业机会给移动应用开发者。

（5）社会关系平台

这类开放平台不仅通过API的形式开放了平台的功能，还将直接将对用户传播的渠道开放给了广大第三方应用，比如 Facebook、Myspace、人人网等。

这5类平台，为服务提供了全生命周期管理，从开发、测试、部署到推广，每个环节都更加便捷；为开发者提供了一个全新的舞台，建立了全新的创业模式。

2 开放平台运营模式分析

开放平台生态系统能否健康运转，平台自身的运营模式起到了至关重要的作用。开发者能够通过开放平台生存和发展，在创新的土壤之上获得收入是整个平台运营中的重中之重。同时，开放平台内部关系处理妥当、资源配置合理是主要的考核标准。

目前，开放平台的盈利模式大致分为两类：前向盈利，就是指向用户直接收钱，比如游戏等；后向盈利，指向用户之外的其他人收费，主要指的是广告模式。具体的收费途径包括：微支付、广告和直接销售，其中，微支付主要包括虚拟物品、虚拟货币、游戏费用等；广告收入主要包括植入式广告和联盟广告；直接销售主要是指应用软件一次性销售获得的收入和免费应用收取的增值服务费用[15]。

2.1 国外开放平台运营模式现状

国外开放平台的发展比较早，在运营模式方面也相对比较成熟，下面将就Facebook、Google、亚马逊以及苹果的开放平台的运营模式一一进行分析。

2007年5月24日，Facebook首次推出开放平台，利用这个框架，第三方开发者可以开发与Facebook核心功能集成的应用，Facebook从而成为应用集中发布的新平台。Facebook的做法带动互联网走向开放平台的新格局[16]。

2008年 4月，Google推出 Google App Engine平台[17]，采用云计算技术，实现网络应用程序的开发、托管以及数据管理等。该平台提供了一整套开发组件来让用户轻松地在本地构建和调试网络应用，之后能让用户在Google强大的基础设施上部署和运行网络应用程序，并自动根据应用所承受的负载来对应用进行扩展，并免去用户对应用和服务器等的维护工作。同时提供大量的免费额度和灵活的资费标准。在开发语言方面，现支持Java和Python这两种语言，并为这两种语言提供基本相同的功能和API。App Engine的资费情况主要有两个特点：其一是免费额度高，现有免费的额度能支撑一个中型网站的运行，且不需付任何费用；其二是资费项目非常细粒度。普通IaaS服务资费，主要就是CPU、内存、硬盘和网络带宽这4项；而App Engine则除了常见的CPU和网络带宽这两项之外，还包括很多应用级别的项目，比如：Datastore API和邮件API的调用次数等。

亚马逊是互联网上最大的在线零售商，但是同时也为独立开发人员以及开发商提供云计算服务平台。亚马逊将自己的弹性计算云建立在公司内部的大规模集群计算的平台之上，而用户可以通过弹性计算云的网络界面操作在云计算平台上运行的各个实例（instance）[18]，而付费方式则由用户的使用状况决定。早在2006年3月，亚马逊就发布了简单存储服务（simple storage service，S3）；2007 年 7月，亚马逊公司推出了简单队列服务 （simple queue service，SQS），这项服务使托管主机可以存储计算机之间发送的消息；亚马逊公司进一步在此基础上开发了EC2系统，并且开放给外部开发人员使用[19]。

苹果围绕App Store构建“终端+服务”的完整移动互联网生态系统。App Store的核心是建立了端到端的支撑控制框架以实现对平台的唯一控制权。终端业务一体化是App Store成功的基础，这种成功颇具苹果的烙印，是一种特有的成功模式。苹果App Store的成功取决于3方面。

（1）降低开发者门槛

苹果允许个人用户参与开发App Store的游戏、软件、主题等应用，既为平民移动互联网创富提供了可能，又提高应用数量和应用的创新性。

（2）提供统一的开发工具

加强对终端的完全控制，同时在服务器端建立与终端相匹配的SDK体系。

（3）建立社区化的运营机制

搭建用户、开发者、App Store之间充分交流的平台，形成良好的交流与反馈机制，促进平台的提升与产品的改进[20]。

随着苹果应用商店模式的成功，开放平台成为业界的大势所趋。来自产业链的分工协作、角色互补和利益共享正创造巨大的产业价值。

2.2 国内开放平台运营模式现状

在国外互联网的带动下，我国互联网也正走向开放平台时代。腾讯、淘宝、百度、人人网等先后推出了各自的开放平台，互联网公司的开放平台之争不断升级。

腾讯开放平台拥有中国互联网最大的社交平台以及用户最为全面的社交关系，并推出了社交、微博和Q+为代表的三大平台，通过应用接入和QQ互联实现了用户互联网行为的产品引导以及开发商的全面合作。其中腾讯Q+开放平台提供应用平台、推送通知、统一账号、多关系链、通信传输、安全支付、地理位置、状态共享、数据存储、应用分析等10项服务[21]。由此可见，腾讯已经不仅仅满足于作为单纯的应用开放平台，而是朝着互联网时代的基础平台方向迁移。腾讯正在搭建PC乃至多种移动终端上的“Q++服务”的生态系统。

淘宝是目前我国最大、影响力最广泛的网上零售平台，在交易规模、用户份额等方面均拥有绝对领先的优势[22]。同时，淘宝开放平台（Taobao open platform,TOP）开放的主要服务均处在业务层面，是基于电子商务进行的业务开放平台搭建。其中包括API接口规范和定义；APISandbox在线开发测试环境等。其中最有核心价值的是淘宝应用商店“淘宝箱”。这些应用涉及商品展示、客户服务、店铺营销、后台管理、物流管理等多个网购环节。淘宝开放平台不仅为第三方开发者提供了海量用户的广阔市场，更提供了从技术研发、市场推广、收费体系、客户服务等全方位的支持和服务；同时，淘宝开放平台提供的优质资本支持，也为创业者提供了一个很好的环境和舞台，极大地降低了创业难度。

百度搜索开放平台[23]是一个基于百度网页搜索的开放的数据分享平台。广大站长和开发者可以直接提交结构化的数据到百度搜索引擎中，使用户获得更好的搜索体验，并获得更多有价值的流量。由于百度也推出很多应用，所以有不少业者觉得百度不够开放。业者担心如果用户都停留在百度，自己的网站就会失去流量。虽然有基于“框计算”的应用开放平台，但应用通过搜索而获得大量用户的可能性微乎其微[24]。

除此之外，新浪微博开放平台、盛大游戏开放平台、人人网开放平台、51.com开放平台、天涯开放平台、豆瓣开放平台等先后出现，并表现出很突出的发展潜力。

3 开放平台技术架构

一个健壮且易于扩展的技术架构是搭建开放平台的基础，下面对国内外主要开放平台的技术架构进行简要分析。

3.1 国外开放平台技术架构现状

笔者选取国外几个典型的开放平台对其技术架构进行了一一分析，其中包括：Google App Engine、Amazon Web Service、Facebook、Windows Azure。

3.1.1 Google App Engine

Google App Engine的技术架构如图 1所示[25,26]，该架构可以分为3个部分[27]。

（1）Web

Web部分主要用于处理Web相关的请求，共包括4个模块。

·Front End：既可以认为它是Load Balancer，也可以认为它是Proxy，它主要负责负载均衡和将请求转发给App Server（应用服务器）或者Static Files等工作。

·Static File：在概念上，比较类似于 CDN（content delivery network，内容分发网络），用于存储和传送那些应用附带的静态文件，比如图片、CSS和JS脚本等。

·App Server：用于处理用户发来的请求，并根据请求的内容调用后面的Datastore和服务群。

·App Master：是在应用服务器间调度应用，并将调度之后的情况通知Front End。

（2）Datastore

Datastore是基于BigTable技术的分布式数据库，虽然其也可以被理解成为一个服务，但是由于其是整个App Engine唯一存储持久化数据的地方，所以其是App Engine中一个非常核心的模块。

（3）服务群

整个服务群包括很多服务供App Server调用，比如Memcache、图形、用户、URL抓取和任务队列等。

3.1.2 Amazon Web Service

Amazon Web Service(AWS)是一组服务，允许通过程序访问Amazon的计算基础设施。Amazon多年来一直在构建和调整这个健壮的计算平台，现在任何能够访问Internet的人都可以使用该平台。Amazon提供了大多数系统的核心需求的基本服务（如图2所示）：存储、计算、消息传递和数据集[28,29]。

图1 Google App Engine技术架构

图2 AWS主要架构

（1）存储

所有应用程序都需要存储文件、文档、用户下载或备份，可以把应用程序需要的任何东西存储在 Amazon S3中，从而实现可伸缩、可靠、高可用、低成本的存储。

（2）计算

Amazon EC2(elastic compute cloud)能够根据需要扩展或收缩计算资源，非常方便地提供新的服务器实例。

（3）消息传递

Amazon SQS(simple queue service)提供不受限制的可靠的消息传递，可以使用它消除应用程序组件之间的耦合。

（4）数据集

Amazon SDB(simple DB)提供可伸缩、包含索引且无需维护的数据集的存储、处理和查询功能。

Amazon Web Services具有如下特点[30,31]。

（1）可靠性

服务在经过充分测试的高可用的Amazon数据中心中运行，这些数据中心也运行Amazon自己的业务。

（2）安全性

提供开箱即用的基本安全性和身份验证机制，可以根据需要在服务之上实现应用程序特有的安全措施，从而增强安全性。

（3）节 约 成 本

没有固定的成本或维护成本。只需为使用的服务付费，可以根据需要扩展资源和预算。

（4）容易部署

可以通过简单的API使用这个虚拟基础设施和库的所有功能，可以在使用最广泛的编程语言中使用这些API。

（5）弹性

可以根据需要扩展或收缩计算资源，可以快速地从一个服务器扩展到任意数量的服务器，从而满足应用程序的需要。

（6）内聚性

4个核心服务（存储、计算、消息传递和数据集）能够非常好地协作，为各种应用程序提供一个完整的解决方案。

（7）社区

Amazon Web Service社区非常活跃，这会促进世界各地的用户采用这些Web服务，有助于在这个基础设施上创建独特的应用程序。

3.1.3 Facebook开放平台

图3 Facebook平台架构

Facebook开放平台的架构如图3所示[32,33]，主要包括：Facebook API、Facebook JavaScript以及 FQL 3 部分。

·Facebook API是基于REST架构实现的Web编程接口，通过API，第三方开发者可以接入到Facebook的核心数据（如用户信息、朋友信息等），并实现一些核心功能（如用户登录、重定向、更新视图等）。

·Facebook JavaScript（FBJS）是开发者在应用中需要使用的JavaScript功能，可以保护平台中用户的隐私。FBML是对HTML的修改和扩展，用于定制应用程序外观。

·基于SQL的FQL用于查询Facebook核心数据，包括用户、朋友、群组及其成员、事件及其人员、相册等[34]。Facebook开放平台的运作流程：Facebook应用程序在开发者的服务器上运行，每个应用程序与特定的URL关联。当用户请求其URL时，Facebook服务器将该请求重定向到应用服务器处理，服务器之间通过Facebook API或FQL交互，应用服务器最终向Facebook服务器返回承载应用界面的FBML文件[35,36]。

3.1.4 Windows Azure

Windows Azure主要有5个组成部分，如图4所示[37,38]。（1）计算

在云中运行应用程序。这些应用程序在很大程度上看到的是一种Windows Server环境，但Windows Azure编程模型与内部部署的Windows Server模型不完全相同。

（2）存储

在云中存储二进制程序和结构化数据。

（3）结构控制器

部署、管理和监控应用程序。结构控制器还处理在整个平台中对系统软件的更新。

（4）内容传送网络(CDN)

加速对Windows Azure存储器中的二进制数据的全球访问，方法是在全球维护该数据的缓存副本。

（5）连接

允许在内部部署的计算机与Windows Azure应用程序之间创建IP级连接。

3.2 国内开放平台技术架构现状

目前，国内多家互联网企业推出了自己的开放平台，笔者选取其中发展较为成熟的淘宝、百度和人人网的开放平台技术架构进行分析。

3.2.1 淘宝开放平台

淘宝开放平台（taobao open platform，TOP）是一个综合型的全面的开放平台，从3个方面开放淘宝电子商务基础服务：开放业务、开放自有插件式平台、开放对外接入标准。

·开放业务包括两点：以Open API形式开放数据；以流程页面化方式开放核心业务流程。从API的开放数量、规模、业务范围和深度来说，TOP已经是国内最大的开放平台之一[39]。

·开放自有插件平台包括开放淘宝店铺管理平台、开放淘江湖插件平台以及规划推出的其他多种平台。

·开放对外接入标准，允许了第三方以插件或者独立应用形式将淘宝业务开放出去，支持Taobao.com之外的网站上运行基于TOP的插件或者独立应用。另外，TOP也支持桌面端和新平台的应用开发。

淘宝开放平台的整个架构体系是组件化体系架构（如图5所示），可以是很少的几个基础组件构成的Skeleton，也可以是融入了商业想象的Amazing Architecture。TOP当前从业务模块功能角度来划分，可以分成3个层次：基础平台组件层、基础业务组件层、普通业务组件层。基础平台组件层，倾向于平台级别功能满足及对平台稳定性、可用性的支持。基础业务组件层，是介于平台服务于普通业务服务之间的组件，部分利用平台基础组件层的组件，抽象出一层公用业务服务组件，为业务组件提供通用的基础支持[41]。

图4 Windows Azure架构

图5 淘宝开放平台架构[40]

3.2.2 百度开放平台

在2009年8月18日“百度技术创新大会”上，百度董事长兼首席执行官李彦宏首次提出“框计算”的概念，即用户只要在“框”中输入服务需求，系统就能明确识别这种需求，并将该需求分配给最优的内容资源或应用提供商处理，最终精准高效地返回给用户相匹配的结果[24]。

百度开放平台是“框计算”理念实践的重要基础设施，准确捕获用户需求，为广大站长和开发者免费提供开放式数据分享暨对接平台。百度开放平台主要包含“百度数据开放平台”和“百度应用开放平台”[23]。其技术架构如图6所示。

百度开放平台主要针对广大站长和开发者，为其提供了将结构化的数据和应用直接提交的开放平台；同时该平台与百度大搜索平台连接，将开放的数据和应用同步运行于搜索之中，并以最佳展现形式与最优展现样式呈现在搜索结果中，与数亿用户的需求直接对接。

3.2.3 人人网开放平台

人人网开放平台技术架构遵循一个清晰的分层模型，具有如下特点[42]。

（1）通用性

更好地支持Web、mobile、desktop等运行环境，提供了多种形式的API。

（2）标准化

将SDK的开发维护工作交给第三方开源社区来完成，而不是全部由平台来完成。开源社区在平台提供的API上开发SDK，第三方应用开发者在SDK基础上开发应用。

（3）新特性

在某些出于安全考虑而无法通过REST API开放的功能，如加好友功能，则可以由新的Widget API来提供。

人人网开放平台的官方网站[42]给出了如图7所示的其开放平台的最新架构。

从图7可以看出，人人网开放平台大概分为3个层次，共同为最上层的各种形式的第三方应用程序提供服务[19]。

（1）核心服务层（core service layer）

实现了人人网对外提供的最底层的API，定义好了接口参数和调用流程，第三方或平台方可以根据这个层次的API在上面封装SDK。

（2）SDK 层

由第三方或平台方提供的针对各种开发语言或开发环境的SDK。

（3）高级 SDK 层（high SDK layer）

图6 百度“框计算”技术架构[24]

图7 人人网开放平台架构

构建在核心服务层或SDK层之上的高级SDK，例如Discuz SDK就是基于JSSDK来封装的。

第三方应用程序可以使用任意3个层次提供的API进行开发。目前，API可以主要分为3种类型。

（1）Auth API

第三方如果想调用人人网提供的REST API，则必须首先经过用户授权。AuthAPI就是用来完成用户授权的。目前，人人网开放平台进行用户授权遵循业界最新的标准OAuth2.0[43]。

（2）REST API

REST API是人人网开放平台提供的一种使用HTTP来调用的API，需要在完成用户授权后才能调用[44]。

（3）Widget API

Widget API是人人网开放平台提供的一种在用户控制下访问用户资源的一种API，由于是在用户控制下完成的，所以无需进行用户授权 （但用户身份验证还是必需的）。这种API能够支持各种不同的运行环境，如Web、mobile、桌面编程环境等。一个Widget可有拥有多种视图，每一种视图能够适应某个特定的运行环境。Widget可以在Web浏览器中运行，或嵌入到一个原生程序（native application）中，或嵌入到一个对话框中[45]。

4 开放平台现有问题分析

在分析国内外众多开放平台的基础上，笔者发现当开放平台成为企业“一窝蜂式”的选择后，开放平台给企业所带来的优势也慢慢失去，现在很多国内的开放平台在自身管理和整合资源方面存在很多问题。笔者将众多问题进行归类[46～48]，现总结如下。

（1）平台运营商自身职能界定不清晰

开放平台运营商应该具有清晰的业务发展策略，能够明确自身的核心资源和能力，明确界定“裁判员”与“运动员”的关系。分析目前国内现有开放平台发现该问题主要集中体现在以下两个方面：一方面，在应用开发上，平台运营商应当明确界定自身开发哪些应用，而哪些应用留给第三方开发者开发；另一方面，在第三方开发者指导上，平台运营商应当把握用户需求，为开发者提供方向性指引。

在这方面，淘宝做得比较好，值得借鉴。淘宝开放平台明确自身的优势在于用户忠诚度以及用户相对消费能力，而与电子商务相关的后台管理等服务，并非自身所擅长，于是将这部分市场空间让出来给予广大第三方开发者自行发挥，同时，并没有放任不管，而是分阶段地阐明当前最需要的电子商务后台应用是哪些，指明了大致的方向。

（2）平台技术路线不明确，支撑条件存在漏洞

随着第三方应用以及用户的不断增加，对平台运营商也提出了更高的要求。在技术稳定支撑、平台安全以及开发服务支撑等方面，均需要平台运营商为第三方开发者和厂商提供相应的支撑。在对开放平台技术方面的调查中，发现如图8所示的4个问题受到了广泛的关注。

图8 开放平台存在技术问题比例[9]

·安全问题：主要是指用户数据安全性和应用身份安全，例如目前部分厂商正在尝试推行应用授权管理。

·标准问题：主要指目前每家开放平台为了体现自己的特色，保持自己的竞争优势，会加入一些与其他平台不兼容的特性，因此为第三方服务商的服务接入和第三方开发商的应用发布，造成了一定了技术门槛。虽然存在像OpenSocial联盟这样致力于“统一标准”工作的团体，但是由于其主要针对相应领域，同时影响力度还不够强大，所以开放平台标准化还有一条很长的路要走。

·支持问题：主要指平台架构稳定，能够支持海量访问的稳定运营和快速响应，通过提供长期的技术支持，构建独有的、稳定的技术壁垒。

·易用性问题：主要是指第三方开发者和企业对于开放平台的学习成本低，另一方面在于第三方开发者和企业在平台的使用过程中，能够较容易地发现相关错误，同时，在平台各方面服务的搭建上也需要平台运营商能够完善和不断改善平台各种技术支撑。

（3）平台无法为开发者提供更多的发展机遇

让开发者在当下或者未来能够产生足够的收益，是一个开放平台能够持续循环滚动发展的一个非常重要的关键点。但是由于我国互联网长期以来都是通过为用户提供免费服务打开市场的，而这与第三方开发者和企业希望通过用户付费来获得收入想违背，所以就需要平台运营商从以下两个方面进行努力。

首先，培养和挖掘用户付费需求，明确平台盈利模式。目前来看，企业用户的付费和个人用户在游戏端的服务需求较为旺盛，是可供挖掘的基点。同时，在个人用户增值服务方面的培养也是不容忽视的。

其次，制定公正、透明、成体系的开发规则。在应用审核方面，平台运营商与第三方开发者之间需要达到认同；在应用分成方面，平台运营商应该在保障平台基本收益的基础上，更多地让利给第三方，让第三方觉得自己的付出得到了超出想象的回报，更好地激发其热情和对整个平台的忠诚度，进而有利于占领第三方开发者份额。

（4）平台缺乏有效的用户利益保障机制

开放平台本身作为一个多方参与、多方协作的生态系统，一旦缺乏相应的运作约束机制或者机制运作不畅，就会导致低劣应用的出现，进而影响到用户利益，乃至整个平台环境。建立一个有效的保障机制，主要体现在3个方面：首先是准入机制，主要包括开发者资质的准入审核、第三方应用的准入审核、应用测试等机制；其次对用户的响应机制，对使用发现的问题和建议，需要通过一两个渠道进行反馈，并快速得到处理；最后是平台技术分享机制，整个平台和第三方应用的技术调整细节以及带来的好处应当及时与开发者进行详细的分享。

5 开放平台发展建议

通过借鉴国外互联网企业开放平台的成功案例，并分析国内主要开放平台的最新发展，笔者结合目前我国互联网以及移动互联网的发展状况，对于开放平台的运营模式和技术架构给出如下建议。

5.1 开放平台运营模式建议

当开放渐成互联网的一股趋势和潮流之时，国内很多企业构建或参与到开放平台中，并希望在整个产业链中占据属于自己的一环，进而获得用户、流量以及利润等方面的快速积累。但不容忽视的是，构建一个良好的运营模式是整个开放平台生态系统持续、长久运作的基础。笔者在分析国内外开放平台运营模式的基础上，建议在构建开放平台运营模式的时候需要遵循如下原则。

（1）统一文化

开放平台需要具有独特的运营文化，将平台的愿景和理念传达给广大第三方，形成一个大家都广泛接受的文化和理念，以降低日后的沟通和运行成本。例如，在维基百科就有一批崇尚自由奉献、共享知识的志愿编辑们，正是这种文化让维基百科成为了世界上最好的免费知识库。开放平台的各方如能形成文化上的共识，那么日后的沟通成本都会低很多，出现的冲突也会得到较好的管理和解决。

（2）明确职责

对于开放平台这块“大蛋糕”来说，没有一家企业可以独自将其完全消化掉。无论大企业还是小企业，都需要明确自身在产业链中所处的位置，在属于自己的环节中不断做好做深。如果一个企业总是想着扩大自己的领域，占领相关环节，必然会影响到整个产业链的稳定，甚至造成产业链断裂。

（3）协同合作

在开放平台的产业链上，每个环节都是必不可少的，只有与上下游环节的协同合作才能使整个生态系统在和谐稳定的环境中不断成长。同时，对于平台运营商而言，整合的上下游资源越多，越能够吸引到更多的用户，成为日后竞争能够立于不败之地的强大后盾。

（4）公平透明

开放平台需要一个公平透明的游戏规则贯穿始终，并渗透到产业链的各个环节中。主要包括平台运营商与应用开发商之间，同平台的应用开发商之间以及用户与应用开发商之间。

（5）开放共赢

只有共赢互惠的开放平台，才具有长久的生命力。作为平台运营商，在盈利模式和分成模式方面就应该做些创新和突破，让为该开放平台做出了贡献的各方都得到相应的回报。

依据上述原则，笔者给出了如图9所示的开放平台运营模式的建议和具体说明。

在开放平台产业链中主要包含6类对象：应用开发商、能力提供商、广告商、终端厂商、最终用户和平台运营商。

（1）应用开发商

应用开发商通过调用开放平台开放出来的服务和资源能力，快速开发出服务一定用户群体的应用，并将其交付到开放平台中，进而实现应用的低价运营和针对性销售。开放平台不仅为其提供了丰富的服务、资源能力，同时也将用户带给广大开发者，解决了开发者“最头痛”的营销问题，进而将开发者从产业链的后端推到了前端。随着移动互联网的快速发展，移动应用不断盛行，开发商群体也在向精小化和年轻化发展，越来越多有才华的个体自由开发者参与其中，为整个群体的创新能力注入了新活力。

（2）能力提供商

能力提供商主要包括服务能力提供商和资源/内容能力提供商，其将自身具有的服务和资源能力开放出来，供第三方使用。目前，国内外很多开放平台的运营商即是能力提供商。主要是因为这些能力提供商凭借具有的服务能力或内容资源在相应领域已经具有了一定的用户积累，但随着企业的不断壮大，要想形成针对一定用户群体的“全生命周期产品体系”，仅仅依靠其自身的力量是远远不够的，因此这些能力提供商希望通过开放平台能够聚集更多的开发者、第三方能力提供商来为自己的用户服务，进而增加用户的黏性，同时吸引更多的新用户。

图9 开放平台运营模式建议

（3）广告商/广告联盟

广告商/广告联盟主要为企业提供广告的相关服务，并负责将广告发布到开放平台和应用中。目前很多开放平台针对广告商提供了一定规范化的提交和发布接口，同时制定了一定的分成模式。

（4）终端厂商

作为连接开放平台和用户的最终渠道，终端厂商在整个产业链中发挥着重要作用。尤其是随着移动终端智能化的不断深入，终端本身也成为增加用户黏性的一个重要方面。苹果“iPhone+App Store”发展模式的成功，使得苹果成为首个终端厂商转化为的开放平台运营商。但是，笔者认为苹果的这种发展模式并不具有通用性和普适性，这种模式的成功与苹果一直秉承的“封闭”传统以及其终端良好的用户体验密不可分，并不适用于每个终端厂商（诺基亚、联想等App Store的发展失败充分证明了这点）。

（5）最终用户

一般面向一个开放平台的用户均属于一个细分行业，比如淘宝开放平台的用户均为淘宝的卖家或是买家，这些用户可以在平台上获得某个领域的服务链。在该链条中，开放平台设法满足用户各个方面的需求，进而增加用户的黏性，同时强化开放平台在该领域的地位。

（6）开放平台运营商

作为开放平台产业链条中的核心环节，平台运营商在整个开放体系中起着举足轻重的作用。一方面承载着汇集各方能力、协调各方职能的重大责任；另一方面是整个链条运作、利益分配规则的制定者，进而也往往是整个链条中最大的获利者。现有国外的开平台中，平台运营商与能力提供商多为同一角色，大多由大型互联网企业和电信运营商担任。这些企业依托于其原有服务能力聚合了一定规模的用户，为开放平台的运营奠定了较高的起点。但笔者认为随着开放平台发展的不断深入，依靠提供自身原有能力开放的平台运营商仅适合于“专一型开放平台”（即聚焦于特定领域的开放平台，现有开放平台多为该类型）的发展，以自身原有能力为依托融合多家开放能力的“融合型开放平台”必将形成，并会得到长足的发展。

以上5者围绕着开放平台运营商，最终实现了能力流、用户流、资源流和资金流在开放平台上的汇聚。

笔者认为，随着开放平台发展模式的不断多样化，独立的开放平台运营商（即与能力提供商和终端厂商相分离的第三方）将是未来开放平台的一个发展趋势，其可以作为独立的第三方，便于公平公正地汇聚更多一定领域的服务能力和资源内容，进而为开发者提供了更多的选择余地，最终为用户带来更多、更好的应用，同时适用于多种终端平台。但是这样的开放平台必须精细化定位用户群体（甚至是该用户群体的某个需求领域），如果做成庞大的开放平台将失去争取用户、开发者和服务提供商的优势。

5.2 开放平台技术架构建议

目前，开放平台的发展势头虽然很高，但是对于其整体技术架构的研究还处于起步阶段，并主要由各大互联网厂商、电信运营商和标准化组织在推进，由于其各自结合自身业务和发展需求，因此，缺乏一个相对全面和比较标准化的开放平台技术架构。笔者综合国内外多家开放平台的技术架构，并结合我国开放平台发展的特色化需求，给出如图10所示的技术架构建议和具体说明。

该平台主要服务于以下两类用户。

（1）开发者

能够在平台中得到丰富的开放服务能力，并通过应用开发工具快速地将能力进行聚合形成满足一定用户需求的具体应用；然后“一键式”部署到应用运行环境中，由平台为其分配支撑应用运行的基础资源，同时监控应用的运行情况，并针对具体需求可伸缩地调整资源分配情况；最后该应用通过应用销售商店展示给最终用户。

（2）最终用户

开放平台能够为最终用户提供某个需求链上的一站式服务，进而有效地增加用户对于平台的黏性；并通过对用户有针对性的实现应用版本更新提示、新应用推送，实现基于用户个体的精细化服务。

笔者认为，无论针对哪个行业领域抑或是满足哪些用户特定需求的开放平台，都应当包括如下4个基本部分：能力开放引擎、应用开发工具、应用运行环境和应用销售商店。下面将针对每个部分的基本功能及细分模块做简单说明。

（1）能力开放引擎

能力开放引擎主要包括业务能力适配、开放业务认证、标准化开放业务接口以及业务接口监控4个模块，实现核心业务能力以及第三方业务能力的标准化开放。通过实现业务接口的统一性适配，达到开放业务的“热插拔式”管理；为了保障业务内信息的私密性以及业务间的隔离性，采用开放的用户认证和业务认证机制；最终以标准化的方式开放业务接口，同时对于接口的调用情况进行监控进而实现有效的业务流控。

（2）应用开发工具

为了使开发者方便快捷地利用第三方开放服务能力开发出符合需求的应用，同时该应用又能够规格化地部署和交付到应用运行环境中，开放平台需要提供一系列的开发工具集。其中开放服务组合构件主要实现Web应用的可视化开发；移动App构建器主要实现利用第三方开放服务快速进行移动应用的开发；测试沙箱为应用的测试系统提供虚拟的测试环境；模拟器为应用的展示提供模拟运行环境。

图10 开放平台技术架构建议

（3）应用运行环境

为了使应用程序易于构建和维护，并可根据访问量和数据存储需要的增长轻松扩展资源，开放平台为开发者提供了统一的应用运行环境。该环境主要支持Web应用和移动应用（主要指移动应用的服务器端）两种，并利用监控模块实现应用对于资源使用情况的统计及简单分析；集群管理和应用路由模块主要实现对于高并发访问时服务的分流及底层资源的调度。

（4）应用销售商店

主要包括应用管理和用户管理，同时针对移动应用在移动端提供App Zone。其中应用管理主要实现Web应用以及移动应用的发布、交付、推送等功能；用户管理主要实现推荐、统计等功能；App Zone主要是针对移动应用实现版本更新提示、新应用推送等功能。

目前很多开放平台要么侧重于面向开放者为其提供开放的服务能力、能力的集成开发工具以及应用的部署运行环境，比如Google App Engine、AWS等；要么侧重于面向最终用户为其提供应用的浏览、下载以及推送，比如现在的很多App Store和Android Market。笔者认为，将两者整合，为开发者和用户提供一站式服务的平台架构（如上所述），将成为未来开放平台的一个趋势。

6 结束语

作为促进互联网“长尾”业务模式快速发展的重要手段之一，开放平台的发展得到了国内外产业界的广泛关注。本文针对开放平台发展的两个关键因素——运营模式和技术架构展开深入研究，在充分分析国内外主要开放平台现有优势和主要问题的基础上，给出了相关建议，期望本文的介绍能够对于开放平台的发展形成良好的参考价值。

1 Metcalfe B.The next-generation internet.IEEE Internet Computing,2000,4(1):58～59

2 Yinghui Huang，Guanyu Li.Descriptive models for internet of things.Proceedings of2010 International Conference on Intelligent Control and Information Processing (ICICIP),2010:483～486

3 Lee J K.Web 2.0 and OpenAPI.NHN,KRNet 2006

4 Wikipedia OpenAPI.http://en.wikipedia.org/wiki/Open_API

5 Chun H,Li X,Chau M,et al.Using open Web apis in teaching Web mining.IEEE Transactions on Education,2009,52(4):482～490

6 Tanaka S,Shina H,Yamada T,et al.High performance platform for multiple OpenAPI.Proceedings of 10th International Conference on Telecommunications,2003:1259～1263

7 Lei Dongyu,Luo Nianlong.An application interactive platform integrating applications with OpenAPI into campus network.Proceedings of International Conference on Educational and Network Technology(ICENT),2010:473～477

8 Wikipedia Open Platform. http://en.wikipedia.org/wiki/Open_platform

9 开放平台.http://baike.baidu.com/view/4039572.htm

10 谭晨辉,刘青炎.OpenAPI出现、起源与现状.程序员,2008(7)

11 Eunyoung K,Kangtae K,Hoh P I.A multi-view API impact analysisforopen SPL platform.Proceedingsofthe 12th International Conference on Advanced Communication Technology(ICACT),2010:686～691

12 Hai-Hong,Song Mei N,Song Jun D,et al.A new service delivery open platform(SDOP)architecture.Proceedings of IEEE International Symposium on IT in Medicine&Education,2009:404～409

13 Zeng Liangzhao,Hsueh Pei Y,Chang H,et al.Greenolive:an open platform for wellness management ecosystem.Proceedings of 2010 IEEE International Conference on Service Operations and Logistics and Informatics(SOLI),2010:88～93

14 李大维.开放平台大势图.程序员,2009(8)

15 易观国际.中国互联网开放平台专题研究报告,2011

16 http://developers.facebook.com/

17 Google App Engine.http://code.google.com/intl/en/appengine/

18 Amazon Elastic Compute Cloud (Amazon EC2).http://aws.amazon.com/ec2/

19 Amazon Elastic Beanstalk.http://aws.amazon.com/elasticbeanstalk/

20 App Store.http://www.apple.com.cn/iphone/built-in-apps/app-store.html

21 Tencent Open Platform.http://open.qq.com/

22 孙颖.淘宝开放平台.程序员,2009(8)

23 百度开放平台.http://open.baidu.com/

24 框计算官网.http://boxcomputing.baidu.com/index.html#

25 探索Google App Engine背后的奥秘.http://www.dbanotes.net/arch/google_app_engine-arch_intro.html

26 Explore the mystery behind the Google App Engine(3)-Google App Engine Introduction

27 Explore the mystery behind the Google App Engine(3)-Google App Engine Architecture

28 Prabhakar Chaganti Ylastic.Cloud computing with Amazon Web Services.http://www.ibm.com/developerworks/cn/web/ar-cloudaws1/,2009

29 Hazelhurst S. Scientific computing using virtual highperformance computing:a case study using the Amazon elastic computing cloud.Proceedings of the 2008 Annual Research Conference of the South African Institute of Computer Scientists and Information Technologists on IT Research in Developing Countries:Riding the Wave of Technology ACM,2008:94～103

30 Evangelinos C,Hill C.Cloud computing for parallel scientic HPC applications:feasibility of running coupled atmosphereocean climate models on Amazons EC2.Ratio,2008,2(2):2～34

31 Wang G,Ng T E.The impact of virtualization on network performance of amazon EC2 data center.Proceedings of IEEE INFOCOM,2010

32 Hewit A,Forte A.Crossing boundaries:identity management and student/faculty relationships on the Facebook.Proceedings of CSCW’06,Banff,Alberta,Canda,2006

33 Acquisti A,Gross R.Imagined communities:awareness,information sharing,and privacy on the Facebook.Privacy Enhancing Technologies,2006:36～58

34 MSNBC.Red tape facebook ID theft targets friends.http://redtape.msnbc.msn.com/_news/2009/01/30/6345792-facebook-idtheft-targets-friends,2009

35 Action Fraud.Profile stalking facebook scam.http://www.actionfraud.org.uk/profilestalking-facebook-scam-may11,2011

36 B ates D.Facebook cyber bullying:schoolgirls arrested for creating fake page with naked pictures.http://www.dailymail.co.uk/news/article-1347034/Facebookcyberbullying-Schoolgirlsarrested-creating-fake-page-nakedpictures.html,2011

37 Windows Azure.http://www.microsoft.com/windowsazure/

38 Chappell D.Introducing the Azure services platform.White Paper,Oct 2008

39 关于淘宝开放平台的战略规划.http://blog.csdn.net/mylove 2362004/article/details/4832106

40 岑文初.淘宝开放平台架构设计与实践.http://www.baowei.org/blog/uploadfile/200909/SACC2009_network/2.pdf

41 岑文初.透明是开放平台成功的关键——淘宝开放平台基础组件介绍.程序员,2011(3):60～61

42 人人网开放平台技术架构.http://wiki.dev.renren.com/wiki/

43 人人网开放平台OAuth2.0.http://wiki.dev.renren.com/wiki/Authentication

44 人人网开放平台API.http://wiki.dev.renren.com/wiki/API

45 人人网开放平台Widget API.http://wiki.dev.renren.com/wiki/Widget_API

46 彭胜君.开放平台第三方开发者的管理策略.信息网络,2010(6)

47 詹新惠.开放平台的喜与忧.人民网,2011-06-15

48 郑柯.中国“开放平台”和“OpenAPI”调查分析.程序员,2008(7)

Open Platform:Operation Mode and Technical Architecture

Ma Lin1,Song Junde1,2,Song Meina1
(1.Department of Computer Science,Beijing University of Posts and Telecommunications,Beijing 100876,China;2.Bright Oceans Inter-Telecom Co.,Ltd.,Beijing 100093,China)

This paper analyzes the operation mode and technical architecture of the existing open platforms,and gives the proposal of open platform.Firstly,it introduces the background of the open platform,and explains the definitions and classifications of the open platform.Secondly,it analyzes the operation mode of the domestic and foreign main open platforms,one by one.Thirdly，it introduces the technical architecture of the domestic and foreign main open platforms,in detail.On the basis of the above analysis,it points out the main problems of the current open platforms in China.At last,it gives the development proposal of open platform,from the operation mode and technical architecture.

open platform,open service,operation mode,technical architecture

2012-05-14）