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，就先到这里，后续会再继续往深入的方面进行讲解，包括关系链，好友邀请，金币等等。
之前已经已经写过一篇《从开放平台建设者角度对应用开发者的一点架构建议(1)》，主要是介绍了最基本的openid、平台数据、应用内部数据的存储建议，这一次我们更深入一点。
对之前的文章，我们提到了三种数据：
- openid-id
- id-平台数据
- id-应用数据
相信大部分个人开发者的第一反应是，上面每份数据建一张表，之间建立很多外键关系。这样的确会有很大的好处，很多数据查询操作都可以直接通过sql语句完成，比如:
- 通过openid查询id
- 通过id查询openid
- 通过用户名查询openid/id
- 通过应用数据查询openid/id
上面的架构都很好的，并且开发成本非常低，但是这一切的前提是你的应用的用户量有多少。
100w是个坎，100w之前没有任何问题，100w之后，这种架构就是垃圾
很多人会说，对于一个小应用，考虑那么大量用户干嘛？你这是过度设计了吧。
有这种思想的人不少，没错，当年facebook过100w用户的时候，已经是一家有很多职员的公司了。那你会不会觉得，当我们的小应用成长为100w用户的时候，我们已经有了足够的资金，足够的职员，可以考虑重构了？
然而事实是，zynga新推出的游戏《帝国与同盟》在facebook上上线一周，日活跃就达到3000w，更别说注册用户量。而就国内的情况来说，在朋友网上面的任何一款应用，只要不是太差，1~2个月，注册用户基本就可以轻松达到100w。
是不是有些震撼？SNS应用的病毒式传播能力远超过我们的想象，而这所带来的结果，除了利益之外，在技术上也对架构提出了更高的要求。
请别误会我的意思，我并不是说一个个人开发的应用，一开始就要考虑 读写分离，异步写，将二层架构（webserver+db）变成三层架构（webserver+cache+db）甚至四层架构(webserver+logicserver+cache+db)，我的意思是，大系统开始要小做，但是不代表不给以后留下扩展的接口。
OK，到此为止，我所要表达的观点基本已经出来了：
对于一个小团队来说，我们可以继续保持webserver+db的两层结构，但是要为以后留有适当的扩展接口
听起来似乎有些抽象，但是实施起来却很简单：
- 分库分表，即使所有的都库表都放在同一个mysql实体机上
- 要封装出数据库访问层，上层不需要知道访问的是的memcache还是mysql
- 将很多太依赖mysql的查询，放到业务层（比如自增key，比如外键查询）
按照上面的原则，如下的问题就可以得到解决：
- 注册用户数超过100w，导致单表查询性能降低，以及单机存不下的问题
- 数据访问频率变高，导致mysql需要迁移到memcache的问题
OK，那么根据这个原则，我们从新来设计一下我们的底层数据库结构。
首先，冗余出一份id-openid的数据，来支持id到openid的查询。
原来我们只有openid-id这样一个映射表，是因为mysql也可以直接通过id查询openid，然而一旦分库表之后，就不得不再冗余一份id-openid的映射表，但也确实是没有办法的事情（当然，如果你技术够牛，也可以自己实现一个双key cache）。
第二，将所有自增key的地方，替换为在某个地方存放当前id的最大值。
既然要抛弃自增生成id的方法，那我们就需要一个地方来存储当前的最大id的值。这里用一个表来记录就可以了，因为毕竟每秒新注册的用户还是很少的
第三，将openid-id,id-openid,id-平台数据,id-应用数据，分库分表。
最简单的方法就是取模，id=1234，如果10库10表的话，千位和百位对应库，十位和个位对应表，那就是db_2和tb_4。当然，在某些框架，如django上不方便分表，那么也可以只分库，比如分100库，落到db_34。我们这里采用只分库，不分表的方式，我们分1000库，这样等到你有10亿用户的时候，每个表也才100w条记录，一定是够用了。
具体怎么分呢？实际上，我们有更简单的方法，如下:
库名 | 包含的表 |
db_app_single | id_alloc |
db_app_openmod_0 ~ db_app_openmod_999 | openid2id |
db_app_idmod_0 ~ db_app_idmod_999 | id-openid id-平台数据 id-应用数据 |
OK，这样我们整个架构对于抗大量用户的能力就大大加强了，而且扩展性也比原来的架构要好很多。以后一旦访问量的瓶颈达到之后，我们就可以把db的直接访问变成访问cache，或者考虑其他的优化方案，如前面提到的读写分离，异步写等等。
好啦，就这样~，希望文中的建议能给已经是个人应用开发者，或者即将成为个人应用开发者的朋友有所帮助~
