聊一聊小团队如何做同城双活
背景
随着业务的逐步发展，系统的部署结构也是会跟着演进的。
正常来说，会经历下面几个阶段。
阶段一
业务初期，没有什么数据量和访问量，这个时候往往是单机部署，快速应对业务的迭代。
虽然是单机，相信大部分还是会把数据库和应用独立开的。
阶段二
业务快速发展，访问量和数据量开始大了起来，一台机器的瓶颈慢慢的出来的，这个时候就会考虑引入反向代理来实现负载均衡。
也就是我们最常说的堆机器。
阶段三
业务高速发展，访问量和数据量成倍上升，单个反向代理压力也逐步上来了，需要多个反向代理来分担压力，这个时候会引入LVS或F5来让多个反向代理负载均衡。
阶段四
在阶段三种，单个机房里面的机器已经多了很多了，万一遇到机房出问题了，业务基本就处于不可服务的状态了。
所以这个时候会引入DNS轮询将请求分发给多个机房，避免单个机房故障导致业务崩溃。
这里比较常见的就是同城双活和异地双活两种。到了这一阶段，其实成本就慢慢在上来了。
这个阶段再往后就是异地多活了。
上面这几个阶段，应该大部分人都有过了解，不过却不一定有过实践。
真正实践起来还是会有一些坑要踩的。
老黄公司是做互联网医疗的，虽然量级不大，但是领导对这一块还是挺看重的，所以我们还是有做一个低配版的同城双活。
做这个的初衷也是避免单点故障问题，不想把鸡蛋都放在同一个篮子里面。
下面老黄就分享一下相关的实践经验吧。
对用了云服务的情况下，其实很多内容都简化了。
首先是在同一个城市下面，分了很多个可用区，其实这就很好的满足了同城双活的基本条件了。
其次，负载均衡产品都是集群部署，避免单节点故障问题。
下面那个项目来说一下吧。
项目实战
现状
这个项目是部署在阿里云上面的，所以这里用的都是阿里云的云产品。
挂在一个 slb.s2.medium 规格的 SLB 上面，这个规格最大可以支持连接数: 100000，新建连接数 (CPS): 10000，每秒查询数 (QPS): 10000。
日均访问量在三千万左右，峰值QPS会去到 1.2K 往上，1.2K 的QPS会很容易达到这个规格 SLB 的瓶颈，因为这里会很容易触及一个雷区。
虽然规格的最大可支持数看上去很高，但是这些数字都要除以 7 才是真正的值。7+1的模式部署，其中1是备机。
如果这个实例的 QPS 一直持续在 最大可以支持连接数 / 7，就要考虑升级规格了。之前不清楚这个，从日志服务发现很多503请求去提工单问了才知道这个雷。具体详见文末工单内容。
这个 SLB 后面有三台机器提供负载，大概结构如下：
这算是一个比较典型的结构方案。
再来看看引入双活之后的：
变化不会特别大，就是在 DNS 的后面加多了一个 SLB，分担了部分请求压力。
那么接下来就看看这个双活具体怎么弄吧。
实战
