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

背景

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

正常来说,会经历下面几个阶段。

阶段一

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

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

阶段二

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

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

阶段三

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

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

实战

详见 https://mp.weixin.qq.com/s/YYozo7V6MkJGkiVYUaWJWQ

如果您认为这篇文章还不错或者有所收获,可以点击右下角的【推荐】按钮,因为你的支持是我继续写作,分享的最大动力!
声明: 本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。如果您发现博客中出现了错误,或者有更好的建议、想法,请及时与我联系!!如果想找我私下交流,可以私信或者加我微信。
posted @ 2021-03-02 09:04  Catcher8  阅读(284)  评论(0编辑  收藏  举报