架构是规划、设计和构建建筑及其物理结构的过程与产物。在计算机工程中，架构是描述功能、组织和计算机系统实现的一组规则与方法。

【资料图】

[[192853]]

近来一直在做一个产品的架构升级，架构升级的前期工作是对旧架构现存的问题进行梳理，考虑新架构的设计如何规避旧架构的坑，完善旧架构支持不佳的缺陷。终于完成了新架构设计，在给开发工程师讲解时，还会遇到开发的疑惑：新架构真能实现旧架构上支持的特别困难或别扭的场景么，如此等等。一个架构从设计到实现，到底要做些什么，关注些什么?

那么我们就从下面这个问题开始梳理吧。

架构做什么

查了下维基百科(Wikipedia)架构(Architecture)一词最早源自建筑学术语，后来被计算机科学领域所借用。

架构是规划、设计和构建建筑及其物理结构的过程与产物。在计算机工程中，架构是描述功能、组织和计算机系统实现的一组规则与方法。

Architecture is both the process and the product of planning, designing, and constructing buildings and other physical structures. In computer engineering, "computer architecture" is a set of rules and methods that describe the functionality, organization, and implementation of computer systems.

要明白做什么，首先需要考虑目标是什么?软件架构的目标是要设计软件系统来解决问题，所以架构要做的事从抽象的维度上看，就是：

根据问题域，界定系统的边界对系统进行切分，切分的目的是分工与协作(并行，以获得效率)被切分的各部分之间建立交互与沟通原则与机制将部分连接合并成一个整体，完成系统的目标

更具体一些来说，架构做得就是结构设计，在不同维度和层次上：

高维度：是系统、子系统或服务的切分与交互结构中维度：是系统或服务内部的模块划分低纬度：是代码结构、数据结构、表结构

当在架构升级这样的事情中，架构师的职责之一是要交付“一种架构”，而这“一种架构”的载体现在通常又会以某种文档的形式出现。所以，很容易误解架构师的工作就是写文档，实际上架构师的交付成果是一整套决策流，交付载体通常体现成了文档。在这个过程中，架构师的首要工作就是保证在架构方案执行中，整个开发团队的实施效果与决策保持一致。即使在这个过程发现了实施与决策的冲突，就又需要重新协调沟通讨论以取得新的一致。

当系统规模比较小时，比如架构师一个人就能把全部的设计决策在交付期限内开发完成，这就省却了很多的沟通协调讨论成本。五年前，我就曾这样做过一个小系统的架构升级改造，但后来的系统越来越大，慢慢就需要几十人的团队来分工协作，如何保证架构设计中的决策在架构执行过程中保持一致，这成为了架构工作的真正难点所在。

架构关注点

架构设计的决策流一旦落在了文档的载体上，它实际就是一个静态的东西了。而真正的架构执行过程却是动态的。在这个动态过程中，架构师需要定期地去对系统的状态做快照，观察是否有出现需要解决的问题，而这些问题就是技术层面的架构关注点。

一些问题也许是架构执行中新出现的，在当初的架构设计中未能考虑到，需要对此做分析判断，并形成新的决策。而另一些问题，也许是执行过程中的走样，导致和当初的决策形成了偏差。架构师需要考虑所有这些关注点，并和开发工程师找到解决这些关注点的各种选项，在适当的时候根据真实环境的情景去采取合适的行动。有时，我们称这些行动叫作：重构或优化。当一个旧系统长期没有这样的行动，积累久了后，我们将迫不得已采取另外一种行动，我们称之为 —— 架构升级。

软件系统或架构，不像建筑物会因为时间的流逝而自然耗损腐坏，它只会因为变化而腐坏。一开始清晰整洁的架构与实现随着需求的变化而不断变得浑浊、混乱。信息与计算机科学都爱借用一个物理学的术语「熵」，它表达体系的混乱程度，而软件系统的「熵」很容易不经意间随着需求的变化而变得更高。

软件系统「熵」有个临界值，当达到并超过临界值后，软件系统的生命也基本到头了。这时，我们就要采取那个迫不得已的行动了。图例展示了软件系统「熵」值的生命周期变化。

所以，近年流行的微服务架构有个很大的优势，服务粒度合适，服务物理隔离，单个服务的「熵」增问题被局限在单个微服务内部。单个微服务的替换与重构成本十分有限，使得「熵」增问题局部化，不容易传染全局，以致失控。当然这有个前提，就是微服务的拆分和接口交互要合理，合理的检验标准就是随需求变化，总是实现变化或接口新增，而非总是调整接口交互。

架构始于系统生命之初，并伴随系统生命周期全程。每次需求变化带来的变动都应进行一次或大或小的重新架构过程。架构的关注点在于控制软件系统变动时「熵」值的变化。

架构等效性

架构升级中一开始的疑惑：这个新架构能实现么?其实，这根本不是一个值得疑惑的问题。

相对于建筑架构，软件架构过程其实更像是城市的规划与演变过程，有一定历史的城市，慢慢都会演变出所谓的“旧城”和“新城”，新城相对于旧城，就是一次架构升级的过程。城市规划师会对城市的分区、功能划分进行重新定位和规划。一个旧城所拥有的所有功能，如：社区、学校、医院、商业中心，你难道能想象新城会没有吗?或者说“实现”不了吗?

所以，如果一个单体应用能实现的功能，换成微服务架构肯定也可以实现，只是编写代码的方式不同。不同架构在功能的可实现性上其实是完全相同的，我称之为：架构等效性。不同的地方在于哪里呢?如前所述，切分方式不同导致的分工协作完全不同，因此获得的效率与付出的成本也会不同。

架构升级，仅仅是一次系统的重新布局与规划，成本与效率的重新计算与设计，熵的重新分布与管理。

【本文是清一色专栏作者胡峰的原创文章，转载请联系作者本人获取授权】

戳这里，看该作者更多好文