新版 SegmentFault 重构之系统架构

若是有关心SF发展同窗确定经过很多渠道了解到咱们正在对它进行全站的重构，如今重构已经进入了尾声，并且内部测试也已经通过了一个阶段，因此不出意外的话，这个新版本过不了几天就会出如今你们面前了。

那么此次重构在系统上有什么进步呢？

系统架构的大大增强

在过去的一年，SF由于系统的制约发生了很多起宕机事故，有的时候甚至长达数小时之久，大大影响了用户的体验，所以在此次重构之初，咱们就下决心从系统层面开始解决这一问题。

截止到2014年9月15日，你们看到的虽然仍是老版本的界面，可是实际上背后已经迁移到新的系统架构上了，而且在这段时间内没有发生任何访问故障或者宕机事故，新的系统架构威力初显。

那么SF之前的系统架构是什么样子呢？个人回答是没有什么架构，由于全部的服务都放在一台服务器上，这个答案可能让不少用户大跌眼镜。

是的，受制于创办之初的资金限制，咱们的网站只有一台服务器。在后期访问量逐渐增大的状况下，这台服务器情况不断，若是有一天它忽然挂掉，那恢复它可就费事了。

云主机助力

对于SF这样的初创企业，本身创建数据中心显然是性价比极低的选择，可是系统架构的限制又逼迫咱们不得不作出改变。幸亏如今已经进入了云时代，大量的基础设施问题能够交给更专业的服务商解决。通过一系列权衡，咱们最终选择了青云做为咱们的云主机提供商。

• 4 * web服务器(其中一台备用)
• 1 * db服务器(得力于ssd和缓存的使用，目前一台db是能够知足需求的)
• 1 * 搜索服务器
• 1 * 缓存服务器
• 1 * 后台服务服务器

通常工做的就是这8台服务器

更加颗粒化的系统划分

这一点在web服务器系统的设计上尤其突出，它是全部服务器中压力最大的，所以机器数量也是最多。可是每台服务器的配置倒是最小的 单核1G 的实例。

这种颗粒化的划分，有如下几个好处

1. 节约成本，若是咱们一次性配置一台多核大内存的服务器，成本是很高的，并且大部分状况下性能是有浪费的。
2. 增长可靠性，一台机器挂掉的可能性远大于多台机器同时挂掉
3. 方便水平扩展，你可能已经注意到我设计了一台备用服务器，它平时就是挂在负载均衡节点上的，只是不须要开机（若是不开机是不会计费的），当遇到忽然增长的访问量时，咱们能够实时启动这台服务器，从而瞬间减轻其它节点的压力。而访问量下降后，咱们又能够关掉它，下降使用成本。

好比上面这张图就是一次典型的流量冲击处理，在11点左右网站的访问量陡增，前端web的负载所有到顶，根据它的增加曲线，咱们判断这是一次恶意抓取。须要咱们在程序上作防御的同时在这期间不影响用户访问，所以咱们将第四台备用服务器的配置临时调整到 4核2G，并在12点左右上线，系统负载立刻恢复到了正常水平

改变代码上线模式

一般的上线流程就是直接把可发布的代码经过rsync之类的同步到线上机器。

在新版的SF中咱们根据PHP的特色改变了这一模式，咱们将代码打包成phar发布到服务器，每上线一次就从新打一个包，并将其文件名命名为版本号，好比14.9.5.195755.1718937340.phar。打包发布有以下好处

1. 方便管理，只有一个文件，并且传输比之前的同步模式更加快速，而且能够避免当某些文件没有同步完用户就来访问的错误
2. 能够回滚，回滚很是方便，在配置文件里将须要加载的包版本号改为你须要回滚的版本便可，能够快速完成灾难恢复

更加好地依赖云服务

除了咱们的云主机，咱们还使用了以下云服务

1. Amazon SES，群发邮件价格便宜量又足
2. Mailgun，目前咱们的主力邮件发送服务，你们的通知提醒服务都是经过它
3. SendCloud，备份邮件发送服务，主要用来发一些mailgun没法收到的邮件，好比QQ Mail等等
4. 又拍云，全部的静态文件，包括用户头像和上传图片的存储
5. NewRelic，程序性能监测

Todo

虽然咱们已经达成了一个milestone，可是后面要作的事情依然不少，而且咱们的后端服务能力会逐渐增强。咱们后续的工做会围绕数据流的处理展开，咱们也会使用更多的技术来完善咱们的服务，Node.js，Go-lang，Scala，都是咱们的选项。也欢迎在这方面有经验的工程师加入咱们