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

时间:2024-04-17 07:13:43

什么是架构?

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

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

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

卡内基·梅隆大学的玛丽·肖(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 数据的多副本,它解决了单台服务器故障带来的可用性问题,但同时也带来了数据的一致性问题。

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