前端架构入门
常见的架构风格
分层风格
这是最常见的架构风格,它将系统按照水平切分的方式分成多个层。一个系统由多层组成,每层由多个模块组成。每一层为上层提供服务,并使用下层提供的功能。最为人所知的分层架构应用是OSI七层模型和TCP/IP五层模型,在开发后端服务的时候得到了广泛的应用。如在采用Spring MVC开发的后端应用中,Controller层在接收后端请求时,将通过Service层向DAO(Data Access Object,数据访问对象)层请求数据,而不是直接向DAO层请求数据。
MVC架构
这种风格应用得相当广泛,它强调职责分离,将软件系统分为三个基本部分:模型(Model)、视图(View)和控制器(Controller)。由视图和控制器一起完成用户界面的功能,并设计一套变更机制,来保证用户界面与模型的一致性。它是一种常见的架构风格,在涉及图形用户界面时,往往都有它的身影,如前端应用、移动端应用等。
发布-订阅风格
这种风格又可以称为基于事件的架构风格,它是一种一对多的关系,一个对象状态发生改变时,所有订阅它的对象都会得到通知。这种架构风格带来的最大好处是,代码上的解耦。发布者不关心事件的订阅者,只需要在适当的时候发布相应的事件即可;而订阅者则依赖于事件,而非事件的发布者。在前端的日常开发中,为了解耦不同的UI组件的依赖,会经常采用这种模式。
管理和过滤器
这是一种适合于处理数据流的架构模式,它将每个步骤都封装在一个过滤器组件中,数据通过相邻过滤器之间的管道传输。最典型的管道-过滤器架构是UNIX shell的设计。在类Unix系统中,使用“|”作为管理符号,当我们需要编写复杂的Shell脚本来处理内容时,便会使用这个符号。诸如ls-l|grep.jpg,便会先执行ls-l命令,再将结果交由grep程序,查找以.jpg结尾的文件名。
它也适用于相关的数据处理场景,如我们在采用Hadoop、Spark等编写数据处理相关的代码时,便会采用这种模式来编写。如前端框架的Angular,也直接内置了管理(Pipe)系统。
架构设计方法
RUP 4 +1 视图法
逻辑视图(Logical View)
在设计期的模块、接口划分、职责及协作方式等。
流程视图(Process View)
在运行期运行的数据同步,如在微前端中的数据流、控制流等。
开发视图(Development View)
在开发期的框架、库、技术选型及其对应的编译。
物理视图(Physical View)
又称为部署视图。在部署期与持续交付相关的技术决策
场景(scenarios)
又称为例视图,它使用一组用例或场景来说明架构
架构设计原则
不多也不少
不做多余的设计,也不缺少关键部分
演进式
不断地演进以使架构适应当前的环境
持续性
长期的架构改进比什么都重要
前端架构设计:层次设计
架构设计本身是分层级的,面向不同级别的人时所展示的内容也是不一样的,不同阶段构成架构的因素是不同的,基于这个思路,架构设计可以分为四个层级。
相应的层级解释如下:
◎ 系统级,即应用在整个系统内的关系,如与后台服务如何通信,与第三方系统如何集成。
◎ 应用级,即应用外部的整体架构,如多个应用之间如何共享组件、如何通信等。
◎ 模块级,即应用内部的模块架构,如代码的模块化、数据和状态的管理等。
◎ 代码级,即从基础设施来保障架构实施。
在设计的时候,既要用自上而下的方式来设计架构,又要用自下而上的方式来完善架构。从演进式设计的角度来看,我们需要在前期设计的时候,对所有系统级架构及部分应用级架构进行技术决策,而其余部分的架构则可以在实施的过程中考虑。
微前端的技术拆分方式
从技术实践上,微前端架构可以采用以下几种方式进行:
(1)路由分发式。
通过HTTP服务器的反向代理功能,将请求路由到对应的应用上。
在这个架构中,我们只需要关注应用间的数据传递方式。通常,我们只需要将当前的用户状态,从A应用传递到B应用即可。
(2)前端微服务化。
在不同的框架之上设计通信和加载机制,以在一个页面内加载对应的应用。
前端微服务化,是微服务架构在前端的实施,每个前端应用都是完全独立(技术栈、开发、部署、构建独立)、自主运行的,最后通过模块化的方式组合出完整的前端应用。
采用这种方式意味着,一个页面上同时存在两个及以上的前端应用在运行。而路由分发式方案则是,一个页面只有唯一一个应用。
同时,我们还需要保证应用间的第三方依赖不冲突。如应用A中使用了z插件,而应用B中也使用了z插件,如果一个页面多次引入z插件会发生冲突,那么我们应该尝试去解决这样的问题
(3)微应用。
通过软件工程的方式,在部署构建环境中,把多个独立的应用组合成一个单体应用。
微应用化是指,在开发时应用都是以单一、微小应用的形式存在的,而在运行时,则通过构建系统合并这些应用,并组合成一个新的应用。
微应用化与前端微服务化类似,在开发时都是独立应用的,在构建时又可以按照需求单独加载。如果以微前端的单独开发、单独部署、运行时聚合的基本思想来看,微应用化就是微前端的一种实践,只是使用微应用化意味着我们只能使用唯一的一种前端框架。
(4)微件化。
开发一个新的构建系统,将部分业务功能构建成一个独立的chunk代码,使用时只需要远程加载即可。
(5)前端容器化。
将iframe作为容器来容纳其他前端应用。
(6)应用组件化。
借助于WebComponents技术,来构建跨框架的前端应用。
实施的方式虽然多,但都是依据场景而采用的。在有些场景下,可能没有合适的方式;在有些场景下,则可以同时使用多种方案。
微前端的业务划分方式
与微服务类似,要划分不同的前端边界不是一件容易的事。就当前而言,以下几种方式是常见的划分微前端的方式:
◎ 按照业务拆分。
◎ 按照权限拆分。
◎ 按照变更的频率拆分。
◎ 按照组织结构拆分。
◎ 跟随后端微服务划分。
因为每个项目都有自己特殊的背景,所以切分微前端的方式就不一样。即使项目的类型相似,也存在一些细微的差异。
待续。。。
《前端架构:从入门到微前端》