反架构

软件架构可以说是软件开发的“政治正确”，不谈“高大上”的架构，不但得不到客户的信任，也无法在团队中获得话语权，今天就来“反”一下。

架构设计本身就是个抽象过程，不但包含实践的方法和过程，还有抽象的理论和总结。而这个过程表象很容易掩盖本质，有时还可能是陷阱或骗局。

我一直是个实用主义者，也就是相信架构设计是以需求为出发点，遵循最小投入最大产出的原则进行。所以我主要“反”的是两种：

• 理想主义的架构
• 商业包装的架构

而很多坑都是在这两者之间纠缠，让你云里雾里。

理想主义架构

可以认为是比较唯心的，偏离了实际情况，追求完美，追求内心的舒适。这种架构思路在非常优秀的程序员身上都能找到，是难以避免的人性问题。常见的一些情况

• 可靠性：谈及可靠性容忍不了单点错误，从各种可能性上全面考虑，假设大量出错场景并解决。过度设计通常会导致系统复杂，可维护性低，因可提高靠性本身的功能产生了不可靠的问题。

• 可扩展性：过度追求设计上分离，分层，假设变化无处不在，通常会导致服务切分太细，维护工作量大，资源利用率低，性能下降。

• 性能：追求性能的极致，会产生会系统和环境的依赖，导致可移植性低，模块耦合严重。

• 理论深度：喜欢套用理论升华方法，本身是本末倒置的行为，但用在商业包装上却是合适的。是对外不对内的架构。

回过头来看，可以看到架构设计实际上很多时候是取舍，所以“什么都要的”的成年人想法是不实际的，根据具体场景，产品差异做好小孩子的选择。

商业包装的架构

理想主义常存在于追求完美的人性弱点里，而商业包装就是针对这种人性弱点所设计的有商业目的的架构，把程序员作为客户，包装出的架构或技术。它们有时不是为了解决问题，而是谋取更高的利益，鼓吹双赢，所以更加隐蔽。我们也思考一些例子

• 商业驱动的热门架构：比如云原生架构，微服务，上云，大力传播这种架构理念的是AWS，阿里云及其关联企业或组织，哪怕是开源组织，赞助商也是他们。不是说微服务不好，而是要审视自身的需求，平衡好预算和组织能力。因为对于商业来说数字化转型花了钱就一定要是“成功”的，“来都来了，做也做了”也只能说它好，上车容易下车难，所以一定要提前想明白。这种问题在大公司比较突出。

• 设备厂商的完美可靠性：通常提完美可靠性方案的话，都是设备厂商，因为可靠性最简单的就是“冗余”，说白了就是利用技术人员追求完美可靠性的心理，多卖一些设备，多赚一份钱，所以在技术架构上都打着一些旗号，也为甲方设计好了说辞。我承认作为乙方这是商业上的成功，也确实应该这样做。但最为甲方客户时，很容易过度投资。

• 开源技术的成本：但天下没有免费的午餐，除了“商业驱动”，还有就是“请君如翁”式的沉没成本。利用开源解决你的所有问题，需要自己“搭积木”，比如Hadoop表面上给出了完美的开放性，生态，但如果想搭建一套完整的大数据平台，那么至少涉及5，6个开源组件，并且有很多复杂的技术细节和经验，一旦因为免费，你投入了时间和精力，像极了“爱情”，被沉没成本冲昏头脑。而往往这种大而全的架构都很中庸，对场景模糊，需求贪婪的甲方很容易中招。

• 技术的阴谋论：因为各种商业目的，一些并不好的架构模式或实践也会包装成优秀实践，毕竟角度不同。哪怕角度相同，体质也不同。有的大公司通过分享复杂技术，完美架构方案，来进行人力和智力资源的对抗，最终必定大鱼吃小鱼。小鱼还得向大鱼求救，为大鱼买单，所以这些商业因素所影响的技术目的是很复杂的。

感想

虽然说了这么多负面的东西，但技术的本源还是正向的，会长期推动生产力的进步。还是要鼓励拥抱变化，无畏学习。

同时不要局限在技术上看架构，要从产品，组织，商业上多角度选择，还包括资源，人力，团队能力，商业合作，产品差异。

刚工作时，一位架构师培训时说“架构是长出来”，现在来看颇有深意，“架构”长得好不好，除了人的辛勤栽培，还有土壤，阳光，温度…

技术上承认自己的不完美，接受妥协，擦亮双眼，辩证而全面的想，低成本而无畏的学和试。