前端架构初识

前端架构初识

什么是软件架构

软件架构 是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。软件架构会包括软件组件,组件之间的关系,组件特性以及组件间的特性。软件架构可以和建筑物架构相比拟。软件架构是构建计算机软件,开发系统以及计划进行的基础(蓝图),可以列出开发团队需要完成的任务。——维基百科

和盖房子一样,对于软件开发来说,最初,设计出软件的总体架构蓝图,思考各个模块之间的关系,实施一系列相关的架构决策。然后,选择软件开发所需要的一系列技术栈、框架等,讨论关于应用的上线、部署等流程问题。最后,才能进入软件的开发阶段。在开发过程中,还需要保证软件的质量,才能设计出符合要求的系统。

开发人员需要怎样的软件架构?我们期望的软件架构,应该是贯穿在它被应用的生命周期里,应该包含: ​

  • 系统间的关系。明确地指出是调用还是依赖关系。
  • 系统内关系。比如通信机制。
  • 应用内架构。包含应用相关的框架、组件,并清楚表示它们之间的关系。
  • 规范和原则。指导开发人员编码和构建设计中的架构。

架构的设计

架构设计不只是一个技术工作,它包含一系列复杂的工作,其范围包括软件工程、开发实践、业务交付等相关领域。为此,在进行架构设计的时候,需要进行一系列技术及非技术相关工作。 ​

  • (1)手机利益相关这需求。倾听业务人员、项目负责人等相关者需求,进行用户访谈,收集相关的需求。
  • (2)与相应的技术人员(如开发人员、测试人员)讨论,了解架构上的潜在限制。
  • (3)寻找潜在的可行性技术方案。
  • (4)整理出功能列表中的功能性需求和跨功能性需求。
  • (5)找出会严重影响开发的风险点。
  • (6)和技术委员会、利益相关者反复确认方案(可选)。
  • (7)对架构设计进行概念证明。
  • (8)细化架构的部分实施细节。
  • (9)结合技术和业务 ,进行需求排期。

对于不同的项目来说,以上步骤都会有所不同,有的可能会忽略一些步骤,有的可能会更细,包含更多的步骤。对于大部分项目来说,技术方案往往都是现成的。所以这个过程中,最重要的事情是收集相关的架构需求,从过往经验、互联网、同事等渠道,获得一些技术方案。整合多个方案或者对方案进行改进。而需求是决定这些架构方案的细节。 ​

收集架构需求

架构并非从技术角度考虑问题,它需要从多方的利益出发,在满足利益相关者需求的同时,还要具备技术上的可实施性。所以,我们需要收集一系列资料: ​

  • 了解相关者利益。
    • 产品、业务负责人(PO)
    • 产品经理,根据架构来决定项目计划和项目人员
    • 架构师、开发人员,关心系统的构建、演讲及维护。
    • 业务分析人员,关系如何分配和安排项目的迭代计划。
    • 测试人员,设计合理的测试计划,如对系统集成部分的测试等。
    • 更高级别的人物,公司战略相关……
  • 寻找架构关注点。
    • 性能(性能指标、并发量)
    • 安全(数据安全、应对客户端和服务端攻击)
    • 平台化(是否需要作为平台承载其他系统)
    • 代码维护(开发上手难易度)
    • 用户体验
  • 明确跨功能需求。

按功能性来区分,需求可以分为功能性需求和非功能性需求。功能性需求定义了一个软件系统或者组件的功能,也是一个系统需提供的功能及服务。而跨功能性需求也是需求的一个重要组成部分,它指的是依靠一些条件判断系统运作的情形或特性,而不是针对系统特定行为的需求。这些非功能性需求一般是隐性的,往往难以直接观察得出。比如:

  • 运行质量
  • 演进质量
  • 可用性、可维护性、可变性、可伸缩性
  • 浏览器的支持范围
  • 移动设备支持的版本
  • 罗列技术风险点。
    • 技术风险
    • 第三方系统集成
    • 受限制的线上运行环境
    • 需求带来额外的技术膨胀,影响开发交付。

架构模式

架构模式也可以认为是架构风格。前端常见的架构风格有: ​

  • 分层风格。
  • MVC架构风格
  • 发布-订阅风格
  • 管理和过滤器风格

如果是后端架构,风格会更多。 ​

架构设计方法

1、架构开发方法:4+1视图法

image

  • 逻辑视图(Logical View):在设计期的模块、接口划分,职责及协奏方式等。
  • 流程视图(Process View): 在运行期运行的数据同步,如在微前端中的数据流、控制流。
  • 开发视图(Development View):在开发期的框架、库、技术选型及对应的编译。
  • 物理视图(Physical View):又称部署视图。在部署期与持续交付相关的决策。
  • 场景(Scenarios):又称用例视图,它使用一组用例或场景来说明框架。

2、架构开发方法: TOGAF 及 ADM

TOGAF: 开放组体系结构框架 (The Open Group Architecture Framework )

https://www.opengroup.org/togaf

TOGAF 是一个企业架构标准,分为如下 4个架构域:

  • 业务架构: 定义业务战略、治理方法和关键业务流程。
  • 应用架构:为将要部署的各个应用程序提供蓝图,并展示他们的交互及核心业务流程的关系
  • 数据架构:描述一个组织的逻辑、物理数据资产及数据管理资源的架构。
  • 技术架构:定义了支持部署业务、数据和应用程序服务所需的逻辑和硬件功能,他包含了IT基础设施、中间件、网络、通信、处理和标准。

在没有足够的时间和精力的情况下,很难建立一个涵盖 4 个架构域的详尽架构描述。此外,还有一套架构开发方法叫作 ADM,用于创建企业级架构。ADM一共分为8个阶段,如图: ​

image

  • A 架构愿景。设定项目的范围、约束和期望。
  • B 业务架构。开发业务架构,用于支持设定的架构愿景。
  • C 信息系统架构。开发新系统架构,用于支持设定的架构愿景。
  • D 技术架构。开发技术架构,用于支持设定的架构愿景。
  • E 机会及解决方案。为前几个阶段定义 的架构进行初步实施计划和交付改进的识别。
  • G 实施治理准备和发布架构契约,并对实施的架构进行监督,以确保实施项目符合架构的要求。
  • H 架构变更管理。 对架构变更进行持续的监控。

生成架构的产出物

  • 架构图
  • 迭代计划
  • 技术栈及选型
  • 示例代码
  • 测试策略
  • 部署方式

架构设计原则

适度设计

不做多余过度设计,只需要考虑好扩展性。因为我们不知道未来的需求会变化成什么样时,预留的设计可能是多余的,也可能会影响系统的后续扩展。相反,如果架构考虑的不够,设计不足会使架构扩展性不强。 ​

演进式

开发模式不同,软件架构的设计要求也不同。 在瀑布模式下,先设计好系统锁需要的一系列要素,进行软件的建模、详细的架构设计、文档编写,直至设计的工作完成。 在敏捷模式下,则是现有架构蓝图,实现对应架构的 PoC(概念验证)。然后再实现的过程中,基于PoC 产生的代码叠加业务代码。接着,在项目试试的过程中,不断地完善应用架构的设计,如软件建模等。

持续性

演进式指架构上一些变化,而持续性针对的是开发人员的变化。架构的持续性原则的意图是,敢于修正架构的错误部分。

  • 技能水平的持续改进。
  • 应用的持续改进。
  • 设计能力的持续提升。

如果架构上有多个可演进方向,无法做一个合适的决策,那么可以在条件更加充分的时候在做决策,而不是浪费大量的时间盲目地修改架构,那样只会造成资源浪费。——延迟决策。

前端架构发展史

最初前端是没有架构的,因为只是简单的dom操作。随后发展动态生成HTML、模板分离,前端应用开始变得复杂,诞生出了一些MVC框架,如:Backbone,Knockout 等。 ​

在2009年Node.js 出现之后,前端的软件工程不断地改善:

  • 更好的构建工具。从 Grunt/gulp 到 rollup.js、webpack、vite
  • 包管理。Bower、NPM、Yarn
  • 工程多包管理 mongorepo,如 lerna
  • 工程依赖自动化管理。如 renovate
  • 模块管理。 AMD\Common.js 规范
  • API管理。Swagger API、 Mock Server 成为标准实践,Swagger API 生成 TypeScript 代码等
  • 组件化。前端应用其实由一个个小组件组合成区块,再到页面。
  • 大前端。有前端来开发跨平台应用,如 Ionic、React Native、Flutter、electron 等。

系统变得越来越复杂,架构在前端的作用也变得越来越重要。MVC满足不了开发人员的足球,于是采用组件化架构,如 组件化+MV*。当我们为了解决跨框架,应用拆分独立,遗留系统迁移等问题时,又出现 微前端架构。

image

image

前端架构设计:层次设计

image


参考资料《前端架构:从入门到微前端》


欢迎前往原文讨论:https://github.com/giscafer/blog/issues/54

相关文章