最后更新于 .

2011年,各大平台相继开放,相信关注的朋友都应该知道,6月15日,腾讯也召开了开发者大会,在这里笔者不想就开放本身做太多讨论,作为一个技术博客,我们还是专注讨论技术架构吧。 笔者在腾讯主要负责腾讯开放openapi的开发,也确实见到了不少应用由于架构不当,导致开发维护成本非常高的例子,更重要的是接入成本非常高导致落在了别的应用后面,所以,笔者在这里会结合腾讯开放的一些特点,给应用开发者一点建议。 如果有朋友致力于应用的开放,希望能有所帮助。 我们就从最基本的地方开始说起吧。 开放平台都会提供一个openid,一个openid对应平台上面的一个真实帐号,在腾讯当然就代表的是QQ号。通过openid就可以或者某个人的个人信息,他的好友关系链等等信息。 那么,怎么让openid与应用自身的数据关联起来呢? 这是我所见到的第一种架构:

一.openid直接作为主键

openid 主键
名称  
性别  
地点  
头像  
应用内部数据  

应用直接将平台的openid来做主键,即应用没有自身的id。 这种方式有什么问题呢?假设说你做的是一个有发展前景的应用,你的应用以后可能会接入facebook,人人,等等开放平台,而每个开放平台的openid格式又都不一样,那么你的数据库表设计将会每个平台的都有一部分不一样,而大部分业务逻辑又都一样,严重违反了“DRY”原则,增加了开发和维护的成本。 所以这种方式不好。

二.有自己的id,并且id、openid、数据放到一起

id 主键
openid unique
名称  
性别  
地点  
头像  
应用内部数据  

这样当拿到用户的openid时,首先会转化成应用内部的id,之后的一切逻辑操作都使用id。 但是这种方式,实际上和前一种没有太大区别,当你上不同的平台的时候,你的数据库结构仍然面临重写的威胁。

三.将openid、id与用户数据分割开

映射表

id 主键
openid unique

个人数据表

id 主键
名称  
性别  
地点  
头像  
应用内部数据  

OK,总结上面两次架构失败的教训,我们用了如下架构,这种怎么样呢? 的确,这套架构无论在上腾讯,人人,还是facebook都可以复用一套代码,如果openid不一样,无非是在openid转换id这一层做一层简单的封装即可。 但是这里的前提是腾讯、人人、fachbook之间的数据是不互通的,而在腾讯内部就有三个平台:空间、校友、微博,这三个平台的个人信息不一样,好友关系链不一样,但是腾讯方面的要求是:

同一个openid无论在哪个腾讯内部平台上,看到的应用数据都应该是一致的。

那么问题就来了,目前的架构中,个人信息表是和id绑定在一起的,即无法实现在校友登录的用户使用校友信息,在空间登录的用户使用空间信息,所以这套架构还是会有些问题。

四.将openid、id、平台用户数据和应用内部用户数据分割开

映射表

id 主键
openid unique

校友个人信息表

id 主键
名称  
性别  
地点  
头像  

空间个人信息表

id 主键
名称  
性别  
地点  
头像  

应用内部数据

id 主键
应用内部数据  

这样做了之后,应用数据和平台数据就完全分割开来了,这样做了之后对于平台接入这一层基本上可以做到完全的屏蔽,也可以保证应用的数据不会和平台数据揉杂在一起。 当然,这样做也不是完全没有缺点的,最大的缺点即如果你是使用数据库直接访问,那么就需要访问数据表3次,这对于大访问量的数据来说的确是很大的开销。 但是这也并不是不能解决的,如果访问量真的到了一定级别,我们只需要在web层和db层之间加一层cache,而这层cache是混排了不同平台的三张表的数据的,校友访问的cache ip与空间的cache ip是不一样的(比如校友访问的cache是混排了openid-id、校友信息、应用内部数据,空间混排的是空间的信息与其他两张表),这样才是正确的解决访问量的方法,而不是为了提高性能就去将底层架构弄乱。 可维护性与性能是同样重要的东西,而且在用户量级没有达到的情况下,可维护性的重要性要远高于性能的重要性。 OK,就先到这里,后续会再继续往深入的方面进行讲解,包括关系链,好友邀请,金币等等。

Pingbacks

  1. SNS应用开发架构建议(2)-如果你的用户量达到100w | 因美小宝 on #

    [...] 之前已经已经写过一篇《从开放平台建设者角度对应用开发者的一点架构建议(1)》,主要是介绍了最基本的openid、平台数据、应用内部数据的存储建议,这一次我们更深入一点。 [...]

  2. SNS应用开发架构建议 - 数据库 - 开发者 on #

    [...] 之前已经已经写过一篇《从开放平台建设者角度对应用开发者的一点架构建议(1)》,主要是介绍了最基本的openid、平台数据、应用内部数据的存储建议,这一次我们更深入一点。 [...]

Pingbacks已打开。

Trackbacks

引用地址

评论

  1. 荒野无灯

    荒野无灯 on #

    嗯,我看到wp 对分类、tag 等的处理上就是采用了映射表。

    Reply

  2. freeeyes

    freeeyes on #

    数据缓冲很重要,在我见过的很多系统中,数据库只负责存储和被cache获取的作用。而关系型数据库更多的好处是在数据聚合统计下的优势。

    Reply

    1. Dante

      Dante on #

      非常对!
      哈哈,这也是为什么底层要采用数据库的原因,当产品经理需要复杂的统计需求的时候,就可以直接在数据库条件查询。
      而对于大访问量的问题,我在文章最后也提到了cache混排的解决方案~

      Reply

  3. 识字

    识字 on #

    也没学过,呵呵,就来看看

    Reply

  4. fy

    fy on #

    建议你的url配置一下可以通过id来访问的,一大串中文很占地方,也不美观;当然,可以把你标题放到id后面,比如
    http://www.vimer.cn/2011/07/%E4%BB%8E%E5%BC%80%E6%94%BE%E5%B9%B3%E5%8F%B0%E5%BB%BA%E8%AE%BE%E8%80%85%E8%A7%92%E5%BA%A6%E5%AF%B9%E5%BA%94%E7%94%A8%E5%BC%80%E5%8F%91%E8%80%85%E7%9A%84%E4%B8%80%E7%82%B9%E6%9E%B6%E6%9E%84%E5%BB%BA.html
    这样的url,你贴到vim里面或者收藏到某处,不怎么好看吧?写成英文,或者加个id,似乎会好一点,你觉得呢?

    这篇文章对app开发者确实很有用,我们也是一直用这种方式,称之为 uid adapter,根据平台uid特性,一些不会超过int的平台openid,直接配置id为uid,qq的,就需要做uid的adapter...
    后面提到的缺点,我看得不是很明白,为了减少查询,在请求的时候,可以把应用id,平台openid一起带上,这样就可以减少查询,当然,session验证不能少,cache也不能少。

    Reply

    1. Dante

      Dante on #

      你好,url过长的问题的确挺纠结,因为目前这种方式的确对搜索引擎是最友好的……我看怎么把id的访问方式也放到文章末尾吧

      嗯,其实我说的查询三次是指,因为应用进入时,拿到的是用户的openid。这个时候我们需要先从openid拿到id,再用id拿到应用内部的数据,再用id取到平台的数据(这一步也可以去平台侧那边取)。
      所以一共三次,如果直接用openid为key,value是平台数据和应用数据的话,那么就只需要查询一次,不过代价就可扩展性极差,我很少看到有应用这么用。。

      Reply

  5. fy

    fy on #

    http://www.vimer.cn/?p=2246

    收藏之 。。。。。

    Reply

    1. Dante

      Dante on #

      哈哈,这就是默认的URL~

      Reply

  6. zjstandup

    zjstandup on #

    ID映射表最好加个字段:平台编号

    用户ID,(平台用户ID,平台编号) 联合唯一索引

    这样的话可以解决人人和Facebook都有个平台用户ID为1的情况

    Reply

  7. simomo

    simomo on #

    文章最后:
    我们只需要在web层和db层之间加一层cache,而这层cache是混排了不同平台的三张表的数据

    这个cache混排三张表是什么意思?
    是将三张表的内容重新装配成新的数据结构存到cache中嘛?
    我现在的项目中的cache只是根据查询条件生成cache 的 key,然后将查询结果作为value直接放入cache中。
    所以能详细的说一下这个“混排”吗?

    Reply

    1. Dante

      Dante on #

      是将三张表的内容重新装配成新的数据结构存到cache中嘛?

      可以这么理解哈,这样做会减少查询的次数,让一次查询就可以返回结果,但同时也增加上了数据一致性保证的复杂度,其实不是真的量到了那样的级别,还是不建议这么早就使用这种方法。

      Reply

  8. i_love_java@126.com

    i_love_java@126.com on #

    id 主键
    openid unique
    单这两个字段是不够的,除非保证各个第三方的openid绝对不会重复,这个我觉得各方openid规则应该都可以确保自己系统内唯一性,全球唯一性就不一定了。所以还应该有一个来源标识src 保证 openid 和 src 联合唯一

    Reply

发表评论