记一个社交APP的开发过程——基础架构选型(转自一位大哥)

时间:2024-03-06 07:08:21

记一个社交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 两三百行直抒胸意一上午就秒掉了,开发效率完全不一个档次,哈哈哈。