have服务器上线后遇到性能问题的扩展准备

随着正式上线have的日子越来越近，有必要重新梳理下服务器的准备。现在所有的测试环境是跑在一台aws的ec2上。真正生产环境显然不能这么干；但初期由于资金的问题，我也并不愿意把所有的东西都做到一开始就分得很清晰，而是准备到必要的时候，才切分出来。毕竟，好的架构是演化出来，我的经验不能保证一开始的设计就是对的。虽然有些事情一开始不需要做，但做好准备还是必要的。

现在have的技术栈和技术服务里面主要用到以下几个：golang,python,aws,七牛,微信企业号,stringily,bitbucket,trello ,slack,mongo,redis;（这些东西的选择过程之后再说）

have在最初期的时候，最主要的产品就是一个闲置类的app，因此只需要对外提供api的服务器。

刚上线的时候，只需要准备两台ec2，一台跑api service和redis相关，一台跑mongo。刚上线的时候，量肯定不会大，而且图片的服务又是host在七牛那里的，所以压力肯定不会大，甚至于，我把这两台并成一台也未尝不可，但考虑到之后DB服务器的独立性几乎是一定的，未来不折腾，就直接分开了。

api service这边，目前也不准备在前面架一个nginx，原因主要是：第一，我没什么静态文件需要host；第二，golang本身的性能很好，程序里面做分发未尝不可；第三，golang本身利用多核的能力也很棒，不需要前面架nginx分发到多个golang进程；第四，日志相关golang自己的解决方案也很简单；因此我觉得可能并用不到nginx；

下面是一系列的情况以及可以怎么处理：

1.api service压力大？

• 升级ec2性能
• 把redis切出去
• 在redis切出去完成的前提下，前面放ELB，redis独立，后面跟多个ec2服务器跑api service；有点是，可以动态起ec2扩展了；缺点是，ELB双向流量收费。。

2.redis压力大？

• 和api跑在一台服务器上的时候，就只管升级该ec2的能力；
• 当拆分出去的时候，用aws自己的redis实例，并且按读写分实例
• 读的能力继续不够的时候，分多个读实例

3.mongo压力大？

• 升级ec2性能
• 读写分离
• 将最费的查询，用aws的dynamoDB来优化查询，代价是某些数据需要同步到那里

4.上交易，需要更稳定的数据库？

• 不折腾，用aws的postgresql

5.需要wap站点？

• 通过域名配置去独立的ec2
• 通过端口，即api service不走80

6.七牛不靠谱？

• 又拍
• 腾讯云的图片服务
• aws 的 s3