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

记一个社交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，作啥用？主要是三件事情：一、保存token 二、记录用户在线状态 三、防刷业务 “你输入的太快了，请休息一下继续”之类的。可是全部数据的获取仍是走的存储层，到时候若是要加缓存，能够直接在存储层去加，而没必要去侵犯上层业务逻辑。

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 两三百行直抒胸意一上午就秒掉了，开发效率彻底不一个档次，哈哈哈。