Introduction

javascript

软件架构设计

关于架构这个概念很难给出一个明确的定义,也没有一个标准的定义,可以理解为对系统中的实体以及实体之间的关系所进行的抽象描述。有系统的地方就需要架构,架构并非镜花水月或阳春白雪,大到航空飞机,小到一个电商系统里面的一个功能组件都需要设计和架构。发展就需要分工协作,将目标系统按某个原则进行切分,切分的原则,是要便于不同的角色进行并行工作,结构良好的创造活动要优于毫无结构的创造活动。

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口来实现。软件架构为软件系统提供了一个结构、行为和属性的高级抽象,由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系,而且指定了整个软件系统的组织和拓扑结构,提供了一些设计决策的基本原理。

软件架构的核心价值,即是控制系统的复杂性,将核心业务逻辑和技术细节的分离与解耦。架构师的职责是努力训练自己的思维,用它去理解复杂的系统,通过合理的分解和抽象,使哪些系统不再那么难懂;在工作中了解并关注实际上关系重大但未变得过载的一些关键细节和界面。架构师的角色有:理解并解析需求,创建有用的模型,确认、细化并扩展模型,管理架构。

架构模式与架构风格

软件架构设计的一个核心问题是能否使用重复的架构模式,即能否达到架构级的软件重用。也就是说,能否在不同的软件系统中,使用同一架构。当我们讨论软件架构时,常常会提及软件架构模式(Architectural Pattern)与软件架构风格(Architectural Style)。

软件架构模式往往会用于具体地解决某个具体的重复的架构问题,而架构风格则是对于某个具体的架构设计方案的命名。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式;架构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效组织成一个完整的系统。

在笔者的系列文章中,CRUD、分层架构、六边形架构、洋葱架构、REST 以及 DDD,都算是架构风格;而 CQRS、EDA、RARF、微服务等则被划分到架构模式中。

架构分类

根据企业中职责的划分,我们往往可以将软件架构,及关联的架构师划分为以下几类:

  • 业务架构/解决方案架构:了解客户/业务方的痛点,项目定义,现有环境;梳理高阶需求和非功能性需求;沟通,方案建议,多次迭代,交付总体架构。

  • 应用架构:专注于结合企业需求,定制化 IT 解决方案;大部分需要交付的工作包括总体架构,应用架构,数据架构,甚至部署架构。根据业务场景的需要,设计应用的层次结构,制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平,从而在快速的支撑业务发展的同时,在保证系统的可用性和可维护性的同时,确保应用满足非功能属性要求(性能、安全、稳定性等)。

  • 数据架构:专注于构建数据中台,统一数据定义规范,标准化数据表达,形成有效易维护的数据资产。打造统一的大数据处理平台,包括数据可视化运营平台、数据共享平台、数据权限管理平台等。

  • 中间件架构:专注于中间件系统的构建,需要解决服务器负载,分布式服务的注册和发现,消息系统,缓存系统,分布式数据库等问题,同时架构师要在 CAP 之间进行权衡。

  • 运维架构:负责运维系统的规划、选型、部署上线,建立规范化的运维体系。

  • 物理架构:物理架构关注软件元件是如何放到硬件上的,专注于基础设施,某种软硬件体系,甚至云平台,包括机房搭建、网络拓扑结构,网络分流器、代理服务器、Web 服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。