聊一聊小团队如何作同城双活

基于阿里云作低配版的同城双活方案

背景

随着业务的逐步发展，系统的部署结构也是会跟着演进的。

正常来讲，会经历下面几个阶段。

阶段一

业务初期，没有什么数据量和访问量，这个时候每每是单机部署，快速应对业务的迭代。

虽然是单机，相信大部分仍是会把数据库和应用独立开的。

阶段二

业务快速发展，访问量和数据量开始大了起来，一台机器的瓶颈慢慢的出来的，这个时候就会考虑引入反向代理来实现负载均衡。

也就是咱们最常说的堆机器。

阶段三

业务高速发展，访问量和数据量成倍上升，单个反向代理压力也逐步上来了，须要多个反向代理来分担压力，这个时候会引入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，分担了部分请求压力。

那么接下来就看看这个双活具体怎么弄吧。