很多工程师都会假设网络是同质的，也就是所有的网络设备都来自同一硬件厂商，这当然也是一个谬误。实际上，一个大的通信网络中，硬件设备往往来自于不同的厂商，这得益于网络协议标准的统一。厂商间设备的协作测试毕竟不会太充分，在一些特殊场景下极有可能存在网络丢包，从而影响了网络的可靠性（谬误1：网络是可靠的）、时延（谬误2：时延是0）以及带宽（谬误3：带宽是无限的）。
一切从“大泥球”开始
“大泥球”架构是著名的反模式架构，最初在1997年由Brian Foote 和 Joseph Yoder提出。在“大泥球”架构里，系统没有进行内部的模块划分，代码耦合严重，调用关系混乱，就像一个大的泥球。如上图所示，每一个点代表一个类，红线则表示类之间的耦合关系。这样的架构对需求变更极不友好，往往牵一发而动全身，而且在部署、可测试性、性能等方面也存在着很多问题。所有的架构师都在极力避免“大泥球”的出现，但很不幸的是，它仍然在实际项目中很常见，特别是项目伊始，代码质量和结构还没被严格管控起来前。
有反模式的出现，必然就有解决它的方法，这便是架构模式，从下一篇文章开始，我们将逐个介绍常见的8种架构模式。
总结跟设计模式类似，架构模式是软件工程师们多年来在架构设计方面的经验总结。每种架构模式并没有绝对的优劣之分，我们不能说微服务架构就一定比单体分层架构优越，它们都有着各自的应用场景。分布式架构比单体架构有着更好的可扩展性、容错性，但也带来了更高的复杂性，比如分布式事务。因此，我们应该熟知各个架构模式的特点，这样才能在特定的业务场景使用合适的架构模式。
华为云社区专家｜元闰子