架构闲聊之：伪架构过度设计有多可怕

摘要：仅个人吐槽的随笔，做一些散发性的思考，也欢迎读者来辩驳纠正自己错误的观点。

定位

“不想做老板的员工不是好员工” ，这句话对于普通人来说未免有点眼界过高。那我们降低自己的期望来聊聊，”不想做架构的程序员不是好程序员”。

对于每日忙着交付的码农来说，能闲下来有点私人时间就很不容易了，谈什么架构或者设计，那是有理想有抱负人干的事情，恨不得别人把架构搭建完美，照着模版可以快速把任务完成，等哪天心情好了翻翻书学习下，以掩饰内心的焦虑感。

瓶颈期再上升一个层次就需要突破就得多思考，除非就只甘于做一名资深搬砖工。做一名合格的架构师是为自己上升通道做的其中一项准备，当然这里可能还涉及到运气、软能力、情商等更重要的必备条件。

架构是什么

几年工作下来，虽然也有参与到架构设计和开发，但是很少系统去思考整个问题，只是零零碎碎积累了一些自己的观点。

那么重点来了，架构是什么？我觉得就是利用仅有的资源（人力和物力）、时间节点选择最适合项目开发的技术框架，然后我们进行迭代，快速产出能持续盈利的产品。

小公司里的大公司病

在互联网洪潮的冲刷下，巨头IT公司积累的经验是普通公司不可比拟的，随之而来的是，互联网公司都喜欢遍地招这些巨头的员工，因为他们希望借助这些科技人才帮助公司茁壮成长，并且也能更好的进行融资和招揽人才。这些人才中，很大一部分是经过层层筛选出来的精英人才，他们掌握了良好的基础，拥有丰富的架构设计理论和实践。但是有一小部分是进去为了镀了一层金出来谋求更好的发展，或者靠实力进去后吃老本几年混不下去出来的人，他们精通各种话术（专业术语），信手拈来的成熟架构体系，大公司的资源丰富，于是养成了对服务器资源无节制使用，美其名曰背靠大山，不怕坐吃山空。常挂嘴边的口头禅：我们xx公司原来也是这么设计的…

这样真的合理么

下面来说说我经历过的一些案例，这样真的合理么？

案例1:
公司被大公司A收购后，A公司空降架构师过来领头做新项目，上来就启动一个千万级的新项目。公司的小伙伴乐呵地开始折腾起新产品，架构师开始添砖加瓦，过度拆分缓存、拆分服务，分库分表，为将要来的千万洪潮做足了准备。与此同时，每日新增的量不过几万，分库分表的表单数据刚过百万，请求慢的原因不过是索引的错误使用…之后的几个月里，产品的快速迭代开始让小伙伴喘不过气，因为架构的过度设计变得异常复杂，每新增一个功能都变得举步艰难，由于迭代速度快，开发节奏慢，导致测试也开始频繁出错，小伙伴们不得不通过加班加点完成需求，朋友圈终日都是”凌晨x点的xx真美”…N个月以后，因为开发周期过长，产品迭代速度慢，用户量遍一直徘徊在百万级震荡。

案例2:
传统大公司有钱，推崇微服务，请来一群大牛开始折腾。蓝图是美好的，各部门宣讲微服务拆分粒度，接触项目后发现原来一个完整功能服务被拆分为多个微服务，并且老早就把工程完全拆分了，每次需要提交n个工程，打包编译n个工程。某天发现新人把同一个函数的调度分别写在了各个服务中，压测并发出问题后发现成本太高，没法统一优化，又赶在上线的节骨眼，于是便排到后续优化的任务中去了。再之后上线，便因为该功能波及面太大而不了了之。

可能一些地方的决策有自己的考虑，但是我们有没有更加优雅的选择？

1. 不要过早拆分
   服务能不能通过module以包的形式切分（java9 引入了模块化），然后通过pom绑定父子工程来管理，后续分布式部署或者上线前只要将包独立拆分部署即可

2. 不要过早分库分表
   前期设计好主键，方便后期分库分表的拆分，而不是上来就对没数据量的表进行拆分，增加维护成本

3. 谨慎架构设计选型
   大公司的架构固然成熟，但是小公司需要考虑运作成本，而不是一味照搬

4. 衡量资源
   互联网公司运营成本中，人力、机器资源都是大头。一套成熟的架构体系是需要人员来维护的，中小型项目需要考虑维护成本，应该先用更轻量级更好管理的架构，而不是套用笨重的”成熟系统”，并且这些笨重的系统是需要机器来支撑的。

反思

反观上面的案例，都是不遵循架构的发展规律。架构是迭代设计出来的，没有通吃的标准架构，也没法一步到位，我们要因地制宜，层层递进，不断优化，最后才是适合自己的架构。尤其对于中小型公司来说，还没发展成型的项目始终存在着变动，我们应该设计应该是可扩展、易管理、易升级的架构，拥抱变化的同时不断优化，才不会因为笨重的包袱妨碍了奔跑的速度。