在架构的演技过程中，容易掉进如下几个问题的大坑里：

• “重复造轮子”：这句话相比有过几年工作经验的程序员不会陌生，但这种问题在架构设计中也非常常见。很多时候，尤其是新人，由于经验、视野问题，找不到可用的轮子，遍从头创建一个轮子。就算只有10%的差异，却要重写90%的代码，相比于成熟的开源软件，一两个人维护的产品很难持续。所以实际架构设计中尽量使用成熟、开源的解决方案，及时少量不满足的功能，多数情况也可以通过变通的方法解决掉，或者进行少量的二次开发以满足需求，而不是因为一点满足都要从头开始，再不考虑功能的情况下，这里的时间成本，人力成本，可维护性都是个严重的问题。

• 脱离实际业务需求：需求决定价值，技术的价值在于满足了业务的需求，在架构设计中为了技术而技术，不考虑业务是否真实需要是没有任何价值的。一味求新求变，尤其是使用很多小众软件，而不考虑是否真正为业务带来价值，是不可取的，有事反而会增加系统架构的脆弱性，维护的难度，反而让架构更加不可靠。再一点就是一位追求大公司的解决方案，互联网行业有很好的分享氛围，网上能找到很多可以借鉴的资料，尤其是大公司公开出来的，所以很多人就变成了伸手党，一味抄袭大公司的解决方案，而不加任何分析，不考虑是否真正能为业务带来好处，一句“Amazon”就是这么做的，“Facebook”就是这么架构的，就成了最终的决策依据。但要记住，你不是Amazon，你也可能不是Facebook，你不一定有那么大的规模，也可能是面临不同的业务问题，所以不要盲目追求别人的方案，可以有选择地借鉴，但不要完全抄袭。

• 避免无意义的重构：“铁打的营盘流水的兵”，随时时间的推移，架构还是那个架构，维护架构的人的人已经不是之前的那批人了，互联网行业发展这么快，人员流量也很正常，有事一个业务一两年甚至几个月就会换一拨人。对于系统架构，或者程序架构，后来的程序员面对前任留下来的东西旺旺是脸上波澜不惊，心中翻云覆雨，虽然谁技术是相通的，但不同的程序员、不同的架构师面对同样的问题是，态度可能不一样，也许系统中用的某些软件不是他擅长的，或者某些代码风格不是他习惯的，所以很容易就会滑向重构的坑，为了自己运维使用的舒服而把架构中大量的组件重构，而不考虑是否会业务带来价值，如果这种问题不解决，下一波人进来还会重复这种问题，就会不断进入重构再重构的恶性循环。所以为什么我推荐在架构设计中尽量使用成熟的方案，使用敏捷的方式，简单可依赖，才能避免不断滑入毫无价值的重构的坑。

• 功能完成是完事了：很多时候，很多人认为只要功能完成了，满足业务需求了就是完事大吉了，但还要考虑后期维护，升级的问题。如果没有清晰的文档，教程、后来的人搞不懂架构的细节，面对业务升级，就会不算地打补丁解决临时问题，补丁摞补丁，整个架构逐渐腐化掉，最后积重难返很容易把原来的方案推翻重来，就像前文提到的，就会滑向毫无意义的重构的大坑里。

• 技术解决一切：双十一秒杀为例，通过验证码，问题方式解决，就可以轻松缓解瞬时压力。