继服务端微服务化了,前端微服务-爱 • 范儿

中台建设完成后,通过微服务实现了后端应用的解耦,提高了中台应用的弹性伸缩能力。但由于微服务拆分,也会导致项目团队和服务的碎片化,给前端项目集成带来一定的复杂度。

微服务架构通常采用前后端分离方式,中台服务通过 API 网关对外发布,单体应用拆分后一个前端项目可能会面对多个中台微服务项目。前端开发人员犹如维修电工一样,将面对成千上万中台团队开发出来的 API 接头,如何正确的连接和拼装,并且保证不出错,不是一件很容易的事情。而当中台 API 出现变更时,又如何通知所有受影响的前端项目团队同步调整和版本协同发布,需要的沟通成本相信也不小。

如何降低前端集成的复杂度?做到后端解耦,前端聚合?

微服务单一职责和共享原则将前端进行拆分和组合。从功能垂直的角度,将微前端与中台微服务进行集成和组合,形成从前端到后端可独立开发、测试、部署和运维的,领域功能自包含的业务单元。

前端页面通过微前端加载器,利用页面路由和动态加载等技术,实现前端集成主页面与微前端的“拼图式”开发。前端集成项目团队只需关注前端整体风格、微前端之间的数据交互和页面路由等内容,不涉及前端与中台之间以及中台与中台之间的 API 集成,从而降低集成过程中的技术敏感度、团队沟通成本和集成复杂度,提高交付效率和用户体验。

微前端概述

微前端概念是 ThoughtWorks 在 2016 年提出来的,它将微服务理念扩展到前端开发,解决中台微服务化后,前端由于仍为单体而存在的逻辑繁杂和臃肿的问题。微前端是按照前端设计方法在前端同时构建多个可以独立部署、完全自治、松耦合的页面组合,其中每个组合只负责特定的 UI 元素和功能。

微前端与微服务都是希望将单体应用,按照一定的规则拆分为多个可以独立运行、独立开发、独立部署、独立运维的微服务或者页面聚合,从而满足业务快速变化及分布式多团队并行开发的需求。

微前端除了可以实现前端页面的解耦外,还可实现前端页面的复用,做到“一次开发,多端复用”,这也与中台服务共享理念是一脉相承。

从单体前端到微前端

传统的软件项目往往采用单体式架构,前端往往由一个团队创建并维护一个 Web 应用程序,通过 API 网关从微服务调用服务。随着时间的推移,前端往往会越来越臃肿,越来越难维护。

随着 5G 技术的应用,企业活动将进一步移动化和线上化,过去企业的通常做法是为不同的应用开发出很多独立的 APP。但是用户来并不想装那么多 APP!

为了提高用户体验,实现统一运营,很多企业开始缩减 APP 的数量,通过一个 APP 集成所有应用功能。试想如果将企业内所有前端页面、流程设计以及前端与后端集成的工作都交给前端项目,将原来独立和分散的应用,展示在一个巴掌大的手机屏幕上。前端项目将会面对无数的中台项目和成千上万不太熟悉的 API 接口,这绝对会是一场灾难。

相对互联网企业而言,传统企业的渠道应用更多样化,有面向内部人员的柜台类应用、面向外部客户的互联网电商及移动 APP 类应用,还有面向商业生态圈的第三方 API 集成。由于渠道的差异,传统企业前端设计将会更多样化和复杂化。

传统企业在实施中台战略时,为满足前端和中台多渠道共享和复用,部分场景还应有别于阿里巴巴的中台战略。传统企业除了要像阿里巴巴一样进行通用共享服务(主要提供共享 API)的中台化建设外,还需要对核心专属业务(除 API 外,还存在大量面向用户的页面)进行中台化建设,以满足不同渠道的业务复用的需求。

继服务端微服务化了,前端微服务-爱 • 范儿

从单体前端到微前端

如何实现前端复用,降低前端集成的复杂度?

在前端设计时,我们可以参考微服务设计方法,遵循单一职责和共享原则,按照领域模型和微服务边界,将前端页面进行拆分和组合形成微前端,与中台微服务组合成业务单元。

业务单元定义: 在前后端分离架构模式下,微前端页面与中台微服务共同组成一个业务单元。在同一个业务单元内,从前端页面、中台微服务到后端数据可以独立开发、测试、部署和运维,在业务单元内自包含完成中台领域内的部分或全部业务功能。

项目职责和系统边界
  1. 前端项目主要负责前端页面的集成、页面风格设计和流程控制,以及与微前端集成相关的微前端加载、微前端注册、页面路由以及数据共享。
  2. 后端中台项目负责业务单元内中台微服务以及微服务对应微前端开发和集成。

通用和专属中台项目既面向第三方生态圈提供 API 服务,也面向前端集成主页面提供微前端页面复用。微前端和中台微服务组合成业务单元为多渠道业务提供从前端到后台的页面和业务逻辑复用。在面向多渠道业务页面复用时,微前端需要做好页面风格适配,以满足不同渠道界面风格的要求。

通过职责分工和应用边界的清晰划分,前端项目专注于微前端集成,后端项目专职做好本业务领域内中台微服务开发和微前端集成,确保领域内前端页面和后端业务逻辑作为一个业务单元整体高可用。

由于微前端和微服务之间的 API 集成已由中台项目完成,前端项目可基于微前端实现拼图式开发,在实现前后端复用的同时,大大降低前端集成复杂度。

微前端与微服务组合的几种形态

微前端与微服务可以有多种组合方式,以实现不同的业务目标。

一个虚框内微前端、中台微服务共同组成一个业务单元(如下图)。虚框内组件可以按照业务单元分前端和后端进行独立部署。

微前端页面包括业务操作必需的页面要素,不含页面导航等要素,页面导航功能位于前端集成主页面内。

微前端页面稍加改造就可以完成简单的单一场景业务,也可根据页面路由动态加载到前端集成主页面完成复杂组合场景业务。

继服务端微服务化了,前端微服务-爱 • 范儿

微前端与微服务的组合主要有以下几类形式。

  • 单一类微前端:一个微前端和一个中台微服务组成一个业务单元。微前端完成业务单元内页面流程和前端操作,中台微服务完成后端业务逻辑,业务单元功能独立且自包含。微前端可按照页面路由动态加载至前端集成主页面。
  • 组合类微前端:一个微前端与多个中台微服务组成业务单元。微前端通过对多个中台微服务进行服务编排和组合,完成业务单元内较复杂的页面流程和前端操作。业务逻辑由后端多个微服务组合完成,如:可由专属业务中台与通用中台微服务组合,也可由同一领域内多个微服务组合。在微前端设计时,微前端对应的组合微服务的数量要均衡考虑,否则很容易将微前端开发成单体前端。同时业务单元的领域边界要清晰,避免由于功能交叉而导致单元与单元之间的耦合,影响项目团队职责边界,进而影响到部署、测试以及运维等。
  • 通用共享类微前端:一个微前端与一个或多个通用中台微服务组成共享类业务单元。通用共享类微前端一般通过前端集成主页面,以共享页面的模式与其他微前端页面组合,共同完成业务流程。该类微前端通常对应通用中台共享类微服务。

微前端是前端建设的一个非常重要的方向和关注点,通过微前端的集成模式可以减轻系统开发的复杂度,降低前端集成的难度。它的主要价值和意义如下:

  1. 前端集成简单:前端项目只需关注前端集成主页面与微前端的集成,不涉及到 API 集成和中台技术实现细节,可真正实现模块化集成,实现拼图式的开发,降低前端集成的复杂度和成本。
  2. 项目职责专一:中台项目从数据库、中台到微前端界面端到端地完成领域逻辑功能开发,确保领域业务单元内从前端到后端可用。由于团队职责专一,项目成员都熟悉团队内的业务和技术,从而降低开发过程因为沟通和集成出问题的风险。
  3. 隔离和依赖性:每个团队都有自己的关注点,各关注点边界清晰,相互隔离,风暴都在茶壶内。业务单元在代码、逻辑和物理边界都是隔离的,降低应用之间的依赖性。在出现问题时可实现快速问题定位和修复,并可将风险控制在一个业务单元内,不会影响其他业务单元的正常运行。版本发布过程中不会影响其它业务单元的正常运行。
  4. 降低沟通和测试成本:一个中台项目团队从前端页面到后端中台业务逻辑,实现从开发、测试、集成和部署的全流程和全生命周期管理,降低前后端集成的测试和沟通成本。
  5. 更敏捷的发布:由于应用之间的隔离和依赖性降低,每一个小的变化都控制在业务单元内,项目团队可以独立按照自己的步调进行迭代开发,实现更快的发布周期。
  6. 降低技术敏感性:由于前端项目主要关注微前端的集成和前端技术,屏蔽了前端对中台技术的要求,从而降低了前端项目技术的敏感性。在降低前端集成复杂度的同时,中台项目可以更便捷的选择和尝试更多更合适的技术和架构,实现架构的演进。
  7. 高度复用性:微前端和业务中台都有高度的复用性。微前端可快速按需加载到前端集成主页面,或将微前端直接发布成 APP,实现快速发布。某些场景一个微前端就是一个 APP 应用。