神刀安全网

坑系列 — 高可用架构的银弹

坑系列 --- 高可用架构的银弹 呵呵,题图是一队困在坑中的鸭子:)作为一个搬砖的,我经常被困着。今天高考,想起15年前的今天(哦,那时候是七月高考),恩,考完了,还不错,然而15年后还是搬砖:)

0. 承上启下

之前那篇文章写出来以后我就觉得会有很多不同的意见,哈哈,那只代表我个人的意见啊,欢迎讨论。

先说说之前那一篇,我举例子举的 OA系统 ,并不是说OA一定要这么设计,只是一种夸张的手法,为了说明后面的 完全脱离了业务场景来进行技术架构的设计就是过度设计 ,并不是说OA系统太简单所以不能这么设计,另外,写 PHP 效率低也只是打个比方,并非贬低全世界最好的语言,很多人拿这两个来喷实在没必要。

好了,说今天这一篇的正题了,上一篇写了整体架构设计中的过度设计,这篇来说说高可用吧。

1. 迷信架构可以解决高可用,但并没有银弹

高可用 ,我知道一旦带上这个词,不管写什么都会有人有不同意见,我说说我认为的 高可用 下的坑吧。

我想很多人理解的 高可用 就是单台机器挂掉了整个服务不会挂掉,所以写代码的时候使用集群的思想去写代码,比如做成无状态的服务,保证在集群使用的时候无状态,单机故障不影响服务,从而达到 高可用 的效果。

由这种思想搭建起来的系统很可能长成下面这个样子,我想很多人都看到过这种架构模式吧。

坑系列 --- 高可用架构的银弹

首先,这种架构模式本身并没什么问题,而且也确实很好,有服务发现,有集群,单台机器挂掉了还有其他机器可使用,在搜索系统,推荐系统,广告系统,网站后台系统中都在大量使用。

很多人接收到的信息是有了上图的那种架构,那么这个系统就变成了一个高可用的系统了,觉得这种架构模式就是 高可用 的一颗 银弹 了。

但实际上,上图的系统解决的主要是下面的两个问题。

  • 数据同步,主要是公共配置这种少量数据的在各个机器间的同步。

  • 服务发现,新增或者减少机器以后,让其他机器能感知得到有新节点加入或者有老节点下线了。

除了上面两个问题以外,最后才是解决所谓的 高可用 的问题,这里用了 所谓 两个字,因为我觉得 高可用 这种东西不是一个架构的模式能解决的,一个高可用的系统是代码级别解决的,不是靠几个开源模块能解决的。

有些人总认为 高可用 系统有 银弹 ,在各种论坛,会议上看到各种架构,而且基本上都用到了一些成熟的开源软件,所以觉得有了这些以后就可以是一个高可用的系统了,我有zookeeper,那么服务单机挂了,服务照常跑,但实际上然并卵,zookeeper解决的是外部不可控因素导致的机器挂了,比如机器硬盘坏了,网络断了,这种因素导致的服务挂了,zookeeper能解决,你代码出问题导致机器挂了,zookeeper下挂1000台机器也解决不了啊,一般情况下还是一挂全挂。

比如一个分布式的搜索系统,索引分片了,所以有个集群,有50台机器,每个分片大概10台机器,并且机器可以动态增加减少,集群用zookeeper管理,这算 高可用 系统吗?这可是一个标准的搜索系统的 高可用 架构,也只能说,在代码优秀的前提下,这个系统 高可用 了,网络问题和机器硬件问题已经比较难搞挂整个集群了。但一旦代码有个小bug,或者索引数据生成的时候出现了点问题,一般情况下,集群就全挂了,谈何高可用。

高可用 没有 银弹 ,你在各处看到的,听到的,学习到的各种 高可用 架构,他们只会告诉你这个系统架构多么牛逼,用几个框框框住某几个模块,然后告诉你,这个框框里的服务各种突发情况都能自适应,流量洪峰来了线性加机器就能解决,对你来说却是然并卵,他们没有告诉你他们的代码有多牛逼,并且只有在这个前提下才 高可用 的,想纯粹靠几个框框来架构出一个 高可用 的系统,那是PPT架构师。

真正的 高可用 不用纠结架构设计,只需要代码的健壮,健壮的代码加上主备系统设计,不需要其他的,基本上就是一个高可用的系统了,银行的核心数据处理中心加上异地灾备就是这样子的,你敢说他不是高可用的?

所以,写好代码吧,才能高可用,学习架构,更多的只是对提高系统全局性认识的一种补充, 高可用的架构不存在,存在的只有高可用的代码

2. 一个栗子

我前段时间看到过这样一个系统,这是一个O2O的创业公司的后台的一个模块,主要功能是给刚打开APP的用户提供一个个性化的推荐页面,外部接入了一些其他系统产生的一些数据。

数据从其他系统推过来以后,先是接入到一个 kafka 的消息队列,数据进来了以后有一个服务的集群获取这个数据,不同的服务通过 kafka 不同的 topic 获取,然后二次加工这些数据,生成一个结构化的个性化数据,把生成的数据存到 redis 集群中,每个APP用户对应 redis 中一个key,前面的APP调用API以后,直接从 redis 集群中获取数据返回,这些个集群都用zookeeper管理的。

这么架构出来,消息队列是为了解决第三方数据推送太猛,做缓存用的,而redis集群其实是为了解决前端APP的高并发访问的。

我先问了一下,消息队列这个集群在其他系统模块也在用,这没问题,大家都要用嘛,部署一个集群也很应该哈。

但是这个 redis 集群只有这里在用,这里我觉得有点问题了,有必要做个带zookeeper的集群吗?只是为了打开APP的个性化页面,用个redis集群?不是大家共用资源的话,我觉得完全没必要redis集群,一主一备足矣,还容易维护。如果你觉得单机内存不够大,可以用redis2.0,开启VM功能,突破物理内存的限制,redis还能自己在内存保持热点数据。

你说这样是为了解决高并发下的高可用,如果redis挂了,还能自动切换,这么说吧,我觉得一个系统中,排除硬件故障的问题,一般情况下,等你的服务全挂光了,redis也还坚挺着。并且redis的并发能力简直只能用恐怖来形容,单机2,3万的QPS(数据大小2,3kb左右)完全没什么问题,一个创业公司的日活用户量一般情况下也没必要用集群去抗并发吧?

后来,我建议他们把redis集群干掉,换成单机主备的,而且我发现所谓的个性化推荐其实大部分人看到的页面是一样的,这也很好理解,初期没数据的情况下,个性化推荐出来的东西也不够丰富,redis集群的内存使用率其实很低,于是我进一步建议他们用 nginx+lua 的本地字典来缓存最热的数据,后面挂个redis,变成一个三级缓存(redis本地磁盘,redis内存,nginx本地字典)。如果真的业务量上来了,换成redis集群也很容易,现在就没必要浪费机器资源了,毕竟创业公司嘛。

恩,最后他们冲我投来鄙夷的目光,这架构,人家看不上,万一突然一天用户量暴增怎么办,而且最关键的是人家不差钱,好吧,呵呵。

3. 高可用的银弹在哪?

瞎扯了这么多,有没有高可用的银弹呢?恩,优秀的代码就是一切高可用架构的基石和银弹,优秀的代码加上合理的架构就是高可用的架构,一个高可用的架构不是靠开源软件搭积木来得到的,成熟的开源软件解决的是把一部分本应该你写的代码变得更优秀。

好吧,欢迎大家继续讨论:)

如果你觉得不错,欢迎转发给更多人看到,也欢迎关注我的公众号,主要聊聊搜索,推荐,广告技术,还有瞎扯。。文章会在这里首先发出来:)扫描或者搜索微信号 XJJ267 或者搜索 西加加语言 就行

坑系列 --- 高可用架构的银弹

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 坑系列 — 高可用架构的银弹

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址