未来,仅凭几个前台工程师,就能 hold 住一家企业吗?

作者 : 开心源码 本文共2673个字,预计阅读时间需要7分钟 发布时间: 2022-05-13 共150人阅读

微前台架构旨在处理单体应用在一个相对长的时间跨度下,因为参加的人员、团队的添加,从一个普通应用演变成一个巨石应用(Frontend Monolith),随之而来的应用不可维护问题。这类问题在企业级 Web 应用中尤为常见。今天,我们就来聊聊拥抱云时代的前台开发架构:微前台。

微前台的价值

目前提供的很多商业化产品和服务,本质上是对外提供「能力」,普惠中小企业。目前,能力输出主要是通过 OpenAPI,用以集成到企业自己的业务场景中,这里主要处理的还是企业底层的能力问题——无需雇佣算法工程师,即可以拥有语音、图像识别等能力。安全也是一样,不需要找安全专家,普通的工程师即可以通过控制台高效地解决各种安全事件。

但是,随着云技术不断的下沉,与产业结合的越来越紧密,OpenAPI 唯有把粒度做得越来越细,才能满足各种各样的业务场景,但同时企业侧的学习成本和开发复杂度自然就上去了。控制台做为管(理)控(制)这些能力的工具,目前也只能算是「标品」,必需为了满足不同体量、不同业务特点的需求,灵活地组合和部署,就像是客户自己开发的一样。

综上所述,微前台的价值有 3 点:

1、技术栈无关 主框架不限制接入应用的技术栈,子应用具有完全自主权。

2、独立开发、独立部署 子应用仓库独立,前后台可独立开发,部署完成后主框架自动完成同步升级。

3、独立运行时 每个子应用之间状态隔离,运行时状态不共享。

微前台架构旨在处理单体应用在一个相对长的时间跨度下,因为参加的人员、团队的增多、变迁,从一个普通应用演变成一个巨石应用(Frontend Monolith)后,随之而来的应用不可维护的问题,这类问题在企业级 Web 应用中尤其常见。

微前台的问题域

简单地说,搞微前台目的就是要将产品原子化(跟原子化的 OpenAPI 一个道理),再根据用户业务场景组合。每个功能模块能单独迭代,自由集成当然好,但维护成本怎样控制。怎样调试、公共组件版本控制、众多同窗微应用之间怎样“和谐相处”等等。微前台并非只是处理在页面上异步加载一个模块就完事了,更多的是将改造引发的一系列问题需要通过体系化的方案处理,否则就变成反生产力工具。

首先必需明确微前台不是框架、不是工具/库,而是一套架构体系,它包括若干库、工具、中心化治理平台以及相关配套设备。

微前台包括 3 部分:

微前台的基础设备。这是目前探讨得最多的,一个微应用如何通过一个组件基座加载进来、脚手架工具、怎样单独构建和部署、怎样联调。

微前台配置中心:标准化的配置文件格式,支持灰度、回滚、红蓝、A/B 等发布策略。

微前台的可观察性工具:对于任何分布式特点的架构,线上/线下治理都很重要。

微前台具体要处理好的 10 个问题:

1、微应用的注册、异步加载和生命周期管理;

2、微应用之间、主从之间的消息机制;

3、微应用之间的安全隔离措施;

4、微应用的框架无关、版本无关;

5、微应用之间、主从之间的公共依赖的库、业务逻辑(utils)以及版本怎样管理;

6、微应用独立调试、和主应用联调的方式,快速定位报错(发射问题);

7、微应用的发布流程;

8、微应用打包优化问题;

9、微应用专有云场景的出包方案;??

10、渐进式更新:用微应用方案平滑重构老项目。

相信大家能够通过微前台三大组成部分和要处理的 10 个问题,能够有一个大概的了解。

针对中后端的应用处理方案

中后端应用因为其应用生命周期长(动辄 3+ 年)等特点,最后演变成一个巨石应用的概率往往高于其余类型的 web 应用。而从技术实现角度,微前台架构处理方案大概分为两类场景:

单实例:即同一时刻,只有一个子应用被展现,子应用具有一个完整的应用生命周期。通常基于 url 的变化来做子应用的切换。

多实例:同一时刻可展现多个子应用。通常使用 Web Components 方案来做子应用封装,子应用更像是一个业务组件而不是应用。

行业现状

传统的云控制台应用,几乎都会面临业务快速发展之后,单体应用进化成巨石应用的问题。为理解决产品研发之间各种耦合的问题,大部分企业也都会有自己的处理方案。针对国内外几个著名的云产品控制台,做过这样一个技术调研:

MPA 方案的优点在于 部署简单、各应用之间硬隔离,天生具有技术栈无关、独立开发、独立部署的特性。缺点则也很显著,应用之间切换会造成浏览器重刷,因为产品域名之间相互跳转,流程体验上会存在断点。

SPA 则天生具有体验上的优势,应用直接无刷新切换,能极大的保证多产品之间流程操作串联时的流程性。缺点则在于各应用技术栈之间是强耦合的。

那我们有没有可能将 MPA 和 SPA 两者的优势结合起来,构建出一个相对完善的微前台架构方案呢?

jsconf china 大会上,ucloud 的同学分享了他们的基于 angularjs 的方案(单页应用“联邦制”实践),里面提到的 “联邦制” 概念很贴切,可以认为是早期的基于耦合技术栈的微前台架构实践。

微前台架构实践中的问题

可以发现,微前台架构的优势,正是 MPA 与 SPA 架构优势的合集。即保证应用具有独立开发权的同时,又有将它们整合到一起保证产品完整的流程体验的能力。

这样一套模式下,应用的架构就会变成:

Stitching layer 作为主框架的核心成员,充任调度者的角色,由它来决定在不同的条件下激活不同的子应用。因而主框架的定位则仅仅是:导航路由 + 资源加载框架。

云时代的前台开发模式

前台开发从 PC 时代到移动时代,从刀耕火种的原始运维到云计算时代,回顾起来,我们会发现——开发模式跟时代背景真是密不可分。前台奋斗 20 年才把页面写好,而现在又变成「切页面」了,只是此「切」非彼「切」。云时代的开发模式注定是「碎片化」的,开发是面向模块的,而页面只是一种组合场景,一种运行时容器。

我想,未来的产品开发主要时间是在「编排」——编排服务、编排逻辑、编排组件、编排访问策略、编排流程。到了云时代,一家企业只需招几个前台工程师即可以了,兼顾开发和运维、资产一律上云,运维任务通过控制台就能完成。开发借助 Serverless 和编排工具就能实现无服务端。在未来,无论是前台工程师还是全栈工程师,都将不复存在,应该叫端到端(F2E -> E2E)工程师了。

我目前是在职前台开发,假如你现在也想学习前台开发技术,在入门学习前台的过程当中有遇见任何关于学习方法,学习路线,学习效率等方面的问题,你都可以申请加入我的前台学习交流裙:前面:603 中间:985 最后:993。里面聚集了少量正在自学前台的初学者,裙文件里面也有我做前台技术这段时间整理的少量前台学习手册,前台面试题,前台开发工具,PDF文档书籍教程,需要的话都可以自行来获取下载。

说明
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » 未来,仅凭几个前台工程师,就能 hold 住一家企业吗?

发表回复