坑系列 --- 重构过程当中的过分设计

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

这一篇，咱们从重构这个场景来看看系统架构的设计中过分设计这个坑。

首先，咱们这里说的重构，和《重构:改善既有代码的设计》这本书中的重构不太同样，这是本好书，他主要说的是代码级别的重构，这种重构是须要在编码的时候时时刻刻进行的，更多的是一种编程思想的训练，而咱们这篇的重构主要是说系统设计的重构。

0. 关于架构师

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

• 系统架构师，这种技术能力是最强的，这也是通常人眼中的架构师了，这种架构师通常属于领域架构师，对某个领域的技术有比较深刻的了解
• 业务架构师，我只是用了这个名字而已啊，有些地方的业务架构师其实和上面的系统架构师没什么两样，但有些业务架构师有些脱离了技术了，基本上变成了一个项目经理的角色，各类沟通，我以为不该该算架构师了。
• 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语言来实现。虽说每一个语言都有他擅长的场景，可是一个既有系统更换实现语言，是一件成本很是高的事情。

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

OK，这一篇简单的说了一下重构场景下的过分设计的问题，后面还会有和过分设计相关的，你也能够说说你遇到的过分设计，欢迎留言给我哈。

---

若是你以为不错，欢迎转发给更多人看到，也欢迎关注个人公众号，主要聊聊搜索，推荐，广告技术，还有瞎扯。。文章会在这里首先发出来：）扫描或者搜索微信号XJJ267或者搜索西加加语言就行