而这些所谓的“架构师”们，如果仅仅是title上的改动，平时工作中该撸代码就撸代码，该摸鱼看网页就看网页，其实也真的没什么。

最最最最怕的就是，他们觉得自己的身份已经变了，是时候该体现出自己作为系统架构师价值的时候了，那一切就会变得不可收拾了。

这些架构师们体现价值的方式当然是做架构设计。按照他们的话说，系统架构要具备前瞻性、灵活性、复用性、伸缩性、可维护性、可扩展性、低耦合性、高内聚性、可移植性。当然，基本上90%都是过度设计。

下面让我们来细数一下，那些年，我所经历过的过度设计。

不久前我面试过一个中小厂架构师，看他的简历上赫然写着，“主导XX系统从单体服务往微服务架构演进工作”。

然后我问他的问题是：“详细说下微服务拆分这件事情，包括：微服务拆分的原因、时机和拆分后的粒度。”

这个架构师说的第一句话就把我雷到了：“微服务拆分的粒度，我认为越细越好，不然为什么叫微服务呢？而且，现在的一个很小的微服务，随着业务的持续迭代演进，未来都有可能变得非常庞大，我们做架构设计的，必须要具备前瞻性。”

他接着说：“我们的微服务不但按照业务模型进行的拆分，而且我还按照controller层、service层和dao层也做了拆分，这样可以提升代码复用性，你想用我哪层的代码，就可以调用我哪层的API。”

最终，一个单体服务就被他拆分成了这样。

我问他：“微服务的‘三个火枪手原则’了解吗？”

他摇了摇头，说不清楚。

我心里感慨道，今年云厂商业绩能不能达标，全看这类架构师的了，他们是真费机器啊。

去年，跟一个三方公司临时组建了一个项目组，共同开发孵化A项目。

项目联调期间，我跟三方公司的小A说：“我刚调用了你们项目的XX接口，新增了20条交易数据，你看看你们接口的业务处理正常吗？数据库里面有这20条数据吗？”

小A说：“好的，稍等，我看看。”

20分钟过去了，我问小A看得怎么样了。

小A说：“业务处理是正常的，数据我正在一条条找，20条已经找到17条了，我在招剩下的3条。”

我听得有些懵，问小A：“你直接从你们订单表里，不能一下子看到20分钟前写入的20条数据吗？为什么还需要一条条找啊？”

小A说：”我们的架构师老张，按照每天三百万订单的数据增量，做了一个五年架构规划，已经分好了3个库和300张表。我现在正在根据他的路由规则，一条条地找这些数据。“

忽如一夜春风来，满城尽是大中台。

2015年福厂正式提出了“大中台、小前台”的中台战略，通过将原本分散到各个业务的支持部门，比如技术部门、数据部门集中到一起，进行快速的服务迭代，以期更高效地支撑前线，大幅降低支持部门的重复投资建设。

三年后，各个大小互联网公司纷纷跟进，争相建设自己家的中台，也就在这时，某独角兽公司的架构师老范过来找我取经。

我跟老范说：“你们的两个主业务是机票和酒店，业务差别太大了，且创新孵化业务并不多，并不适合中台策略。”

老范说：“不，中台这个我们一定要搞，因为既是研发团队的政治任务，也是我个人的技术追求。”

半年后，我问老范搞得怎么样了，老范说：“唉，讨论了半年哪些职责属于大中台，哪些职责属于小前端，现在还没讨论明白呢。”

某大厂收购了某公司，在收购后的一次技术交流中，我听到对方公司的首席架构师说：“MQ是个好东西，能异步处理，能消峰，能解耦，还是应该在项目中多用用的。”

后来发现，大首席架构师的下级执行力真强，MQ真的在他们的项目中无处不在：

牛Class！

对，对，还是上次的那个首席架构师，他除了爱用消息队列外，还特别喜欢用缓存，而且是Guava Cache + Redis的多级缓存。

据同事说，这种多级缓存策略在这位首席架构师的熏陶下，已经遍布了OA系统、公司官网、消息中心、结算系统、供应链系统、CRM系统。

首席架构师说：“缓存不仅能提升性能，还能帮助数据库抗压，提升系统可用性，绝对是个好东西，应该多用一用。”

然后，公司的系统就经常发生多种缓存的数据与数据库的数据一致性问题。

首席架构师又说：“任何架构都是有利有弊的，但只要利大于弊就好，不要太在意。”

记得我刚上班不久，组内有一个架构师同事，写的代码巨复杂，各种技巧、设计模式、高级语法满天飞，还沾沾自喜地给我们炫耀。

一次Code Review的时候，我嘴欠问他这里咋这么设计，他就鄙视地说：“你连这个都不知道，这是设计模式中的建造者模式啊。”

当时觉得他好牛，而我好low。

以后，每次进行Code Review，只要看到其他同事代码里有几个if else，架构师同事就质问道：“为什么不用策略模式优化if else？”

当然，还有其他的质问，类似于：这块为什么不用抽象工厂模式？这块为什么不用代理模式？这块为什么不用观察者模式？

后来我们就给他起了个外号，叫“设模”（se mo）。

前面说的那些架构师们，他们过度设计所带来的后果是浪费服务器和研发资源，但架构师老邓不一样，他的过度设计是浪费表。

之前见过某在线教育公司设计的表结构，基本上所有表之间的外键关系都是按照多对多方式设计的，也就是加一个中间的关系映射表。

有的我是可以理解的，比如：

但是，但是。

老邓说：“万一以后业务变化了呢？一切皆有可能啊。”

还在上大学的时候，在CSDN上看某著名架构师在极力强调数据库的可移植性。

我记得当时的原话大概是：

当时听了，觉得这个大架构师简直就是YYDS。然后我工作了这么多年，也没遇到过一次数据库移植。

我厂某团队的架构师老李素以严谨著称，其经常放在嘴边的一句话就是：“工程师不仅仅是一项有创造性的职业，也是一门严谨审慎的职业。”

这话说的确实没毛病，我也看过他们团队的工程代码，程序的边界处理、异常处理和容错处理做得都特别好，入参校验也是特别细致入微。

就像老李所说的那样：“All input is evil.”

不，等等，入参校验没问题，但怎么从数据库里读出来的数据，为什么还要再校验一遍？难道不是在写入的时候校验吗？

老李面无表情地说：“如果数据库中的数据，并没有经过应用程序处理，而是不知道被谁直接改库了呢？”

天呐，这是数据校验无间道版吗？

还是上面的那个架构师老李，他要求团队代码中带数字的地方，全部走配置中心，这样可以不发布代码就直接进行修改。

然后，我就看到了这样的现象：

配置中心啊，你的责任真的好重大。

遇到这种类型的架构师，真的特别想把他们祭天了，因为我是Kiss原则的忠实拥趸。

Keep it simple，stupid，即：保持简单、愚蠢。

保持简单就能让系统运行更好，更容易维护扩展，越是资深的人，越明白这个道理。