轻架构（一）：缘起--架构的核心目标是什么

 

 

 在现在这个时代，架构变得异常复杂，也异常艰深。轻架构这个概念，也就是让架构正本清源，回归本来面目。那什么是架构的本来面目呢？

 

架构的英文是Architecture，本身是一个从建筑行业学习来的词语，用在软件设计和开发这个领域，主要是指“系统在其环境中的最高层概念”（IEEE98），架构的任务指：建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。这样的决定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

 

         用一个人类社会的事情来比喻，当然，我们也常常说到，一个公司的“组织架构”，例如我们建立了一整套从总经理、副总到部门经理、助理和普通职员的组织关系，建立了这些关系之间工作指派、工作汇报和工作总结的机制；我们把公司划分为几个不同的部门 分工协作，各个部门完成自己的工作目标，从而完成正规公司的目标。

 

         上面这段话其实体现了架构的几个基本点，第一是分层以及层次之间的关系；第二是分模块以及模块之间的关系，第三个基本点是划分好各个层次、各个模块的职责。各个模块、层次各司其职，系统良好运转，架构的作用隐含于其中。人们看得见各个层次和模块，倒是忘记了这个架构本身。

 

         在上面的类比中，我们可以看到。其实公司的目标，都是各个层次、各个部门来完成的，但是却没有任何实际问题是由架构本身来解决的，架构本身没有提供任何“真正”的价值，但是架构却又是最最关键的，一个不好的架构，使各个层次、各个部门之间相互掣肘，内耗严重，效率极差，解决什么问题也困难，达到总体目标就很难。

 

再来看软件架构，与上面的公司架构一致，它要完成一个系统的复杂度切分，架构本身不解决系统的任何问题，只是把系统的复杂度切分到不同的子系统或模块或层次中中。架构关心的是系统整体的耦合度。模块切分时的平衡、复杂度切分时是否合理。

 

之所以在这个时候提出这个概念，是因为架构这个词被用得太泛滥。架构这个概念包含了太多的内容，以至于架构师成为设计开发过程最累的角色，负担了太多太多的东西。而且，因为事情太多太杂，导致根本性的任务做的不好，今儿严重影响产品质量，产品常常变成大杂烩。所以，有必要正本清源，把纯粹架构的内容抽离出来说。

 

抽离出来之后，架构本身应该不解决任何问题域的问题，只是使问题域的每一个问题都更容易找到解决者。或者为每个问题，提供了一个寻找解决者的途径和方法，尽可能使问题都能更快速、更顺畅的找到解决者。架构为一个组织（一个软件）内部的控制传递、数据传递提供了好的通道和路线，但本身不发送任何控制和数据。

 

例如，设计房子画出了设计图，但是画图的设计师不卖建筑材料，不卖建筑工具。在一个公司内部，组织部门的人并不解决客户的问题。

 

轻架构的目标：

         （显式）

     系统层次和模块划分

         系统层次之间和模块之间的关系和通信

         维护概念完整性和一致性

         （隐式）

         架构复杂度的评估、模块复杂度的评估

         后续设计的规范

         技术选型、技术路线的选择

        

 

纯粹架构对系统后续的设计和开发的重要性是不言而喻的，这并不是说其它部分不重要。架构的重要，在于在切分系统时，维护概念完整性和概念一致性；大体上平衡的分配系统的复杂度和工作强度，使系统能够顺畅的进行设计和开发。

最最关键的是，把所谓模块的高内聚低耦合、最大限度设计和代码重用、用哪些设计模式、采用SSH还是SSI、Tomcat还是Jetty、设计共用（通用）组件内容从架构中剥离出去。不是说 不重要，而是这些与架构无关。

 

这样来做的话，架构似乎变得容易了，很多人都会这么看，其实不是这样的。这样来拆分，其实是希望架构师能够真正的处理好本职的工作。

 

架构师的本职工作是什么？有人说“设计高质量的产品”，这句话太通用，因为这是产品设计和开发的根本目标，也是团队的整体目标。而架构师在过程中所承担的最重要的任务，其一是维护产品的概念完整性和一致性。产品一个版本一个版本的前进，新特性不断加入，不断吸收新的需求，纳入新的概念，在这个过程中，保持产品始终围绕着一个或一组概念（否则产品会被演变成拼盘和大杂烩，变成一种技术元素的堆砌），实在不容易。因为这个是产品的长远利益，所以在以短平快为目标的团队中直接被无视，固然有一种无奈，但毕竟不是一种好的选择。

其二是分层和模块划分，这个会从根本上影响系统的可扩展性、可生长性，而之后的模块设计和代码，对可扩展性和可生长性的影响是很小的。当然，效率、安全性等非功能特性，都是应该在分层、分模块时要慎重和仔细考虑的。

 

这两个本职工作，其实也就是软件产品的设计开发过程中，最最核心价值的所在，最最本质的点，最最需要付出艰苦的脑力劳动的地方。是设计开发活动中最最需要花心思花时间和精力的关键点，关键中的关键。正是因为架构师很多都是百炼成钢，经验丰富，才会担当这样的重任。

 

         反过来想，为什么现代软件开发过程会被比喻成“焦油坑”？为什么设计行业内架构这个职位这么不好做？我觉得现在设计开发过程中，架构师的职位定义是含糊不清的。从人上，救火队员，项目经理、老兵等等；从事情上，开发底层接口、编写设计文档或伪码、到客户处沟通需求这些是架构师的工作职责。很少有人意识到上边提到的架构师的根本职责、本职工作。因为这个认识不到位，所以使架构师没有把“架构”这件事做好，带来的问题就是产品质量低下，可扩展、可延续、可生长特性非常差，人力资源浪费，高投入低回报。