从开放平台建设者角度对应用开发者的一点架构建议(1)

2011年，各大平台相继开放，相信关注的朋友都应该知道，6月15日，腾讯也召开了开发者大会，在这里笔者不想就开放本身做太多讨论，作为一个技术博客，我们还是专注讨论技术架构吧。

笔者在腾讯主要负责腾讯开放openapi的开发，也确实见到了不少应用由于架构不当，导致开发维护成本非常高的例子，更重要的是接入成本非常高导致落在了别的应用后面，所以，笔者在这里会结合腾讯开放的一些特点，给应用开发者一点建议。

如果有朋友致力于应用的开放，希望能有所帮助。

我们就从最基本的地方开始说起吧。

开放平台都会提供一个openid，一个openid对应平台上面的一个真实帐号，在腾讯当然就代表的是QQ号。通过openid就可以或者某个人的个人信息，他的好友关系链等等信息。

那么，怎么让openid与应用自身的数据关联起来呢？

这是我所见到的第一种架构:

一.openid直接作为主键

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

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

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

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

个人数据表

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

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

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

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

校友个人信息表

空间个人信息表

应用内部数据

这样做了之后，应用数据和平台数据就完全分割开来了，这样做了之后对于平台接入这一层基本上可以做到完全的屏蔽，也可以保证应用的数据不会和平台数据揉杂在一起。

当然，这样做也不是完全没有缺点的，最大的缺点即如果你是使用数据库直接访问，那么就需要访问数据表3次，这对于大访问量的数据来说的确是很大的开销。
但是这也并不是不能解决的，如果访问量真的到了一定级别，我们只需要在web层和db层之间加一层cache，而这层cache是混排了不同平台的三张表的数据的，校友访问的cache ip与空间的cache ip是不一样的（比如校友访问的cache是混排了openid-id、校友信息、应用内部数据，空间混排的是空间的信息与其他两张表），这样才是正确的解决访问量的方法，而不是为了提高性能就去将底层架构弄乱。

可维护性与性能是同样重要的东西，而且在用户量级没有达到的情况下，可维护性的重要性要远高于性能的重要性。

OK，就先到这里，后续会再继续往深入的方面进行讲解，包括关系链，好友邀请，金币等等。

原创文章，版权所有。转载请注明：转载自Vimer的程序世界 [ http://www.vimer.cn ]

本文链接地址: http://www.vimer.cn/?p=2246

Posted in: 开放平台 by Dante,2,054 views Tags: openapi, 应用开发, 开放, 开放平台, 腾讯开放, 腾讯开放平台

较旧一篇« vimgtd-在vim(gvim)中实现GTD时间管理！【本博原创插件】

Vi-查询卡片»较新一篇

11 个评论 在 “从开放平台建设者角度对应用开发者的一点架构建议(1)”

1. 荒野无灯 说：

2011年07月3日 于 9:50 下午

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

[回复]

2. freeeyes 说：

2011年07月4日 于 9:36 上午

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

[回复]

Dante 回复:
七月 4th, 2011 at 9:41 上午

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

[回复]

3. 识字 说：

2011年07月7日 于 3:56 下午

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

[回复]

4. fy 说：

2011年07月17日 于 2:06 上午

建议你的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也不能少。

[回复]

Dante 回复:
七月 17th, 2011 at 8:35 下午

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

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

[回复]

5. fy 说：

2011年07月17日 于 2:15 上午

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

收藏之 。。。。。

[回复]

Dante 回复:
七月 17th, 2011 at 8:35 下午

哈哈，这就是默认的URL~

[回复]

6. zjstandup 说：

2011年08月6日 于 8:37 上午

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

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

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

[回复]

7. simomo 说：

2011年08月12日 于 8:46 上午

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

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

[回复]

Dante 回复:
八月 12th, 2011 at 7:08 下午

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

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

[回复]

从开放平台建设者角度对应用开发者的一点架构建议(1)