什么是架构

本文想说一说我个人对“架构”一词的理解

刚毕业那会，对IT行业完全不了解，只是觉得“项目经理”和“架构师”仿佛是很牛逼的。一段时间以后，基本知道项目经理是干啥的了，不过对于什么是架构师还是不太清楚，只是我心中永恒的牛逼闪闪的存在

工作久了也参与了一些设计，读了一些这方面的书，最近感觉可以初步回答自己的这个问题了，在此记录一下

一、架构就是设计，只是上下文不同

现在我认为，“架构”和“设计”可以认为是同义词，只是所处的层次不同，架构是较高层次上的设计，取决于系统本身的复杂度

比如说一个最简单的WEB应用，也需要考虑很多方面：分层、框架选型、使用什么容器、模块划分、模块设计等等。在这之中，分层和框架选型算是比较高层面的决定（当然现在基本每个人都会不假思索地考虑3层架构，然后上SSH），那么我认为这个就可以算是“这个系统”的架构工作了。模块划分，模块设计，就相对低层一些，可能从整个系统的角度来看，就算不上架构了

但是对于更复杂的系统，比如说由若干个子系统组成的大的业务系统，那就还需要考虑各子系统的职责分配、如何集成、部署关系等等。而具体到每个子系统，还是需要考虑分层和框架选型的，但是，完全有可能使用了不同的分层模式，选择了不同的框架。那么从整个系统的角度来看，前面说的职责分配、集成设计、部署关系，才是比较高层面的设计，在这里算是“架构设计”。而分层设计、框架选型，就是比较低层面的设计，可能就不算架构了

可以看到，“分层设计”、“框架选型”这2个设计动作，在不同的上下文（系统复杂度）下面，所处的层面就有所区别。所以我认为，“什么是架构”，要看系统本身的复杂度如何。系统的方方面面都需要设计，但是设计所处的层次，和对整个系统的重要性是不同的，处于高层次的那些设计，就是架构

二、架构有不同的视图

就像数据库中同一张表，可以有不同的视图一样，我认为架构，从不同的角度来看，也可以呈现出不同的视图

前面说了，架构是高层次的设计，需要关注很多方面。那么对于一个很复杂的系统，往往是很难从单一的角度描述清楚的

好比说一座山的地图，从登山者角度来看，会有一个路线图；从气象角度看，又会有降水分布图；从军事角度看，还有等高线图……

架构也是如此，既然架构需要关注系统的各个方面，当然也就需要不同的视图来表达

比如说，架构师要关注系统的部署方式，那么就有一个物理架构图；要关注设计怎么在开发阶段实现，就有一个开发者视图；关注各子系统的职责划分，就有一个逻辑架构图；如果统一第三方组件的选型的话，可能还有一个组件列表之类的东西。这些输出，我认为都是架构设计的不同视图，合在一起才是架构的全貌

对于比较低层面的设计，比如模块划分、模块设计，其实也可以说是架构，只是层次比站在全局角度上看低一些。所以也会有不同的视图，比如包图、类图、时序图等等，都是设计的不同角度的视图

三、大家都是架构师

所以极端点说，每个开发人员都是架构师（除了不做任何设计工作，只填充代码的纯码农之外。。）

可能有的人完成过非常简单的系统的架构（比如最常见的3层WEB应用），有的人完成过很复杂的系统架构（比如淘宝的架构师）

所以同样是架构，由于做过的系统的复杂度不同，个人的经验不同，是存在很大的差别的，只能依赖经验的积累

四、架构师的能力模型

我觉得比较厉害的架构师，应该要具备以下的“硬实力”：

1、对业务的了解。IT系统是为业务服务的，脱离了业务的架构没有意义。比如说淘宝商城，在处理并发和海量数据上，可以说是业内首屈一指，可想而知其架构是非常复杂的。但是，复杂的架构，势必大大增加了开发和维护的难度。如果淘宝根本就没有这么大业务量的话，这种复杂的架构其实就没有意义。所以架构师首先需要理解业务，理解需求，对未来的业务发展和走向有判断，才能以此为依据，输出合适的架构

2、有宽阔的知识面。知道业内的主流技术，跟上技术发展的节奏。这个能力是不言而喻的，就不用多说了

3、有实现核心代码的能力。我不知道这条对不对，只是我见过一些夸夸其谈的所谓“架构师”，谈起架构就好像一本技术词典，各种技术层出不穷；说到实现，不知道hello world写不写得出来。可能是我现在层次还不足以理解这种“架构师”，反正我觉得挺害人的。就算没这么夸张，我觉得架构师还是应该有能力实现自己设计出来的核心部分，不然就是“管生不管养”，也不太科学。或许“架构师”不是一个人，而是一个核心团队，有专人负责实现核心代码，那我觉得这种模式也是可以的

还有其他一些“软实力”，我觉得也挺重要的，比如文档写作能力、沟通能力、协调能力、英文能力等等，不过就不在本文的讨论范围里了，相信大家都各有体会

五、顺便说一下最近看到的一种分层架构

最近在研究的一个产品，用的是4层架构，我觉得很有道理

除了传统的数据层、业务逻辑层、展现层之外，该系统在业务逻辑层和展现层中间还插入了一层“接口层”

系统是分布式部署的。具体来说，数据层，业务逻辑层，接口层部署在一个进程里，以RPC的方式对外发布服务。这是闭源产品，所以不知道具体是怎么发布的服务，只能确定不是WEB SERVICE

然后展现层给浏览器提供页面，数据源就来自于服务端发布的服务（基于SDK开发）

这种架构，当然在开发、测试、部署方面都比简单的3层架构复杂很多，但是在实际场景中确实也带来了好处：

由于这个系统需要支撑非常大的浏览器并发访问，但是业务逻辑却并不复杂。所以往往是部署展现层的server有很大的负载；而部署服务端的server压力却不大。那么采用这种架构，就可以支持部署多个展现层，单个服务端的方式，在展现层之上加一层负载均衡。既能支撑并发访问，又避免部署多个服务端，造成资源浪费

另一个好处是，基于SDK，用户还可以自行二次开发一些定制的客户端，来满足特殊的需求。如果没有这层接口层的话，就很难做到这点了

以前见过另一个系统，也是类似的思路，在业务逻辑层和展现层之中，也加了一层，叫做“服务层”。但是，由于在实际场景中，并没有这种需求（并发量只有10个左右），所以就显得很多余，反而给开发带来了不必要的麻烦

不错的文章，讲的比较明了。不过话又说回来，就是再怎么牛的架构师也不可能想到所有可行的方案，也没有办法完全准确的预测每一个可行方案的结果，而且还要考虑当时的现状，还要稍微有点预见性。所以架构最后都是改了又改的。

architect 本来就是设计师的意思,英文就是从建筑业借来的,架构师不过是翻译创新而已

当初 IT 精英彰显欲太强造了个怪词,成功让架构师的概念晦涩难懂了,可惜相比之下建筑设计师还是高高在上