专栏首页Teobler的开发日记前端架构演进 - 从单体到微前端(理论篇)
原创

前端架构演进 - 从单体到微前端(理论篇)

我们首先需要认识到每一个系统的架构都不应该是一成不变的,为了应对业务的变化,我们不应该只有重写这一个选项。但往往架构的迁移业务方不会给开发人员预留充足的时间,在短时间内平滑地将旧的架构向新的架构演进就成为了一个需要解决的问题。

本文将从一个我最近经历的项目出发,讲解我们是如何在两周时间内将一个单体前端应用演化为一个微前端应用的。

为什么有这次演进

why

不是为了解决问题胡乱上莫名其妙的解决方案就是耍流氓。微前端和微服务一样都是为了解决问题而诞生的解决方案,先看看你的项目是不是也遇到了这些问题,再决定做不做吧。

首先我们项目是一个 To B 的交付项目,是某组织为其多个部门协调合作为愿景而设想的一个系统。各个部门的工作人员为了完成各自的业务需要访问该系统下的一个或多个子系统。

在这样的业务场景下在项目开始之初后端很自然地选择了微服务作为业务解耦和降低系统复杂度的解决方案,但前端因为考虑不周加上客户比较保守并没有采取微前端的解决方案,而是以分文件目录的方式尝试区分各个子系统。

在第一个子系统顺利完成交付后我们意识到了一些问题:

  • 一期项目上线后转由公司内另外的组维护,我们在做后面的项目时难免会修改到一期或者公用的代码,两个团队势必会造成代码冲突
  • 整个系统过于庞大,我们的体量没办法吃下整个合同,可预见未来会有第三方甚至第四方公司加入交付,现在的单体应用不但会造成大量的团队代码冲突,而且限定了整个项目的技术栈,不利于后期的跨团队合作
  • 虽然我们的应用通过 AWS EKS 部署,没有宕机的烦恼,但是现在的架构无法实现独立部署,每一次子系统的部署需要对整个应用进行打包,同时如果一个应用挂了,将会影响整个系统,微前端可以在这件事上做得更好

演进发生的时机

when

架构需要发生改变往往是因为开发人员发现当前的架构没办法应对业务的发展和变化,需要改变架构来适应新的业务。

也有可能是当前业务已经复杂到一定程度,需要对架构做一些改变来对业务做一些解耦降低整个系统的复杂度,使系统更易维护。

而不管是什么原因,在真正开始改变架构时都需要在交付的过程中花费额外的时间精力。但前面我们也提到过,往往业务方不会给足够的时间来让开发人员完成架构的演进。

选择一个恰当的时机也就成为了一个重要的点。

就我们的情况而言,时机在一期项目上线后,二期项目准备阶段,于是我们在新项目的第 0 个迭代启动了前端架构演进。

而如果我们就是连两个周的时间都没有,那么就真的只能在交付的过程中加入一些 tech 卡,在别的分支上边交付边改进。

目标

objective

首先既然是架构的演进,那么就不会有完成的那一天,但是应该有一个最小的目标,只要达成了这个最小的目标,已经能解决开发过程中的主要问题,这次演进就算是达到目的了,基于此我们在演进开始前规划了相应目标:

  1. 不动基础设施,尽最大可能节省工作量,将所有应用打包后部署到同一个 nginx,将不同的应用放在不同的 folder 下,后续项目稳定后再推动客户拆分基础设施
  2. 先做最坏的打算,假如我们两个星期内完不成拆分该怎么办
    1. 保持 master 代码不动,计划后续如何在 master 代码分支上也能继续开发,同时新建分支完成代码拆分工作
    2. 保持现有 pipeline 不动,用于支持现有 master 分支代码,新建一条全新的 pipeline 适配新的应用
  3. 先只拆分整个应用的代码部分,时刻与 BA 和 后端小伙伴保持沟通,以业务形式和权限设计来指导前端如何拆分

技术选型

selection

这个部分不一定每一次演进都会有,在我们的这个案例中,因为我们需要将一个单体应用拆分成微前端,为了减少拆分的工作量,增加项目的可维护性,我们需要挑选一个合适的微前端框架来解决这个问题。

说来也巧,在做出这个决定不久,公司发布了第23期技术雷达,我们关注到了 single-spa 做为一个微前端框架已经进入到了”实验“象限。同时进入我们视野的还有以 single-spa 为基础的 qiankun。

在使用 single-spa 完成一个小demo后我甚至都没有了解 qiankun 就已经决定使用 single-spa 了,原因有以下几点:

  • 生态完备,官网的文档很详细,并且有社区和官方的一系列代码库例子,同时还有上传在油管和B站的各种科普视频
  • 已经能解决我们想要解决的所有问题,并且从各个渠道搜索来看没有致命缺陷
  • 寻求帮助响应极快,我在写 demo 时遇到了一个没法实现的需求,当晚我在官方 slack 提问,第二天一早就收到解决回复

任务拆解

tasking

遇到了合适的时机,明确了需要达成的目标,完成了选型后要做的就是开动了,但是不得不再次提醒的是,我们需要做的是平滑演进,所以最重要的步骤其实是区分各类任务的优先级,通常我们会将任务划分成以下几类:

  • 必须要在短时间内完成的任务 - 这些任务如果不在这段时间内完成可能会 block 接下来的业务开发,可能会对未来的交付产生风险
  • 可以晚点做的任务 - 这些任务不会 block 业务的开发,但是从业务和技术上来说都是应该完成的,而且越往后做这些任务所花费的资源将越多
  • 可做可不做的任务 - 这些任务往往是为了提升开发体验,不会直接影响整个应用或业务
  • 可以不用做的任务 - 这些任务可以做,但是由于各种原因不在此次计划中,可以推迟到未来时机成熟后完成

总结

在日常开发过程中,我们需要站在一个高位往前看,确认现在的架构是否能支撑未来的业务形式和变化,及时计划架构调整和演进。

最重要的是,大多数架构的演进都是在时间不允许的情况下开始的,这时候我们需要对整个演进有一个计划,对所有的任务排列优先级,先做最重要的那一部分,不重要的延迟决定,然后舍弃一些东西。

另一件重要的事情是千万不要在这个过程中自己给自己加戏,作为开发人员,大家都想把每一个技术改进做到最好,但是给自己加戏的后果往往就是啥都想做好但是最后啥也没做好。

成功交付的前提是平滑演进。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 从微前端聊聊架构演进

    就目前来看,微前端已经不是一个新话题了。随着越来越多的公司的深入研究,当前也提出了很多的解决方案。不过本文不是想要来介绍微前端,更想介绍项目如何一步步到达微前端...

    ConardLi
  • 前端架构--从入门到微前端

    本书围绕前端架构的实施,从基础的架构规范,到如何设计前端架构,再到采用微前端架构拆分复杂的前端应用。

    奋飛
  • 《前端架构:从入门到微前端》目录

    本书是一本围绕前端架构的实施手册,从基础的架构规范,到如何设计前端架构,再到采用微前端架构拆分复杂的前端应用。本书通过系统地介绍前端架构世界的方方面面,来帮助前...

    Phodal
  • 从单体架构到微服务架构演进

    随着互联网的发展,互联网企业的业务也在不断的飞速发展,进而导致系统的架构也在不断的发生着变化。总体来说,系统的架构大致经历了:单体应用架构—>垂直应用架构—>分...

    常见_youmen
  • 【架构拾集】前后端分离演进:不能微服务,那就 BFF 隔离

    现有的绝大多数软件系统,都将在未来某一刻成为遗留系统,只是时间跨度不一样。好的系统,拥有好的设计,并在其生命周期里不断地演进。但是没有一个设计能抵抗住时间,以及...

    不知雨
  • 介绍一个架构新词-BFF(这个和微服务也有关系)

    本篇介绍一个概念BFF,Backend-For-Frontend,结合几篇参考文章,从不同的角度理解BFF的发展来源和实际作用。

    needrunning
  • 微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)

    对于IM系统来说,如何做到IM聊天消息离线差异拉取(差异拉取是为了节省流量)、消息多端同步、消息顺序保证等,是典型的IM技术难点。

    JackJiang
  • Netty干货分享:京东京麦的生产级TCP网关技术实践总结

    京东的京麦商家后台2014年构建网关,从HTTP网关发展到TCP网关。在2016年重构完成基于Netty4.x+Protobuf3.x实现对接PC和App上下行...

    JackJiang
  • IM开发基础知识补课:正确理解前置HTTP SSO单点登陆接口的原理

    一个安全的信息系统,合法身份检查是必须环节。尤其IM这种以“人”为中心的社交体系,身份认证更是必不可少。

    JackJiang
  • 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

    IM App 是我做过 App 类型里复杂度最高的一类,里面可供深究探讨的技术难点非常之多。这篇文章和大家聊下从移动端客户端的角度所关注的IM消息可靠性和送达机...

    JackJiang
  • 微信朋友圈千亿访问量背后的技术挑战和实践总结

    微信朋友圈包括图片和视频两套业务架构组成,朋友圈图片的特点是请求量大、消耗计算资源较多,视频则主要消耗带宽。

    JackJiang
  • 新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践

    随着社会的发展、互联网技术的进步,以前的大型机服务端架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了,替代它的就是当下最火的互联网分布式架构。

    JackJiang
  • 演进中的架构之无服务时代

    人们研究分布式架构,最初是由于单台机器的性能无法满足系统的运行需要,尽管后来架构演进过程中,容错能力、技术异构、职责划分等各方面因素都成为架构需要考虑的问题,但...

    TVP官方团队
  • 前端规划:我的 2021 前端技术战略

    整体来看,从大的趋势上没有太大的变化。这里并不考虑某些特定的技术,而是从总体上(战略)层面来看待问题。所以,就有了这么几个点:

    Phodal
  • IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议

    IM应用从服务端数据的角度来看,它是一种很特殊的应用场景,抛开基础数据、增值业务和附属功能不谈,单从IM聊天工具的立身之本——聊天数据来说,理论上是不需要在服务...

    JackJiang
  • 微信七年回顾:历经多少质疑和差评,才配拥有今天的强大

    不知不觉,微信已经诞生七年了。 从第一版到现在,微信的演变史,很像一部创业史,很好地诠释了创业者能经得起多少质疑和差评,才配拥有多大的成功。

    JackJiang
  • 京东京麦商家开放平台的消息推送架构演进之路

    京麦实时消息推送是京东的京麦商家开放平台的核心组成部分。从消息源到消息中心再到触达用户,以及最终根据消息协议呼起操作页面,京麦实时消息推送是一个完整且健康的生态...

    JackJiang
  • 【原创】新手入门一篇就够:从零开发移动端IM一、前言 二、读完本文的收获三、题外话四、网络编程理论准备五、网络编程基础实践六、IM到底该用UDP还是TCP协议?七、IM的数据通信格式选型八、移动端IM

    IM发展至今,已是非常重要的互联网应用形态之一,尤其移动互联网时代,它正以无与论比的优势降低了沟通成本和沟通代价,对各种应用形态产生了深远影响。

    JackJiang
  • IPv6技术详解:基本概念、应用现状、技术实践(下篇)

    在上篇《IPv6技术详解:基本概念、应用现状、技术实践(上篇)》,我们讲解了IPV6的基本概念。

    JackJiang

扫码关注云+社区

领取腾讯云代金券