写在前面: 博客很久没有更新了，主要是事情实在太多，不过最近也确实做了些比较有价值的事情，后面和大家慢慢分享

笔者在腾讯主要负责开放平台openapi的工作，由于工作关系，这几天遍历了 百度、人人、新浪、淘宝 4个平台，研究了一下他们对于站内应用、网站登录、移动应用的整合方式，并开发了一个百度站内应用的demo。

百度站内应用demo: 体验地址(要体验的话，请先联系我开通白名单): http://app.baidu.com/app/enter?appid=385894&debug=1&is_from_dev=1&canvas_pos=platform

代码已经开源在github上: https://github.com/dantezhu/baidu_app_demo，里面封装了一个baidu的sdk，有需要的朋友可以直接拿去用。

开发语言用的是 python+flask 移动应用 和 网站接入，这两种接入都是走的oauth的方式，这个基本所有平台都是一样的。

而对于站内应用则和腾讯目前不太一样，所以着重说明一下在这里的处理,仅以百度举例:

百度的教程在这里： 百度站内应用开发文档

1. 当用户点击应用列表进入时 ...

这次QCon在杭州举办，有幸作为腾讯开放平台部派出的讲师参加，对外分享了《腾讯开放平台的OpenAPI设计》，演讲的ppt已经由InfoQ在网上公布，文章末尾会贴出下载链接，有兴趣的朋友可以看看。

这几天也有很多思索和感悟，今天就和大家分享一下。

一. 切身的感觉到公司实在是 “做得多，说的少”，外界对腾讯的了解太少

“多做少说”当然好，毕竟是多干实事。

但是真的是想象中的那么好吗？ 我引用孔子的一个故事： 鲁国之法：鲁人为人臣妾於诸侯，有能赎之者，取其金於府。子贡赎鲁人於诸侯，来而让，不取其金。孔子曰：“赐失之矣。自今以往，鲁人不赎人矣。”取其金，则无损於行；不取其金，则不复赎人矣。 什么意思？就是如果大家都把“多做少说”作为标杆，那么“多做多说”是不是反而会受到鄙视，进而会不会“多做”都收到影响？ 所以虽然并非我所能控制，但是后续我也一定会做出努力，让公司对外的分享更开放一些。

二. 技术不在于有多强，而在于是否契合业务

大会上包括ebay，百度，阿里，腾讯都分享了自己的技术经验。对比了一下，其实对于这种海量服务的处理模式都差不多，无非是异步化，分布式，NoSQL等等。 但是不是我们看到这些牛B的技术就忘了那些基础的MySQL，Apache呢？ 我看未必 ...

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

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

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

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

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

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

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

一.openid直接作为主键

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

二.有自己的id ...