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

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或者搜索西加加语言就行