引言:这是回声社区(http://huisheng.fm) 创建和运营经验分享系列文章第二篇,由回声联合创始人 RainX 撰写。

————

作为技术人员,已经有蛮长一段时间没有把自己的开发经验做一次总结了,可能是因为太忙和太懒吧。所以这次决定把自己这两三年来作为创业团队的成员,在技术方面的心得和技巧做一个总结,也包括简单提及一下和之前在大网站工作的时候一些不同点。

先介绍一下自己,网名 RainX,2004 年毕业后进入雅虎中国工作,到 2010 年底,一直在阿里集团的技术团队。2010 年底的时候觉得时机比较合适了,就离职出来创业,先后做为合伙人创立了码云网(类似国外的 eventbrite 的自助活动管理平台)以及目前正在进行的回声网(情感故事分享社区)。

首先先说一下作为创业团队的技术团队成员和在大公司技术人员的不同之处。

  • 首先,大公司开发人力资源充足,不管你是做架构的设计,还是底层开发人员,都不需要对所有的技术细节了解,而是精专在某个领域,越深入越好。通过团队的协作来解决单个人的能力短板,比如 DBA 可能对开发不是特别了解,后端开发无需了解前端的太多技术等等。 但是在初创团队,就需要相对全面的技能,比如我们之前在开发码云时,我一个人就需要同时写前端代码和后端代码,部署数据库,做界面的设计,写安卓和 iOS 的客户端,以及桌面客户端,甚至还要帮我们拍摄的宣传视频做剪辑以及后期的音效工作。
  • 其次,除了丰富的人力资源外,大公司内部一般也有很多成型的系统,比如在雅虎的时候,有 yapache(web 服务器), yinst(包管理),mdbm(kv 数据库), shmproxy (网络通信中间件), yrepl(消息中间件)等,创业团队无法应用到这些系统,只能找开源的对应产品替代。
  • 最后,大公司有很多成熟的服务资源,从硬件方面的服务器,CDN,带宽等,到软件服务方面如短信平台,邮件平台等,都可以直接使用。但是初创团队就要购买或者寻找一些对应的替代方案,目前这些很多是以云服务的形态出现的。基于这点,我有一个比较深刻的体会,这次回声在有一次推广的时候突然发现系统无法访问了,登录到服务器上也很慢,先后排查了 web 服务,数据库,邮件服务等都没有发现问题,最后发现原来是由于流量突然增大,我们购买的 VPS 的带宽用尽了,然后紧急的购买了新带宽才解决这问题,但是同样的问题在之前雅虎和淘宝工作的时候就根本没有遇到过。

如上面所述,开源软件和云服务的使用是初创团队不可或缺的元素,也同时可以大大的节约初创团队的时间成本。拿回声为例,我们大概只花了 2 个月的时间就完成了整个系统的搭建并上线,下面我就分几个方面分别介绍一下系统的搭建过程。

整体架构

上图简单描绘了我们系统的架构和所使用的软件(括号内部)和服务(圆形标识)的情况,可以看到,网站的结构是非常简单的,我们将网站部署在 2 台 VPS 云服务器上,一台提供 web 服务,另外一台作为 mysql slave 供我们进行数据分析使用。注意由于我们目前流量还没有非常大,所以这台暂时还不提供对外的服务,只做数据分析用。

目前两台 VPS 节点都使用的阿里云的服务,关于 VPS 的选择方面,其实国内的选择空间不是特别大,比较难找到 Amazon EC2 类似级别的服务。如果创业的目标用户是针对国外用户的话,还是推荐 Amazon EC2 或者 Linode 等比较有规模的服务商。

1、web 服务 :  web 服务我们采用的是 LNMP 的架构。LNMP 的好处是开发简单,快速,资料丰富,并且被验证足以支撑到一定规模的访问量 (facebook, yahoo 等),php 的 mvc 我们采用了 codeigniter 作为基础框架,同样是因为简单。作为创业团队,尽量选择自己熟悉并且稳定的系统和架构构建你的网站,我不太建议刻意尝试太多新的东西,即使你的技术足以驾驭它,还是不可避免的踩很多坑,这会消耗创业者宝贵的时间和精力。

在 web 前端方面,我们采用了基于 HTML5 的响应式设计。具体可参见我们之前写的一篇文章《利用响应式技术构建大规模社区网站》。

2、缓存服务&键值存储:不管是之前还是现在,我们都有很多的场景会使用到基于 key-value 的存储还有缓存的服务,redis 在性能和功能上有一个比较好的均衡,使用起来也不会太复杂,所以我们在系统里面大量的应用到 redis。如记录用户目前是否是第一次访问某个页面,记录用户是否升级到某个版本,以及首页的推荐文章的缓存,系统的部分配置信息等。

3、异步队列服务(或者消息服务):我们使用 Gearman 作为队列服务的支持,严格说来 Gearman 并不是一个标准的消息系统,但是 Gearman 简单高效的特点吸引了我们,并且它分布式架构足以支持更高级别的系统负载,并且他对 php 的支持很好,我们使用的是它的异步任务部分,关于 Gearman 如何作为队列服务支持邮件的发送,可以参考官方网站的 use cases 里面的介绍, 除了邮件服务之外,我们的手机通知的推送服务也是基于 Gearman 进行了队列化的。

4、邮件服务:对于网站来说,不管从邮件营销的角度,还是作为网站服务的基础部分,邮件都是很重要的一部分,这部分比较复杂,后面我们会单独用一个小节来介绍一下我们目前采用的邮件服务方案。

5、搜索服务:目前使用的是 Coreseek,Coreseek 是一款中文全文检索/搜索软件, 是基于 Sphinx 结合中文分词系统进行开发,优点是和 php,mysql 结合较好,有中文的支持,当然基于 xapian 的 xunsearch 也是一个不错的替代方案。

6、推荐系统:回声网需要给用户推荐他可能喜欢的群组,以及潜在还需要根据群组推荐相关的群组,在推荐系统的选型上,我们选择了基于协同过滤的 Mahout Taste CF 来计算用户可能该兴趣的群组,然后使用 Ruby 语言基于 Recommendify 开发了基于 item 到 item 的推荐。我们会在每天晚上进行运算,把结果放在数据库中提供前端调用。

当然虽然基于协同过滤的推荐系统已经非常完善了,但是由于它是基于统计模型的,在初始用户的行为数据比较少的情况下,该模型相对难以解决新用户的推荐问题,比如我们会提供给新注册用户一些群组推荐,这里我们使用了一些基于用户特征的推荐,比如给群组打上标记,比如 “我想把学校炸啦” 这个群组我们会标记为优先推荐给 90 后的用户, “我是处男” 这样的群组我们只会推荐给年轻的男性用户。

7、数据分析方面: 首先 GA 是网站服务不可缺少的工具,唯一的缺点是 GA 后台的访问不太稳定,最好配合 VPN 进行访问,关于 GA 使用方面的介绍,我的合伙人 everfly 会有写一篇专门的文章介绍。另外,基于 app 方面,我们使用 Flurry 提供的服务进行数据分析。

除了第三方提供的数据分析服务之外,有一些比较细致的分析还需要基于网站的自有数据进行,因为刚好之前有一台闲置的 VPS,所以目前就拿来作为我们的数据分析服务器了,和主数据库配置了 Master-Slave 结构,数据分析在 Slave 上及进行,不影响线上的业务。

8、域名服务:我们的域名是从 godaddy 上注册的 (.fm 的域名有点小贵),但是不建议使用 godaddy 的服务器作为 nameserver,因为偶尔会被墙,这里我们直接把 nameserver 迁到了 dnspod 上,还是非常稳定的。

9、CDN:如果你的没有涉及到大量的图片或者声音数据,其实我觉得可以省掉购买 CDN 服务的步骤,不过我们的网站刚好会有一些群组封面图片和用户自己的封面图片的展示需求,并且在一次推广中触及到了 VPS 流量的上限,所以我们把图片访问部分迁移到的 CDN 服务上,这方面选择很多,我们使用了 orca 的服务,orca 的服务有一个亮点是支持 dropbox 的同步,便于管理。当然 orca 毕竟上线的时间不长,如果需要更专业的云存储服务,推荐又拍云和七牛云存储。

由于篇幅有限,这里很多内容无法展开来详细的介绍,下面我针对一些我感觉到相对比较重要的两个部分:发布系统和邮件系统做一个具体的说明。

发布系统 

由于网站的结构是基于 lnmp 的,所以我们主要的代码都是 php 代码,之前在大网站的时候,一般会有比较严格的流程和比较严格的打包发布机制,比如 Yahoo 的 yinst package, 但是对于初创团队来说有些重了,这里我们直接使用 svn 进行代码的管理和发布。

虽然系统环境不复杂,但是我们还是分为开发环境,测试环境 (beta),和生产环境(线上),开发环境我们在自己的机器上搭建,我的是 Ubuntu 的系统,everfly 是 MacOS 的系统,测试环境在和 svn 服务同一台服务器上,我们使用 svnseve 的 post-commit 功能实现了一旦我们提交了代码,服务器会自动将代码部署到 beta 环境的 web 服务器上, 在生产环境则是直接使用 svn export 进行部署,整个流程还是非常简单的。

注意,有的时候我们在生产环境和开发环境的时候需要执行不同的逻辑,比如针对 html 内部引用的 javascript 代码,为了节省流量(当然还有一个原因是代码写的太丑了,不想让大家看到笑话),在生产环境上,我们使用了 jsmin 进行压缩,但是在本机进行开发的时候,为了调试前端代码方便,不能对 javascript 代码进行压缩,所以我们通过设置环境变量,然后在代码中检测环境变量的方式解决了这个问题,由于环境变量是设置在 web server 或者 php-fpm 的配置中的,所以线上和开发环境可以保持同一份代码,在代码中判断当前的系统执行不同的逻辑即可。

邮件系统

作为一个社区网站,邮件系统是非常重要的部分,我们的邮件分为触发式(注册确认)邮件和群发邮件(每周故事摘要)两部分。

我认为邮件系统最主要的亮点是可配置性和队列化,由于我们网站的主要用户是 QQ 用户,所以 QQ 邮箱占我们用户的绝大部分的比例,所以我们把 QQ 邮件单独出来,分为四种情况,QQ 群发,QQ 触发,其它群发,其它触发,然后针对我们可以使用的邮件发送平台,本机 Postfix,Amazon SES,sendgrid,QQ 企业邮箱可以随意组合,这个配置可以在后台完成,即时生效。

然后再谈一下我们这段时间对不同的平台发送邮件效果的体会,首先是触发式邮件,这个比较简单,不管是任何的平台,触发式邮件的到达率都很高,不过 sendgrid 和 Amazon SES 的免费服务有限额的限制,所以我们针对触发式邮件目前使用自建服务器来发送,很多人之前在自建服务器的时候都遇到很多问题,其实自建服务器邮件发送没什么特别的秘诀,但是至少基本的 dkim, spf 以及域名解析等还是能做的都要做的, 这些配置在使用第三方服务的时候也都要做,为了避免混淆,我们注册了几个不同的域名分别通过不同的平台发送邮件,避免了域名解析冲突的问题。

针对群发邮件,我建议还是采用第三方的服务比较靠谱,倒不一定是第三方的服务到达率有多高,只是由于群发邮件很容易被标记为 spam,如果和触发式邮件配在一起反而会影响到触发邮件的到达率。

另外,我们针对群发邮件的队列进行了发送频率的控制,比如 20 秒钟发送一封,这样也一定程度上避免一下子达到某个邮件服务商的时间限额而进入垃圾箱。我们目前使用的是 Amazon 的 SES 作为群发的支持,优点是费率相对较低,缺点是到达率不是特别理想,另外后台数据分析界面相对简陋了点。对于对到达率需求较高的用户,推荐使用 mailgun,但是费用相对较高。

当然如果你的邮件发送规模再小一点,也可以使用 QQ 企业邮箱进行发送,有点是针对 QQ 邮箱的到达率相对较高。不过 QQ 企业邮箱每天和每个小时都有发送的配额限制,如果你要发送的邮件过多应该是无法支撑的。

再次提醒,不管你是自建服务器,还是使用 mailgun,Amazon SES, 或者 sendgrid 以及 QQ 企业邮箱发送,在条件允许的情况下 DKIM 和 SPF 验证是一定要配置的,如果可能的话弄一下域名反向解析。

当然上面介绍的更多都是技术层面的,对于更大规模的发送,尤其是在国内,被邮件服务商加入白名单才是王道,不过这个就不属于本文的讨论范围了。

以上就是我总结的一些技术方面的心得,希望能对起步阶段的同学们有些帮助,当然除了技术方面,在项目管理方面,我们也用到了很多相关的云服务,比如 Asana, Yammer 等,如此多的服务,会涉及到很多帐号和密码的管理问题,这里我们使用 meldium 来管理所有系统服务相关的帐号密码,它的一键登录功能非常方便实用。