移动社交App服务端开发总结

我目前在一创业公司，开发一款移动社交app，作为服务端首席码农（服务端就我一个人啦），见证了服务端从无到有的全过程。客户端从最初上线至今5个月以来，迭代了8个版本，服务端淡定地表示毫无压力（当然， 这跟我们处于发展初期，用户量和数据量不大有很大关系）。我把这个过程分享出来，和大家交流一下，本文不谈具体的技术实现，主要谈技术栈和一些感受。由于技术能力和视野的欠缺，不足之处，欢迎指点。

1. 云服务

1.1 阿里云

服务器用了2台ECS，做高可用，ECS前用nginx做负载均衡，当然，也可以使用阿里云提供的负载均衡服务，不过那是要花银子的，创业初期，能省就省了，不过ngingx服务也是蛮稳定的。

由于我们的产品面向海外用户，所以使用的是阿里云在洛杉矶的服务器，海外访问的速度应该还可以，国内稍差点，导致阿里云的监控经常超时报警。2台ECS的配置均为：2核/8G/4Mbps。

数据库用了1台RDS MySQL，可靠性和可用性由阿里云保障，自己只要针对性地做一些参数调整和优化即可，也没什么运维成本。RDS的配置为：1200M内存/50G空间/300最大连接数/600最大IOPS。

测试环境用了1台单独的ECS，然后在上面安装了MySQL。

总体来讲，阿里云提供的技术服务还是不错的，至于售后服务，至今没打过交道，无法评价。

1.2 环信

社交产品肯定少不了消息模块，我们用的是环信。其实我是被选择了环信，因为我接手的时候，客户端已经基于环信开发了。其实对消息服务提供商，我个人印象最好的是 LeanCloud ，这里就多说两句（有点广告的嫌疑了，哈哈），对这个创业公司最初的印象来自于他们的创始团队，创始人来自Google，很有极客范，后来了解了一下他们的产品，感觉他们的API和Demo比环信的专业和规范太多了，大家可以自己去比较，我打算以后有机会体验一下他家的一站式后端服务。

说回环信，功能上没啥问题，该有的都有。这里说几点感受：1. 接口文档不全：有一次，我需要一个接口，很常见的需求，文档上没有（确实没有），我问了一下技术咨询，他说有啊，然后发过来一个接口示例，我想，如果写在文档上，那不是节省了双方的时间么！2. 技术客服有的很专业，有的很水，经常是问一个问题，客服转来转去的；3. 环信没有部署海外节点，所以海外服务的质量一般，消息存在延时的问题。

1.3 七牛

我们的图片存在七牛上，七牛提供各种图片处理方式，是很方便的。

我们的产品面向海外，晒图又是主要功能之一，所以为了优化用户体验，选择部署了海外节点的服务商是重要考量。目前来看，基本没得选，就七牛可以。但是七牛海外加速下载的费用非常高，是国内下载流量的5倍/G，创业公司伤不起哇！

另外，10月8日的故障（官方说是电缆被挖断）影响甚广，我们也是受害者，当时app内的图片基本全部无法显示（技术客服说有CDN缓存，但是并没有什么卵用），故障持续了差不多一个半小时，后来赔付方案出炉，一共赔了我们7.6元，还是百倍赔付哦，我们都表示七牛好大方！

我觉得七牛的文档和示例都很一般，举个例子，服务端通过七牛的接口上传下载图片经常超时报错，我找了技术客服很多次，各种日志截图，各种解释，他们最后告诉我海外上传下载有单独的域名和ip，但是文档上一字不提，跟别提配置方法了。关于七牛的客服，我有个经验，就是通过QQ交流时，他们爱搭不理，但是如果提交工单，回复会很及时。

对七牛的服务，印象并不算太好，只是现在没有更好地解决方案。

2. 技术栈

2.1 SpringMVC + Spring + MyBatis

典型的Java Web结构，通过SpringMVC提供API接口与客户端交互，使用Spring处理业务逻辑，使用MyBatis处理数据逻辑。

虽然前期数据量不大，但是功能模块比较多，导致数据库的表也比较多。目前的功能主要分为两大块：社交和社区。社交模块已经有50多个表了，所以我提前进行了分库处理，将新增的社区模块放到新库，由于数据量不大，所以目前没有分表的需求。

分库可以通过MyBatis实现，在定义 MapperScannerConfigurer 的bean时，通过basePackage 设置不同的package访问不同的数据库。

另外，项目使用logback打印日志，通过git进行版本管理，使用gradle构建，使用jetty部署项目。gradle可以实现类似于Maven的profile功能，将正式环境和测试环境的配置隔离开。

2.2 quartz

定时任务，用 quartz 实现的，开启了quartz的集群功能和持久化功能。因为项目会在两台服务器上单独部署，quartz刚好可以构成集群；同时，将任务调度信息持久化到MySQL中，则不会因为服务器的重启或宕机导致定时任务的重复调度或错过调度。

关于quartz的使用，可以参考我之前的博文Quartz教程系列和在 github上的小项目。

2.3 ElasticSearch

app具有基于用户的个人信息进行多维度的个性化推荐的功能，维度包括：位置、性别、年龄、身高、星座、国家、家乡等等，其中最主要的还是地理位置。我们使用的RDS的MySQL版本是5.6， 我们知道MySQL在5.7之前，对空间数据（Spatial Data）的支持是不太友好的，所以其它维度还好，而基于地理位置的查询，使用MySQL来实现是比较麻烦的，而且效率不高。

后来，我就决定不通过MySQL实现，采用NoSQL来做， ElasticSearch 和 MongoDB 都支持空间索引，而且我之前也都有过一些了解，最后选择ElasticSearch的主要原因是，考虑到app以后可能会增加搜索功能，而这可是ElasticSearch的强项啊。

然后我就用两台ECS，搭建了一个ElasticSearch集群，创建一个index和一个type，然后将用户的基本信息从MySQL同步过来，将不同的维度作为查询条件，就实现了一个简单的推荐系统。

ElasticSearch集群运行非常稳定，目前偶尔会接到内存达到阀值的报警，主要是由于搜索时需要排除之前已经推荐过的用户，导致内存有时会飙到80%，等腾出时间了想办法优化一下。

2.4 Scrapy

在推广前期，有些模块是没有数据的，所以需要从网络上爬取一些相关数据。爬虫使用的是python的 Scrapy框架 ，使用起来比较简单，目前可以实现不登录爬取、登录爬取，但是具有复杂验证码验证的登录爬取要麻烦，还没有时间去研究。

关于Scrapy爬虫入门，可以参考我之前的博文：1. 搭建Scrapy爬虫的开发环境 ；2.Scrapy爬虫入门实例。

2.5 Django

还有一个后台管理系统，使用python的 Django框架 写的，是让一个朋友在业余时间帮忙开发的，我基本没有参与。

Django适合快速开发，我觉得对于后台的系统尤其合适。

转自 http://www.tuicool.com/articles/uErM3yi