【架构师】-- 浅淡架构的分类

什么是架构？

说到架构，这个概念没有很清晰的范围划分，也没有一个标准的定义，每个人的理解可能都不一样。

架构在百度百科中是这样定义的：架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

我们可以理解为：架构设计的主要目的是为了解决软件系统复杂度带来的问题。

卡内基·梅隆大学的玛丽·肖（Mary Shaw）和戴维·加兰（David Garlan）在文章《软件架构介绍》（An Introduction to Software Architecture）中写到：

“When systems are constructed from many components, the organization of the overall system-the software architecture-presents a new set of design problems.”

译：随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题；当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列新的设计问题。

软件架构的核心价值，即是控制系统的复杂性，将核心业务逻辑和技术细节的分离与解耦。

架构师的职责是努力训练自己的思维，用它去理解复杂的系统，通过合理的分解和抽象，理解并解析需求，创建有用的模型，确认、细化并扩展模型，管理架构；能够进行系统分解形成整体架构，能够正确的技术选型，能够制定技术规格说明并有效推动实施落地。

架构分类

在我的认知体系中，将架构分为业务架构、应用架构、技术架构。当然也听说过数据架构，但大数据领域超出了我的知识范围，并不打算作深入的学习。

我们来理解一下业务架构、应用架构和技术架构。

在需求初期，业务的需求描述往往比较模糊。但是大方向上，业务需求是由公司战略决定的。这些战略所产生的一系统需求，需要业务架构师来进行业务落地，重点在于讲清楚这些需求背后的处理过程，定义各个业务模块的相互关系。

而应用架构、技术架构是为支撑业务架构的落地而存在的。它们的关系环环相扣，上层驱动下层，下层支撑上层。

举一个拍电影的例子。

业务架构定义了这个电影的故事情节和场景安排；应用架构定义了有哪些角色及其职责，在每个场景中，这些角色是如何互动的；技术架构确定这些角色由谁来表演，物理场景上是怎么布置的，以此保证整个拍摄能够顺利完成。

再举一个电商的例子。

一个商品业务，可能对应 3 个应用，一个前台商品展示应用、一个后台商品管理应用，以及一个商品基础服务。业务架构定义了一个下单的具体流程；应用架构定义了下单有哪些应用参与以及它们如何协作；技术架构要保障相关的应用能够处理高并发，从而保证大促顺利进行。

业务架构

说到业务啊，那就不得不提产品经理。产品经理的职责就是：告诉用户，系统长什么样子；告诉开发，他要实现什么功能。比如说，我们现在要设计一个电商系统，用户想在我们系统上买东西，一个典型的购物流程，包括商品浏览、加入购物车、下单、支付。

产品经理首先要把每个步骤具体化为页面原型。在原型中，直观的给出各个步骤的输入或输出，以及用户的操作过程，最后再把这些页面串起来，形成一个业务流程。

业务架构师要设计一个购物流程模块，里面包含商品查询、添加购物车、下单和支付接口，来分别对应流程里的 4 个业务步骤。

说起来倒是挺简单的，要实现这个购物流程，其实是考验业务架构师的功力的。

首先，业务架构师要掌握不同模块的业务和数据模型。这会同时涉及商品、购物车、下单和支付四个业务，业务架构师要同时非常清楚这四部分的数据模型和业务逻辑。

其次，这个模块要设计的足够灵活。如果一个业务领域的需求发生了变化，比如说，订单要增加一个新的状态，那么所有涉及该订单的模块都要知道这个变化，并要做出相应的调整。

下面画出了电商系统的业务架构图，仅供参考：

应用架构

应用架构就是讲清楚系统内部是怎么组织的，相互间是怎么调用的。我们熟知的应用架构有：MVC架构、分层架构、六边形架构。

从单个应用层面讲，应用架构定义了项目包的结构，比如分层应用架构，我在这篇文章《基于 start.spring.io，我实现了 Java 脚手架定制》中介绍了实现分层应用架构的过程，它的分层结构如下图所示：

从系统层面讲，应用架构定义了各个进程间的调用与交互。下面画出了电商系统的分层架构图，仅供参考：

技术架构

技术架构就是对在业务架构中提出的功能进行技术方案的实现。关键就是讲清楚系统由哪些硬件、操作系统和中间件组成，它们是如何与我们开发的应用一起配合，应对各种异常情况，保持系统的稳定可用。

这同样要求技术架构师在计算机技术方面有深厚的功力，第一大挑战就是：硬件。

从技术架构的角度，提升硬件的处理能力一般有两种方式：Scale Up 和 Scale Out。垂直扩展有物理上的瓶颈或成本的问题。受硬件的物理限制，机器的性能是有天花板的。水平扩展如何有效地管理大量的机器，硬件不是 100% 的可靠，它本身也会出问题。

第二大挑战：软件。

这里的软件，主要说的是各种中间件和系统级软件。软件在填硬件的各种坑的同时，也给系统挖了新的坑。

举个例子，Redis 集群的多节点，它解决了单节点处理能力问题，但同时也带来了新的问题，比如 Redis 数据的多副本，它解决了单台服务器故障带来的可用性问题，但同时也带来了数据的一致性问题。

下面画出了电商系统的技术架构图，仅供参考：