系统架构第三篇之架构(上)

一、引言

架构在百科中的定义是"架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计"。看到这个定义，从中获取的有效信息不大，只知道这个很厉害，用于指导大型软件系统各个方面的设计。那何为架构呢？

自己对它的理解是"按照架子把它构建出来"，这里包含两个方面：一是架子是什么；二是如何构建出来。在架构两篇文章中回答这两个问题。

二、架构分类

大部分人谈的架构，一般是两种类型的架构：一是业务架构、二是技术架构。所以聊架构的时候，也要区分这两类，否则会迷糊，虽然在本质上的分析思路是一样，但表现出来是不一样的。做技术的人大部分喜欢谈技术架构，如Dubbo等。除了中间件团队外，大部分的还是做业务的，即使是中间件，也是服务于业务的，所以这里的架构主要偏业务架构。

架构一般分为：业务架构、技术架构、应用架构、部署架构，不同的架构关注面不一样。

业务架构：业务提供的能力，业务能做什么；

技术架构：技术领域解决问题，如存储、计算等；

应用架构：应用之间的关系；

部署架构：应用实际是怎样部署的，不同机房等。

三、何为架子

架构不止是软件开发专有的，在建筑领域也有这样的概念，很少有人全程参与大型项目的核心开发。这里以建筑为例来说明架子。架子是一种蓝图和骨架，看到这个架子就知道长什么样。比如华中师范大学在建设一个校区，有很多人投标提交自己的方案，最后公布了几个设计方案，可以看到校园设计成什么样的，从整体上就可以看出校园设计的风格。

软件可样是这样的，对业务进行理解并设计，要画出一个概貌图出来表示这个系统有哪些关键部分，通过这些关键部分组成的骨架可以看到整个系统的扭转流程。

架构一般而言关注比较大的方面，细节是涉及到详细设计这一阶段。就好比建筑一样，开始有整个房子的设计图，整个房子有几层，长、宽多少，窗户、门大概在哪里.....，后面还有详细的设计，门的高度、朝向，房屋的颜色等等。

前面说了架子是一种蓝图，一般我喜欢用盲人摸象来说明全局的重要性，它代表了一种格局和高度，如果大方向错了，就算再努力也没有用。老大在团队里要我们写技术方案设计，先就有整个的业务流程，然后当前需求涉及到这些流程中的哪些点，这样一目了然，做到改动心中有数。

那么问题来了，架子是怎么出来的呢？还是回到前面两篇文章中，系统架构前面有系统二字，那么具有系统的特性，系统是分层，所以架子的导出按照之前提到的三把斧：分解、抽象、层次特性。在下篇文章中以优惠券为例推导这个架子是怎么出来的。

四、小结

本文主要提到系统架构中的架子是什么，架子是一种蓝图和骨架，从这个架子就可以看到整个系统包含的核心内容，架子一般而言不涉及到具体的细节实现，细节实现是放到详细设计。架子是一种全局，代表了整体的方向，如果大方向出错了，即使再多的努力也是没有用的。