做了这么多年架构师，我终于理解了什么是架构设计

作者：博文视点Broadview

2022 年 1 月 27 日
本文字数：1931 字
阅读完需：约 6 分钟

作为软件开发的一个永恒话题，“架构”一直在被讨论、被总结和提炼。经验越久的开发者，对“架构”越会形成下面这样一些认知：

架构不曾有一个“标准答案”，架构决策受技术框架、业务场景、团队能力、公司规模、组织架构等多种因素影响；
架构理论随着某些技术的成熟而完善，又随着某些新技术的发展，旧的成熟理论被重建；
互联网产品所引发的海量大规模分布式系统，使得架构的领域也越来越细分：基础架构、中间件、业务架构、领域建模、大数据、云原生、AI……

因为架构需要如此多的“综合”知识，做决策的思维方式又如此“灵活”，程序员在走向架构师的成长过程中，或多或少都会遇到各种技术成长问题。

这些问题，总结起来有下面几类：

（1）有大量项目实验，但缺乏理论知识，思考深度不够，不能把项目中的核心问题和核心方法提炼总结；

（2）有不少理论知识，比如操作系统、分布式、领域建模，但不能很好地应用到自己的日常项目中；

（3）知识点、技能点掌握得很多，但是比较碎片化，不能把点连成线、把线连成面和体；

（4）不断地追逐新技术、新框架，疲于奔命，却忘了做项目、做系统的一些根本思维方式；

（5）不能很好地处理业务、技术、组织架构三者的关系。

只有解决了“架构理论与实际相结合”的问题，才能构建起真正的方法论，解决上述列举的这些技术成长问题。

这里所讲的方法论，不是讨论解决问题的“具体技术或者框架”，而是真实解决“问题”本身。不是说解决问题的方案不重要，而是“定义问题，提出问题，往往比解决问题更加重要！”同样的问题，用 C++、Java 等不同语言和技术框架解决时，解决方案会有差异；在电商、广告、金融等不同业务场景中，解决方案也会有差异，但问题本身却是一样的。

比如分布式 ID 生成器，不管用什么语言写，也不管用在什么业务场景中，都有它本身固有的几个问题要解决。
比如消息中间件，要实现消息的不重不漏，也是一个无论在何种开发语言和业务场景中都需要解决的共性问题。
比如高可用切换导致的“脑裂“问题，无论在基础架构，还是在业务系统中，都会遇到。
比如高可用切换导致的数据一致性问题，无论在 Kafka、MySQL，还是在 Redis 等系统中也会遇到。

方法论的作用是建立“迁移学习”的思维。迁移学习指的是当遇到新业务、新技术时，可以把之前的分析和解决问题的方法，快速地用到新的领域，提升学习效率。

而实践是什么呢？实践只是针对这个问题，在某种特定的业务场景下的其中一种解决方案。

我们可以列举不少实践案例，但不管怎么列举，都没办法把所有业务场景或实践全部枚举出来。解决方案可能是无穷的，但问题本身却是有限的。只有明白了这点，才能在新的业务场景和技术框架下，用同样的思考方式去解决问题：技术框架一直在变，业务场景也一直在变，解决问题的方案也随之在变，但那些“问题”却是永恒的。

《软件架构设计：大型网站技术架构与业务架构融合之道》一书的作者总结过一句话：软件架构是针对软件设计的所有“重要问题”做出的重要决策。对于一个大型在线系统来说，面临的“重要技术问题”主要包括四个：高并发、高可靠、数据一致性、高可用与容灾。这也正是分布式架构要解决的几大核心问题，如图 1 所示。