记一个社交APP的开发过程——基础架构选型

目录[-]

基本产品形态
技术选型

最近两周在忙于开发一个社交App，因为之前做过一点儿社交方面的东西，就被拉去做API后端了，一个人头一次完整的去搭这么一套东西，上面也没有PM和各种催促，过程还是很轻松愉快充满乐趣的，现在后端已经基本完成，下周会进入联调测试的阶段，有些东西想写一写记录一下，先从技术选型开始。

基本产品形态

产品的基础功能无非是所有社交App都具备的那些东西，新鲜事、好友关系(同微博一样，单向follow)、地理位置（当前的位置、你附近的人）更多小的细节和功能点现在还不便于透露 :)

其实社交这种产品给我的感觉一直是挺怪的，相对于技术和那些抠交互的产品分析来说，这东西更让人着迷的是一种心理魔术，比如上面说道约炮App，你可能会想到陌陌，但是陌陌的产品层面上跟众多社交App是一样的，也是feed、follow和地理位置，而我们正常的社交，正常的朋友圈子用的最多的是微信而不是陌陌，但当夜深人静你想打发掉寂寞的时候，可能就会去用陌陌了，虽然功能和技术相似，但是一些产品细节对用户的暗示却造成了全然不同的结果，就跟QQ、MSN、Gtalk之间的感觉类似，虽然它们的主要功能都是聊天，但是各自的用户群和使用氛围完全不同。结合自身的需求，去体验目标用户的心理，想办法满足自己和用户的心理诉求，这也是做社交类型产品最大的乐趣吧。

技术选型

最开始的技术选型秉着简单清晰、尽快实现想法，减少复杂的引入，但是要尽量为以后的扩展做好准备这么一种想法。很多互联网创业心灵鸡汤比如《黑客与画家》、《Rework》也都大概是这么提倡的，先把东西迅速做出来，然后根据用户的回馈发现问题快速迭代。下面介绍一下我选用的技术栈：

1. 语言:

人生苦短，我用Python

2. 存储和数据访问工具：

这年代存储面临的选择的确很多，但我还是选择自己最为熟悉的MySQL，原因不必多说。根据之前的经验，像是用户表这种会保持不动，但是有些表，比如feed index我在一开始就做了sharding的处理（关于feed的实现和存储结构我在后面会进行介绍）。另外很重要的东西就是数据访问层的实现了，虽然有些东西，比如读写分离的支持，现在不会用到，但是我觉着要支持，最起码要考虑这种情况将来会发生，到时候不至于太苦逼的到处重写代码，另外对于sharding，要做到跟访问通常的表类似的轻松，最后要带点儿ORM功能。

做的第一件事情就是写这个数据访问工具，业务就是增删改查么，没有这家伙还怎么活！？用python两三百行代码对web.py的数据访问模块做下包装就搞出这么一个东西来，https://github.com/chihongze/shard.py 最终可实现读写分离和对sharding的支持。当然在用的过程中发现问题不少，有些查询不能很好的满足需求啊等等，完善中。

3. 缓存

因为这个项目属于80/20那种课余爱好，资源较少，最开始也不想大推，只是给周围的小伙伴们先玩玩，程序员怪叔叔搏妹子一笑什么的，能有两三台机器就很不错了，所以对于传说中的分布式缓存，想想还是算了，多数东西还是直接读库，但是还是搭了个Redis，做啥用？主要是三件事情：1、保存token 2、记录用户在线状态 3、防刷业务 “你输入的太快了，请休息一下继续”之类的。但是所有数据的获取还是走的存储层，到时候如果要加缓存，可以直接在存储层去加，而不必去侵犯上层业务逻辑。

4. 静态存储

做社交对图片的质量要求是很高的，多数都是会在后台专门拿出机器搭image magic等切图服务，但对于初创的社交app，搞这种东西挺耗费资源的，考虑了性价比、开发成本，就直接使用了又拍云的服务，瞬间就搞定了图片存储和处理的问题。

5. 消息队列

对于社交来说，很多事情，比如你有几万个粉丝关注，我要把你刚发的一张裸照推送给这一万个人，那么肯定不能等所有推送完毕再返回给你结果，那会等的不耐烦的，我会立即给你返回发送成功的结果，而把推送这件事情放到幕后，让它自己去玩。这样的需求情景有很多，这时就需要用到消息队列了。消息队列的产品也有很多可以选择，http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html 这篇文章对现在流行的消息队列做了下大概的介绍。个人对消息队列选择的观点，一是稳定，出了错好恢复，二是容易监控，队列堵了啊什么的我能很方便的监控到，三是并发性，四是接口要容易使用。这四点，RabbitMQ明显胜出。就选用RabbitMQ了。关于RabbitMQ使用的一些细节，会在feed分发的时候做相关介绍。

7. API Server

API全是RESTful的，用的web框架是web.py，目前调试阶段还只是web.py直接对外给客户端的同学做调试，上线后准备走Nginx的反向代理，另外最近也在研究这个项目：http://www.oschina.net/p/gunicorn 可以选择Nginx + wsgi模块 + web.py的模式，也可以是gunicorn + web.py， nginx再反向代理到gunicorn。

对于通常的API,使用web.py容易满足，但是对于我们这个应用来说，私聊是一个最为重要的功能，因此打算把聊天的服务拆出来了，单独拿tornado去做，tornado做长链接更专业一些，不同于web.py，tornado本身就是一个异步的web框架，像Node.js那样。

总体的技术选型就是这些东西吧，非常简单，都是很成熟的一些技术，也没有用什么新东西，但开发起来还是蛮爽的，尤其是Python的开发效率更是没的说，比如那个支持sharding的数据访问工具，原先用Java做过类似的事情，对Spring Jdbc Template做的封装，貌似写了十几个类文件，搞了好多天，现在用Python 两三百行直抒胸意一上午就秒掉了，开发效率完全不一个档次，哈哈哈。