Have的服务器端的架构调整

最初的服务器配置可以见之前写的记录，现在主要是发生了一些新的变化，因此服务器的架构调整了一波。 原因如下： 第一，服务器已经不仅仅提供api service，也开始提供后台工具，以及马上要提供的分享回来的引导页。

第二，系统已经开始引入了queue。

第三，使用的云服务商的主机真的会莫名的宕机。

基于第一点，之前文章有说过，并不想引入Nginx，但由于后来上了后台工具，并不想把域名混杂在一起，因此最后还是在前面架了Nginx。然后后面跟两个服务，一个是api相关，一个后台工具相关。不过由于背后的数据是一套，因此这样的服务拆分现在感觉不算成功，反而很多时候稍稍有些把自己绕进去。

第二点，之前大部分的需求并不会非常耗时，因此异步的需求基本上就用groutine解决了。但上了feed流之后，感觉是个契机把queue引入。因此琢磨了下RabbitMq，比较顺利的接入了现在的服务。

基于第三点，得好好说叨说叨。之前觉得云主机不奢求性能好吧，但至少应该要保持稳定。但事实是，云主机一般情况下是能稳定，但一旦遇到比如物理主机重启这样的事情，真的一点办法都没有。Have上线到现在，遇到过三次宕机。

第一次是我晚上在健身房的时候，突然公司同事就说线上挂了。我看了下我的报警，一点信息都没有，并且定时的ping也没有。当时觉得很奇怪，就赶忙回去看了。发现机器被重启了。于是把服务一点点开回来。第二次还要经典，跟太太准备休假，晚上的飞机，准备18:30分出门，18:22分的时候报警像雪片一样进来。马上打开电脑，看看什么情况。发现数据库的主机宕机了。并且当时可能由于紧张和时间的关系，一直也重新起不来，最后不得已直接通过备份的snapshot恢复，另起了一台机器工作。第三次，在好好备份机器的时候，突然机器又重启了。。。

之前的记录写过，当时的机器配置其实主要是为了省钱。但现在考虑到云主机的各种不可抗拒因素，就准备着手改一下架构。当然，当机器多了以后，就会面临部署，监控各种问题。

现在的基本配置是这样的:

最前面有一个ELB，ELB后面挂着两台服务器，两台服务器上分别部署了api service以及rabbit mq。 其中rabbit_mq组成一个cluster。两台服务器后面，放一台redis，以及三台组成cluster的mongo。基本上现在这样，ec2不稳定受到的影响不会特别大，因为mongo可以挂两台，api service可以挂一台。唯一还是单点的是redis以及ELB。ELB现在不受我控制，redis还没有backup的原因是还想再观望一段时间的redis cluster。

这样的配置目前负载很小。唯一稍微有些紧张的地方是当我们的官方号发信息时，feed的插入，对现在最低配的机器有些挑战。

这部分的调整目前还没有正式上线，有点期待上线后挂一次服务。。