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、校友信息、应用内部数据，空间混排的是空间的信息与其他两张表)，这样才是正确的解决访问量的方法，而不是为了提高性能就去将底层架构弄乱。

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

建议继续学习：

1. 国内的开放平台就是一个玩笑    (阅读：2686)
2. 从开发者协议看各SNS开放平台的开放策略    (阅读：1528)