撇开代码不说，谈谈我对架构的6个冷思考

普通程序员如何定义架构？架构师又是如何定义架构？这位老司机一直用最简单的方式对架构进行定义：架构是一种用计算机解决问题的综合能力，与头衔无关。

计算机是个复杂的机器，相比普通的机器（比如小家电、汽车），它可以在使用过程中对其工作行为进行再定义和场景适配，以解决不同场景下的人的需求和问题，这种定义的结果，对于机器的最终用户来说，是应用 / Application。

对于非计算机相关的普通人而言，即便是有诸多对于职位头衔的描述：程序员、软件工程师、架构师、首席技术官，也离不开一个潜意识的印象：做网站的或者是修电脑的。

很多架构师，都是从软件工程师开始，不知不觉的变成了一个架构师。对于我个人而言，当我还是一个实习生，被升为一个部门架构师带领一些正式员工干活的时候，对架构师这个概念居然是一片空白，甚至于不知道这是个好消息，还是个坏消息，当然也不知道架构师是干嘛的。

所以，我一直以最简单的方式对架构进行定义：架构是一种用计算机解决问题的综合能力，与头衔无关。下面我将结合自己的工作经验，谈谈这些年来，我对架构的理解。

架构源于对实践的总结

架构能力并不是与生俱来的，而是和具体经历强相关的，丰富的经验是形成架构能力的基础。

很多时候我们强调系统性思考对于架构设计的重要性，希望从方法论上能够对正在从事或者即将从事架构工作的程序员在专业能力上进行提升。教条式、填鸭式的培训，是教不出架构能力的。理论的价值是能够帮助应用理论的人少走一部分的弯路，但不能够解决眼前的现实问题。

在企业里，架构是一个实践结合非常紧密的领域，一切以解决实际问题为目标。由于问题是多种多样的，导致解决的方法也是多种多样的。踩过的雷，填过的坑，都需要进行总结和抽象，才能提升到架构层的高度，防止重蹈覆辙。

架构是一个建模的过程

对于一个复杂问题，通常会对复杂问题按照能力领域进行分解，其目的是能够找到与现有能力相匹配的映射。这个映射，就是解决方案。它，离不开人的「知识型劳动」，主要分解为三个方面：

对于已知问题的抽象和建模
对于已知能力的抽象和建模
对于解决方案和工具的设计

其中前两个方面，都提到了「建模」。建模本身是对客观事物的一种抽象，客观事物越复杂，那建模的结果变成盲人摸象的概率就越高。

然而，盲人摸象在IT领域其实不能算是个贬义词，因为这个现象十分的常见。究其原因，解决实际问题信息系统，更多程度是面向于典型应用场景，而不是任意应用场景的。

场景即是对客观事物的认知视角，信息系统做不到、也不需要对一个完整的客观事物进行全面（360°无死角）建模。

举个具体的例子：对于人这个客观事物，银行系统里，可能会关心这个人财务指标，例如收入、支出和存款余额，但在医院的重症监护病房里，可能就会关心这个人的生命指标，例如血压、心跳。

从例子里可以看出，一个面向具体问题的场景化应用系统，都是对一个客体进行片面的场景化建模。

说到底，建模是一种抽象能力，具体的说，是人对客观事物认知结果的理性提炼和总结，不可否认感性的部分太难以刻画和描述。很符合《庄子·天道》中所述：「意之所随者，不可以言传也」。

如果要拿数学语言进行描述建模的能力，就是找到一组尽可能少的特征向量去表述这个空间，而找这组特征向量的能力，就是建模的能力。

架构工作的核心是设计

没有软件的计算机，是无法使用的，因为没有办法帮助我们解决任何问题。计算机原本很生硬，无法很柔软的去直接适配所需要解决的问题。

架构的核心工作是设计，设计计算机如何按照预期进行工作。

架构设计中，建模的结果，是模型，它有着结构化、棱角分明的特质，因为这是计算机进行计算的最高效的方式：严格的告诉我们——两个数是相等还是不相等，及其衍生。

正由于严格匹配，所以在很长的一段时间里，解决方案的制定和后续系统的交付运行，都围绕着如何严格按照实际场景进行模拟和落地。很少以按概率成功对系统的业务功能进行设计和实现，一切都必须绝对正确。因为绝大部分的计算机系统，无法理解自然语意。只能根据人为设计的结构化信息，按部就班地完成重复性劳动。

人工智能、机器学习，在解决自动化建模领域的成熟度还是远远达不到人的能力，如果达到了，那么软件就不需要人进行架构设计了。简单的从架构设计的结果（当然也是结构化的），生成代码，这方面目前的计算机还是有能力胜任的。

任何不符合实际场景的计算结果，用户都认为是缺陷，而在系统中产生此类异常结果，往往需要程序员为此承担相应的责任。呐，回想一下，在没计算机的时代，反而往往都是店小二算错了帐自己赔，没有人会去责怪算盘。

这是为什么，因为算盘足够简单，简单到不需要做任何的监控系统、不需要记录任何的日志，连三下五除二这样的操作规则，都已经被社会化学习消除了使用成本。最终，一切出错的原因只有一个：用键盘的人。

是的，计算机系统生来就是是不可靠的，它不可能像算盘一样在运行期不依赖任何的自然资源。断电了，会引发故障；光纤断了，会引发故障；磁盘满了，会引发故障。。。一系列的不确定因素，导致分布式系统架构设计比主机系统的架构设计复杂的多，原本不需要操心的事情，都需要从更上层的软件层加以解决了。

所以，当前架构工作的很大一块，都随着分布式系统规模的增大而加大了比重。也许，导致世界上最聪明的一伙人都去解决计算机的问题了。

架构需要作出一系列非技术选择

架构既然是个解决方案，自然有很多可以自由选择的领域，有很多受限的前提条件。这些外围因素，往往还系统背后的个人、团队、企业的价值观、以及非IT能力有关，这是一个很容易被忽视的点。

与人和团队的关系

架构往往是与个人或者团队的能力有关的，因为架构前一部分是设计工作，后一部分是代码框架的落地工作。可以没有一个十全十美、满足各方需求的方案，架构过程中有很多都是妥协的结果，有的是向需求妥协，有的是向运维妥协，有的是向个人英雄主义妥协。另外，绝大部分的选择都是人作出的，这导致了和人、团队的水平形成了很大的耦合关系。

早在1895年，法国心理学家勒庞在他的心理学名著「乌合之众（The Crowd）」就早已经说过：一群精英所作出的群体决定，很有可能是最愚蠢的决定。有时候，技术团队不能太强调民主；有时候，技术团队中的强强产生的效果是「1 + 1 \< 1」。一个良好的、强弱结合的组织结构，才有可能孵化出优秀的工具，再进阶为一个优秀的产品，也有利于成员梯队的培养。

团队越大，一个优秀的架构设计方案被严格执行下去的可能性越小。第一，制定方案的人和落地方案的人大多数情况下都有脱节，很多设计精巧的方案细节到了执行者的手里，会被忽视。

第二，为了统一一个团队的认识结构、设计理念，这部分的培训成本往往都是各个雇主不愿意付出的。第三，方案的描述本省是不精确的，还很容易存在文档过期的情况，在软件及交付的各个环节，任何参与者都有机会以自己的知识背景作为出发点进行理解，并自豪地加上自己的杰作。

与企业的价值观相关

企业的价值观，最直接的体现，就是企业的投资组合。

在大型的企业里，软件产品的采购往往会受制于采购部，也会受制于不懂IT的公司级领导所下达的行政干预，有些理由好像听上去也很有道理：采购过为什么还要采购，要保护投资。往往到了这个层面，程序员、架构师都纷纷表达了无奈。

软件，包含代码和数据。它不是一个简单的能够按照固定资产折旧进行的固定资产。它透射的是使用者对客观世界的认识，也需要随着对客观世界认知的变化而变化，因此版本对于软件来说就是一个时刻认知的快照沉淀。

行业的快速发展，企业的快速发展，势必推动企业信息系统的快速发展。对于企业而言，其价值是能够找到感知行业、感知产品、感知用户、感知企业内部运营的触角，每个社会中的实体不管是个人，还是产品都能够在系统中找到它的影子。

对企业主而言，IT是一个长期的投资行为。陈旧的、不符合时代背景的软件，是会变成降低企业生产力的绊脚石。

代码是架构设计的落地实现

现今任何的计算机高级编程语言，例如Java/C/C++，或者更高层的DSL，都是人与计算机之间的单向语言。这些单向语言，并非自然语言，大多数由程序员编写，再交由计算机进行执行，在很长的一段时间内，信息系统都是以这种方式与人进行交互。（当然，也可以慢慢的等待「Siri」之类的助手长大成人，成为一名架构师，也许那个时候，广大架构师需要转行了。）

代码是架构实现的核心，通过代码可以完成对现实世界的虚拟化：