• Feeds

  • Archive for June, 2009


    国内开放API平台实践的一些问题

    随着在国外一些开放API的成功,国内开放的趋势尤其是在SNS领域也开始涌现,实际上开放的需求不局限SNS领域,所有的互联网应用都可以从开放API获得更多的用户使用等潜在的价值。Tim在这方面也进行了一些尝试和思考,这里初步探讨开放API产品及开发方面实践中需要面对的几个问题。

    一、设计开放API没有明显的标准可以遵循

    • 如何设计一个好的鉴权(authentication)体系,安全,便利,简单。
    • 如何设计一个好的用户SSO(Single Sign-On)体系,达到无缝的在第三方网站与平台之间切换,或者支持将平台的内容无缝嵌入第三方网站,类似facebook connect这样的体系。
    • 国外的一些标准是否适合引进,比如OpenIDOAuth,OpenID国内还没有成功案例或领头羊,因此支持OpenID的用途就大打了折扣。OAuth解决了平台对第三方应用的信任(authorization)问题,但对于国内的第三方开发者是否太复杂。

    二、缺少深度理解开放平台设计的产品及开发人员

    国内大部分从业人员可能都没一手接触国外的开放平台产品及API,可能没写过一个hello world的Facebook应用,说不出Gadget的原理或者理解twitter client跟服务器交互的具体流程。大部分从业人员可能简单的理解facebook就是开心网一样。因此即使有意愿也很难设计出能真实满足用户需要的接口。

    三、没有生态圈或者短期不能形成生态圈

    Facebook的魅力就是从f8 2007推出到2008 f8已经形成40万开发者的规模,这40万开发人员对Facebook Platform的稳定及成熟起了非常重要的作用。但对于国内每一个新的开放平台可能设计人员并不清楚下游开发者在哪里,也很难进一步了解潜在的需求,很容易造成闭门造车的局面。

    四、不清楚盈利模式

    由于找不到清晰的赢利模式,不但对于提供平台的公司还是对于下游的开发者都缺乏推动力,所以大部分公司都是抱着试试看的心态去公开一些非核心的API。另外平台本身也有顾虑开放API是否会对本身原有的业务带来冲击,因此在公司内部也不太容易得到大力的支持,所以都是在小圈子内充当着试验田的角色。

    Yahoo!的分布式数据平台PNUTS简介及感悟

    在分布式领域有个CAP理论(Brewer’s CAP Theorem) ,是说Consistency(一致性), Availability(可用性), Partition tolerance(分布) 三部分在系统实现只可同时满足二点,没法三者兼顾。所以架构设计师不要把精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍,选取最适合应用需求的其中之二。比如MySQL 5.1 cluster设计前显然不知道有CAP理论这样的经验, 所以MySQL cluster表面看来尽管可提供所有分布式特性,但实际大部分场合都无法提供稳定可靠的服务。

    Yahoo!的PNUTS是一个分布式的数据存储平台,它是Yahoo!云计算平台重要的一部分。它的上层产品通常也称为Sherpa。按照官方的描述,”PNUTS, a massively parallel and geographically distributed database system for Yahoo!’s web applications.” PNUTS显然就深谙CAP之道,考虑到大部分web应用对一致性并不要求非常严格,在设计上放弃了对强一致性的追求。代替的是追求更高的availability,容错,更快速的响应调用请求等。

    1. PNUTS简介及特点

    • 地理分布式,分布在全球多个数据中心。由于大部分Web应用都对响应时间要求高,因此最好服务器部署在离用户最近的本地机房。
    • 可扩展,记录数可支持从几万条到几亿条。数据容量增加不会影响性能。
    • schema-free,即非固定表结构。实际使用key/value存储的,一条记录的多个字段实际是用json方式合并存在value中。因此delete和update必须指定primary key。但也支持批量查询。
    • 高可用性及容错。从单个存储节点到整个数据中心不可用都不会影响前端Web访问。
    • 适合存相对小型的记录,不适合存储大文件,流媒体等。
    • 弱一致性保证。

    传统的数据库提供强一致性保证, 通常称为“serialization transaction”,保证调用时序的一致性。但在web应用中不是必须,比如用户A修改了自己的资料或上传了图片,他的好友B短时间不能立即看到并不是大的问题,通常的Web应用都可以接受。PNUTS像大部分分布式key/value系统类似,提供的是弱一致性的支持,也就是支持“最终一致性(eventually consistent)”。用户B最终会看到用户A的修改信息。

    未够!但最终一致性并非可以适应所有场合,比如用户A修改了相册的访问权限,设置用户C不能访问,然后用户A又上传了新的图片,如果用户C处于另外一个IDC访问,如果图片数据先同步成功,而权限记录后同步的话,C实际上违反了A设置的权限而看到图片了。因此对于部分场合最终一致性是不够的。

    2. PNUTS实现

    2.1 Record-level mastering 记录级别主节点

    每一条记录都有一个主记录。比如一个印度的用户保存的记录master在印度机房,通常修改都会调用印度。其他地方如美国用户看这个用户的资料调用的是美国数据中心的资料,有可能取到的是旧版的数据。非master机房也可对记录进行修改,但需要master来统一管理。每行数据都有自己的版本控制,如下图所示。

    pnuts-4

    2.2 PNUTS的结构

    pnuts-1
    每个数据中心的PNUTS结构由四部分构成
    Storage Units (SU) 存储单元
    物理的存储服务器,每个存储服务器上面含有多个tablets,tablets是PNUTS上的基本存储单元。一个tablets是一个yahoo内部格式的hash table的文件(hash table)或是一个MySQL innodb表(ordered table)。一个Tablet通常为几百M。一个SU上通常会存在几百个tablets。
    Routers
    每个tablets在哪个SU上是通过查询router获得。一个数据中心内router通常可由两台双机备份的单元提供。
    Tablet Controller
    router的位置只是个内存快照,实际的位置由Tablet Controller单元决定。
    Message Broker
    与远程数据的同步是由YMB提供,它是一个pub/sub的异步消息订阅系统。

    2.3 Tablets寻址与切分

    存储分hash和ordered data store。
    pnuts-31
    以hash为例介绍,先对所有的tablets按hash值分片,比如1-10,000属于tablets 1, 10,000到20,000属于tablets 2,依此类推分配完所有的hash范围。一个大型的IDC通常会存在100万以下的tablets, 1,000台左右的SU。tablets属于哪个SU由routers全部加载到内存里面,因此router访问速度极快,通常不会成为瓶颈。按照官方的说法,系统的瓶颈只存在磁盘文件hash file访问上。
    当某个SU访问量过大,则可将SU中部分tablets移到相对空闲的SU,并修改tablet controller的偏移记录。router定位tablet失效之后会自动通过tablet controller重新加载到内存。所以切分也相对容易实现。
    Tim也曾经用MySQL实现过类似大规模存储的系统,当时的做法是把每条记录的key属于哪个SU的信息保存到一个字典里面,好处是切分可以获得更大的灵活性,可以动态增加新的tablets,而不需要切分旧的tablets。但缺点就是字典没法像router这样,可以高效的全部加载到内存中。所以比较而言,在实际的应用中,按段分片会更简单,且已经足够使用。

    2.4 API访问

    支持多种级别的数据访问API:
    • Read-any 读取的版本有可能是旧的,返回本地IDC的数据,不检查最新版本,性能最好。
    • Read-critical(required_version) 读取指定版本,用户修改资料之后调用返回比当前版本更新的版本,以保证当前用户看到的不是修改前的记录。
    • Read-latest 强制读取最新,可能需要执行远程IDC调用。比如上面例子介绍的读取权限列表的调用。
    • Write 比如更新用户资料
    • Test-and-set-write(required version) 只有当记录属于指定的版本才执行write,比如更新用户积分等业务,这个调用有点类似以前介绍的atom操作

    Write调用示意图pnuts-3

    3. PNUTS疑问

    记录级别master的问题,比如master选取如何达到效率最佳,如何面对2个修改合并冲突?合并冲突据说是需要client自行来处理,

    这篇Details on Yahoo’s distributed database提到的平均调用latency 100ms的问题。web应用通常对每次数据的访问最好在10ms之内完成,因为每个web页面实际上不止一个数据访问的调用,经常调用10次以上db的访问的页面并不少见,因此如果平均latency在100ms以上那势必影响页面加载速度。不过yahoo!的开发人员回复paper中的数据实际是一个老版本的测试,目前的版本,在实际生产环境的pnuts的latency会在10ms以下。

    另外PNUTS为什么要用消息系统代替replication/undo log?有何优点?

    4. PNUTS感悟

    Web应用使用通用的存储服务是大势所趋,类似BigTable, Amazon Dynamo/SimpleDB这样的方案,但是目前除非使用Amazon提供的商用SimpleDB之外几乎没有通用的解决方案,每个公司甚至每个项目需要面对及考虑数据规模增大的问题。比如初步统计下国内研究可扩展数据存储及访问的项目就有

    • 手机之家的数据访问层封装DAL 2.0
    • 盛大陈思儒写的开源项目Amoeba,类似MySQL proxy
    • 国内的Erlang geek @litaocheng 曾经对Dynamo paper深有研究,正在开发开源的erlang Dynamo实现e2dynoma
    • 豆瓣的doubanDB,也是类Dynamo实现

    当然上面几个只是冰山一角,大部分互联网公司都有自己的数据层分布及访问实现,只不过没有对外公开而已。架构师、DBA、程序员具备这方面的实践经验及技能当然是好事,但是如果业界能够有通用稳定的解决方案来解决大家的重复工作则对整个业界更佳。PNUTS虽然声称会开源,但是一直没有进一步消息。而且即使开源是是开放核心代码还是全部可用于部署的程序(比如YMB等)这也是一个问题。

    当然,我不是第一个也不是最后一个考虑这个问题的,比如2006年Greg Linden就说I want a big, virtual database

    What I want is a robust, high performance virtual relational database that runs transparently over a cluster, nodes dropping in an out of service at will, read-write replication and data migration all done automatically.

    I want to be able to install a database on a server cloud and use it like it was all running on one machine.

    参考资料

    Facebook平台设计(一)

    为了研究Facebook platform的设计, 我们可以从最早的第一个版本f8 07开始了解,当时是由Facebook创始人兼CEO Mark Zuckerberg 在2007年5月f8开发者会议上发布的。根据当时的数据是,50%以上的Facebook用户会每天都访问Facebook,超过同行3倍以上。

    为了理解Facebook平台,我们可以从Facebook相册说起。Facebook相册虽然只提供了最简单的特性,比如不能存高像素原图,没有编辑工具等,非常简单,但是Facebook的相册流量是是其他所有相册(Flickr, Picasa…)流量之和的2倍以上。为什么?这就是Mark介绍的Social Graph的力量。

    1. 用户A上传图片,他所有好友都能看到。

    2. 用户A继续在图片上tag people(标注图片上的好友),这个tag的图片会出现在被tag好友B profile wall上,接着B的好友接着可以看到这个图片(受privacy设置控制,默认开启)。

    特别是第2点它扩大了传播范围,在Facebook认为,第2点比1更为重要,Facebook平台的意义就是在这里。”we build the platform optimize for build apps for social graph”,开放平台的意义就是让扩展应用将social graph发扬光大。

    “在Facebook开放平台以前,social network封闭式平台,但是今天这种情况结束了”

    Facebook Platform的三大目标

    1. Apps深度整合到Facebook平台(Deep Integration Into Facebook Website)

    • app可以集成到用户profile
    • app拥有独立的首页(canvas page),首页完全是应用自己控制的,可放任何内容,包括广告。
    • app可以以用户身份发布feed
    • app可以发送消息,邀请,提醒等

    一个应用只要被用户授权访问他的profile之后,应用就可以调用api获取到比如user/friend/application/privacy information,Facebook API接口也值得各种平台设计者学习。比如用户API接口

    2. 病毒式的传播(Mass Distribution through the Social Graph)

    传播的核心是feed体系(从09年的眼光来看,Twitter的feed可能比它做得更出色,甚至造成了威胁,并进一步引发它最近的homepage改版)。App可以发布3种不同类型的Feed

    • application story,相当与应用添加提醒,比如A添加了某应用。
    • simple story, feed里面表现为一行文本。
    • full story, 详细,可以预览图片,视频等。

    关于feed可参看另外一篇技术分析文章:Facebook的feed格式设计

    App可以发送notification(提醒),request(邀请)。Facebook还提供平台级别的工具如friend selector供app使用。Facebook还通过应用嵌入到Profile通过exposure让更多的用户来使用,比如用户看到好友Profile某个应用有趣也会立即add。

    通过以上途径,促进应用的传播,促进信息的传播,促进人的社会化交流。

    3. 商业机会(New Business Opportunity)

    canvas page可以放任何广告,也可以进行电子商务进行销售,app可以获得所有收入。对于这两种方式,Facebook都是持支持态度。

    视频:Mark Zuckerberg Keynote Speech f8 2007
    http://www.facebook.com/video/video.php?v=28202665043&ref=mf

    12