聊聊软件架构

架构，名词，汉语词典中的解释是框架、支架。我认为更贴切的应该是汉典的解释：人们对一个结构内的元素及元素间关系的一种主观映射的产物。就好比Framework（框架）和Architecture（体系结构）的区别。在计算机术语中，特指软件架构（Software Architecture），是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

正如Architecture源于建筑学术语，软件开发人员也被称作软件工程师。现在的软件系统越来越复杂，架构的作用也越来越明显。2004年，原计算机软件专业技术资格和水平考试将“高级程序员”等级名称改为“软件设计师”。其实，一名优秀的程序员未必可以成为一个合格的软件设计师。从编程到设计，软件工程师的成长之路上，一道技术门槛正是对“架构”的理解和把握。

架构的本质

要理解架构，可以通过热力学第二定律寻找答案。这条定律就是著名的“熵增定律”：一个封闭的孤立系统，它的混乱程度（也就是“熵”）一定会随着时间变化而变大，从而让系统从有序走向无序。

这个理论对于软件系统也非常适用。一个软件系统可以拆分为具体的业务和所依赖的技术。一方面，随着业务的发展和业务需求的增加，我们会往系统里不停地添加业务功能，融入更多技术；另一方面，技术的发展拓宽了业务边界，随着访问量使用量的不断增加，我们会不断通过技术手段来加强系统的非业务性功能和性能。如果事先不做良好的设计，随着时间的推进，整个系统野蛮生长，就会越来越无序，最终不得不推倒重来。软件系统架构的优化，其实就是对抗熵增的过程。

为什么建筑业会需要架构？我们看李子柒搭房子其实很简单，直接就可以上手；在农村盖一个两楼一底的砖房，稍微复杂一些，但对一个经验丰富的师傅来说不是什么难题，也不会提什么架构；而盖一座高楼，复杂程度就不是多几个泥水匠能解决的，需要专业人员事先做好整体的架构设计，并严格按照设计来施工。

软件系统也是如此。个人写个小程序，做个小网站，不会提什么架构。但从简单的桌面应用发展到现在的大型互联网平台，这个过程中，系统规模越来越大，业务和技术越来越复杂，就不是作坊式的软件开发能够驾驭的。我们同样需要通过架构设计，消化复杂性带来的混乱，使系统始终处于一个有序状态，能够应对现有和将来的需求变化。

所以，一个好的软件架构，就是可以通过调整系统各个组成部分的关系，不断扩展，满足业务和技术的发展变化，同时保证系统高度有序。用专业话来说，既要满足业务的可扩展、可复用，也要满足系统的高可用、高性能和可伸缩，落地成本还要尽可能低。

架构的方法

调整系统各个组成部分的关系，需要对系统内部进行合理编排，把系统打散，然后重新组合，形成更合理的关系。

具体方法就是“分”与“合”。“分”就是把系统拆分为各个子系统、模块、组件，明确功能定位，划分边界，实现合理拆分。“合”就是基于业务流程和技术手段，建立联系，解决依赖关系，把各个组成部分整合在一起，形成有机整体。

这样一来，通过合理的“分”与“合”，把原先铁板一块的系统变成一个富有弹性的结构化系统，就是我们常说的“高内聚、低耦合”，系统的复杂性有效分解，系统的有序度大幅提升。

架构师的自我修养

从编程到设计，需要把具体的问题抽象、拆解，再进行归类、整合。对一名架构师来说，在“分”与“合”的过程中，需要处理好3个关系。

一是技术和业务的关系。技术和业务双向驱动，两手都要抓，两手都要硬。

二是理论和实践的关系。读万卷书，行万里路，学习各种架构需要的知识技能，通过大量的实践把架构知识变成架构能力。

三是应然和实然的关系。再好的架构也需要最终落地。“应该是”的视角帮我们把握长远基准，“实际是”的视角帮我们解决当下问题。永远以资源有限、条件不足为前提，去实现合理的架构，让理想最终照进现实。