这是一个坑系列，会说一些在系统设计、系统架构上的坑，这些都是我想到哪说到哪，有像这篇一样比较宏观的坑，后面的文章也会有到具体技术细节的（比如某个函数，某个系统调用）坑。总之，到处都是坑，这些坑有些是我经历过的，有些是听说的，你也可以留言说说你遇到的坑。

第一部分，我们从重构这个场景来看看系统架构的设计中过度设计这个坑。首先，我们这里说的重构，和《重构：改善既有代码的设计》这本书中的重构不太一样，这是本好书，他主要说的是代码级别的重构，这种重构是需要在编码的时候时时刻刻进行的，更多的是一种编程思想的训练，而下面我们要讲的重构主要是说系统设计的重构。

关于架构师

在说之前先聊聊架构师这个职位吧，这个职位最近两年特别特别火，哪个公司没个架构师好像都不好意思跟人打招呼，各位架构师打上这个标签后头上就顶了一个光环了，本人也认识各个公司的一些架构师，我认识的架构师分成几种：

系统架构师，这种技术能力是最强的，这也是一般人眼中的架构师了，这种架构师一般属于领域架构师，对某个领域的技术有比较深入的了解。

业务架构师，我只是用了这个名字而已啊，有些地方的业务架构师其实和上面的系统架构师没什么两样，但有些业务架构师有些脱离了技术了，基本上变成了一个项目经理的角色，各种沟通，我觉得不应该算架构师了。

PPT架构师，这个顾名思义，这是"最高级"的架构师了，只要PPT做得酷炫就OK了，这是我等达不到的程度，呵呵呵呵。

最近还有一种说法就是架构师到底要不要会写代码？我的理解是没什么可说的，必须要会写啊，你一个架构师，代码都不会写还架构个毛线，就算你是PPT架构师，没时间写代码，但出问题了抡起袖子来解BUG的能力得有吧，而且很关键的一点，架构师面对的都是一群技术宅，你连个代码都不会写，你觉得下面的技术宅会看得起你么？至少你得显得很会写吧。为什么说架构师呢？因为大部分架构上的坑都是从一个不好的设计开始的，而现在的各个系统的设计都是由架构师来操刀的。

重构过程中的过度设计

1、重构过程中的过度设计

技术人员最喜欢做的一件事就是重构，因为技术宅们都看不上别人的代码，特别是需要在别人代码上加新功能的工作更是看不上，架构师们是技术宅的升级版，所以更加看不上别人的架构设计，所以重构是经常做的事情，小的是功能模块的重构，大的是整个系统的重构，总之，都是不重构不舒服斯基。重构本身并没有问题，但是需要看的是重构的时机，是不是应该重构了？我们以一个例子来详细说说重构中的过度设计吧，你也可以想想要是遇到这样的系统，你是架构师，你怎么做？欢迎留言讨论。

假如有个初创公司，是帮企业做OA系统的，最开始的时候是由三个程序员小哥开发出来的，系统架构很简单，是个AllInOne的设计，开发语言PHP，就像下图一样。

每当客户有新需求，基本的操作就是加个表—加个逻辑模块—修改一下界面—上线，而且一般OA系统是部署在客户内部的，所以每次修改都是针对单独客户进行开发。公司发展的越来越好，有了一些大公司买了他们的OA，有钱了，请了个架构师过来优化优化技术架构，架构师叫小明（每次都黑小明），小明来了一看现有设计，我去，这怎么行？三天后，给出了他的建议：

首先，数据层都在一个库里面，以后数据量大的话数据库效率太低了，首先要分库分表，把用户数据表和事件表横向和纵向的拆分一下，哈希到不同的机器上去，减轻单台机器的压力。

其次，AllInOne的设计太臃肿了，要把各个模块微服务化，把权限模块，附件管理模块拆分出去成为一个微服务，提供API给其他模块使用，方便维护，后续添加新功能做一个微服务就行了，和其他模块的耦合性急剧降低。

在数据层和业务层之间加一个代理层，用个开源的中间件，以后数据端再有分库分表操作，对上层屏蔽细节，业务人员不用关心底层数据库细节，专心写业务逻辑就行了。

PHP性能不太行，并且界面做出来不好看，前端分离还不彻底，改成Nodejs+Angularjs来进行前后端分离，前端人员专注页面，做出更绚丽的页面来，后端人员专注业务逻辑，使用RESTAPI进行数据交互。

docker部署，每个服务启一个docker，对运维人员友好，而且有很多工具可以看各个docker的健康状况。

于是，整个系统变成下面这个样子了。

卧槽，好高大上，乍一看，这就是一个目前比较流行的架构图了，有数据层，有中间件层，有业务层，有前端展示层，数据层支持分库分表，可以无限扩展，业务层微服务化，也可以无限扩展，docker部署，一个image搞定部署，简直了！

除了消息队列没有用上以外，其他的流行东西用了个遍啊。那么，开始干吧，把人员分成两拨，一拨继续维护现有系统，接客户新需求，一拨开始重构，一个月时间，把数据和功能模块梳理了一遍，然后开始定各个服务中的接口，又用了小一个月，然后全部人员投入进去开始编码，又忙活了三个月，终于重构完成了，再花一个月时间追上这4个月新来的需求，牛逼的架构上线了！如果小明够厉害并且开发人员也给力的话，最好的情况就是上线后一切正常，你不是重构么？客户完全感觉不到有变化，继续使用得很high。但这种概率几乎为零，最有可能的情况是什么呢？

客户说，卧槽，少了个功能了，卧槽，数不对了，这都是小事，新系统嘛，总归有一些问题，解决这些bug就好了。

某天发现登录不上了，如果在之前，跟踪一下代码就知道哪里有问题了，立刻解决了，现在已经微服务了，你说是网络问题还是权限服务问题还是逻辑问题呢？要跟踪可没那么容易。

某天发现数据写入和读取都有问题，最后查问题发现是技术教程开源的中间件偶尔抽风了，要修改的话，得看中间件的源码了，跪了吧……

最关键的是，你会发现，上了这个新的架构以后，是耦合性降低了，但开发一个新功能的工作量比以前多了，效率反而降低了。

这就是一个典型的过度设计，过度设计特点：

完全脱离了业务场景来进行技术架构的设计就是过度设计。

这个例子中的业务场景是一个OA系统，OA系统的主要数据是企业的人和人的数据，一个企业能有多少人？一个初创公司，能接入10万人的大公司做OA已经非常不错了吧？即便是10万人的大公司，人的数据也就10万条，我们在成100，算单个表1000万条数据吧，单台MySql完全可以hold得住，所以第一条分库分表的设计在这个场景下就完全没有必要，企业主最关心的是什么？

是数据的安全可靠，所以你在这里把MySql换成Orecle，企业主觉得安全也会买单，并且你收入还能更多，而且换成Orecle的话，单个表上亿问题也不大，何必分库分表？好，就算你数据量巨大，需要分库分表，那你整个中间件干嘛？中间件的作用是屏蔽底层数据没错，但还有个场景是数据读写分离，一般是在大数据量并且有高并发需求的系统使用，你一OA系统，能有多高的并发？需要用中间件这么高端的东西么？

再看看微服务，为了降低系统的耦合度使用了微服务，同样场景也不对，什么时候需要把服务拆分出来呢？只有在当前服务已经耗费了单台机器太多的资源了，单机扛不住了，才会把功能比较独立的模块拆分成微服务出去，因为微服务虽然降低了系统的耦合度，但是需要更多的考虑到系统的可用性和网络因素造成的问题，对开发人员的要求更高，一个OA系统，能有多大的计算量？后面的前后端分离啊，docker部署啊，你想想各自的必要程度如何？一个OA是否需要绚丽的界面？一个OA系统的更新频率有多高？是否需要docker这样的东西来帮助部署？成本如何？再看看是否是过度设计？最后，我觉得上面这个系统，比较合理的修改设计是：

把数据库加上一个主从同步，保证数据的可靠性，别数据库挂了，那客户可会跟你拼命，这是最重要的。

把系统的SQL语句梳理一遍，看看有没有什么慢SQL，然后做针对性的优化，比如加索引，改SQL之类的。

把后端的服务加上详细的Log信息，这样出了问题也好查问题，并且可以把Log收集起来做分析，看看系统的瓶颈在什么地方，然后再在局部做优化也好重构也好，这样对系统的侵入性最小。

这样下来，系统的性能应该有提升，数据可靠性也增强了，并且也耗费不了多少资源，通过Log分析，一个局部一个局部的优化，直到发现了一个大坑需要拆分服务了，再进行服务的拆分，如果你有更好的建议，欢迎留言讨论啊。

2、重构的理由

我觉得重构得满足以下几个条件的大部分，才有重构的必要，第一个条件是必须满足的。

现有系统的所有功能模块和对外接口都了解得非常清楚了。如果你没把对外接口了解得非常清楚，重构完了以后外部的依赖系统必然要跟着改，那就是个无底洞了。

现有系统有明显的重大BUG，并且在现有条件下无法解决或者很难解决。如果仅仅是系统有BUG，那么解决BUG就好了，完全没有必要为了BUG来重构，只有当确实BUG已经无法解决或者解决的成本实在太高了，才有重构的必要。

文档缺失或者维护人员大量离职导致目前系统的可维护性降低，很难添加新功能。如果大家都很熟悉现有系统，可以很快的在上面迭代新功能，你重新来一个系统干什么呢？

现有系统在可预见的未来无法支撑业务的发展了。只有当业务部门已经跑到了技术部门前面了，可以预见得到业务发展的方向了，再来审视目前的系统，发现已经无法继续支撑了，这时候才需要重构现有系统。

而重构最忌讳的用以下理由来重构系统

现有代码太臃肿，实现不完美。难道你重新实现一个就完美了？

这个系统的技术栈太陈旧，没有使用最新的技术流，以后肯定会落伍。难道用了新技术就不会落伍？

现有系统没有考虑高可用的情况，要是出问题了就是大问题。

这个语言就不适合做这个系统，得用XXX语言来实现。虽然说每个语言都有他擅长的场景，但是一个既有系统更换实现语言，是一件成本非常高的事情。

总而言之，重构一个系统最需要考虑的就一个词：成本，需要衡量各方面的成本后，再考虑是否需要重构，这样的重构才是有意义的重构。

高可用架构的银弹

上面我举例子举的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、高可用的银弹在哪？

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