什么是架构

本文想谈谈我个人对“架构”一词的理解。刚毕业那会，对IT行业完全不了解，只是觉得“项目经理”和“架构师”仿佛是很牛逼的。一段时间以后，基本知道项目经理是干啥的了，不过对于什么是架构师还是不太清楚，只是我心中牛逼闪闪的存在。现在感觉可以回答这个问题了，本文记录一下

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

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

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

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

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

架构有不同的视图

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

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

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

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

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

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

大家都是架构师

所以极端点说，每个开发人员都是架构师

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

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

架构师的能力模型

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

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

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

3、有实现核心代码的能力

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