近来一直在做一个产品的架构升级，架构升级的前期工作是对旧架构现存的问题进行梳理，考虑新架构的设计如何规避旧架构的坑，完善旧架构支持不佳的缺陷。终于完成了新架构设计，在给开发工程师讲解时，还会遇到开发的疑惑：新架构真能实现旧架构上支持的特别困难或别扭的场景么，如此等等。一个架构从设计到实现，到底要做些什么，关注些什么?
那么我们就从下面这个问题开始梳理吧。
架构做什么
查了下维基百科(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.
要明白做什么，首先需要考虑目标是什么?软件架构的目标是要设计软件系统来解决问题，所以架构要做的事从抽象的维度上看，就是：
- 根据问题域，界定系统的边界
- 对系统进行切分，切分的目的是分工与协作(并行，以获得效率)
- 被切分的各部分之间建立交互与沟通原则与机制
- 将部分连接合并成一个整体，完成系统的目标
更具体一些来说，架构做得就是结构设计，在不同维度和层次上：
- 高维度：是系统、子系统或服务的切分与交互结构
- 中维度：是系统或服务内部的模块划分
- 低纬度：是代码结构、数据结构、表结构
当在架构升级这样的事情中，架构师的职责之一是要交付“一种架构”，而这“一种架构”的载体现在通常又会以某种文档的形式出现。所以，很容易误解架构师的工作就是写文档，实际上架构师的交付成果是一整套决策流，交付载体通常体现成了文档。在这个过程中，架构师的首要工作就是保证在架构方案执行中，整个开发团队的实施效果与决策保持一致。即使在这个过程发现了实施与决策的冲突，就又需要重新协调沟通讨论以取得新的一致。
当系统规模比较小时，比如架构师一个人就能把全部的设计决策在交付期限内开发完成，这就省却了很多的沟通协调讨论成本。五年前，我就曾这样做过一个小系统的架构升级改造，但后来的系统越来越大，慢慢就需要几十人的团队来分工协作，如何保证架构设计中的决策在架构执行过程中保持一致，这成为了架构工作的真正难点所在。
架构关注点
架构设计的决策流一旦落在了文档的载体上，它实际就是一个静态的东西了。而真正的架构执行过程却是动态的。在这个动态过程中，架构师需要定期地去对系统的状态做快照，观察是否有出现需要解决的问题，而这些问题就是技术层面的架构关注点。
一些问题也许是架构执行中新出现的，在当初的架构设计中未能考虑到，需要对此做分析判断，并形成新的决策。而另一些问题，也许是执行过程中的走样，导致和当初的决策形成了偏差。架构师需要考虑所有这些关注点，并和开发工程师找到解决这些关注点的各种选项，在适当的时候根据真实环境的情景去采取合适的行动。有时，我们称这些行动叫作：重构或优化。当一个旧系统长期没有这样的行动，积累久了后，我们将迫不得已采取另外一种行动，我们称之为 —— 架构升级。
软件系统或架构，不像建筑物会因为时间的流逝而自然耗损腐坏，它只会因为变化而腐坏。一开始清晰整洁的架构与实现随着需求的变化而不断变得浑浊、混乱。信息与计算机科学都爱借用一个物理学的术语「熵」，它表达体系的混乱程度，而软件系统的「熵」很容易不经意间随着需求的变化而变得更高。
软件系统「熵」有个临界值，当达到并超过临界值后，软件系统的生命也基本到头了。这时，我们就要采取那个迫不得已的行动了。图例展示了软件系统「熵」值的生命周期变化。
所以，近年流行的微服务架构有个很大的优势，服务粒度合适，服务物理隔离，单个服务的「熵」增问题被局限在单个微服务内部。单个微服务的替换与重构成本十分有限，使得「熵」增问题局部化，不容易传染全局，以致失控。当然这有个前提，就是微服务的拆分和接口交互要合理，合理的检验标准就是随需求变化，总是实现变化或接口新增，而非总是调整接口交互。
架构始于系统生命之初，并伴随系统生命周期全程。每次需求变化带来的变动都应进行一次或大或小的重新架构过程。架构的关注点在于控制软件系统变动时「熵」值的变化。
架构等效性
架构升级中一开始的疑惑：这个新架构能实现么?其实，这根本不是一个值得疑惑的问题。
相对于建筑架构，软件架构过程其实更像是城市的规划与演变过程，有一定历史的城市，慢慢都会演变出所谓的“旧城”和“新城”，新城相对于旧城，就是一次架构升级的过程。城市规划师会对城市的分区、功能划分进行重新定位和规划。一个旧城所拥有的所有功能，如：社区、学校、医院、商业中心，你难道能想象新城会没有吗?或者说“实现”不了吗?
所以，如果一个单体应用能实现的功能，换成微服务架构肯定也可以实现，只是编写代码的方式不同。不同架构在功能的可实现性上其实是完全相同的，我称之为：架构等效性。不同的地方在于哪里呢?如前所述，切分方式不同导致的分工协作完全不同，因此获得的效率与付出的成本也会不同。
架构升级，仅仅是一次系统的重新布局与规划，成本与效率的重新计算与设计，熵的重新分布与管理。
【本文是51CTO专栏作者胡峰的原创文章，转载请联系作者本人获取授权】
