文章转发自: alili.tech前端
近几年,微服务架构在后端技术社区大红大紫,它被认为是IT软件架构的将来技术方向.咱们如何借鉴后端微服务的思想来构建一个现代化前端应用? 在这里我提供一个能够在产品中真正能够落地的前端微服务解决方案.git
微服务化后端先后端对比
后端微服务化的优点:
- 复杂度可控: 体积小、复杂度低,每一个微服务可由一个小规模开发团队彻底掌控,易于保持高可维护性和开发效率。
- 独立部署: 因为微服务具有独立的运行进程,因此每一个微服务也能够独立部署。
- 技术选型灵活: 微服务架构下,技术选型是去中心化的。每一个团队能够根据自身服务的需求和行业发展的现状,自由选择最适合的技术栈。
- 容错: 当某一组建发生故障时,在单一进程的传统架构下,故障颇有可能在进程内扩散,造成应用全局性的不可用。
- 扩展: 单块架构应用也能够实现横向扩展,就是将整个应用完整的复制到不一样的节点。
前端微服务化后的优点:
- 复杂度可控: 每个UI业务模块由独立的前端团队开发,避免代码巨无霸,保持开发时的高速编译,保持较低的复杂度,便于维护与开发效率。
- 独立部署: 每个模块可单独部署,颗粒度可小到单个组件的UI独立部署,不对其余模块有任何影响。
- 技术选型灵活: 也是最具吸引力的,在同一项目下可使用现在市面上全部前端技术栈,也包括将来的前端技术栈。
- 容错: 单个模块发生错误,不影响全局。
- 扩展: 每个服务能够独立横向扩展以知足业务伸缩性,与资源的没必要要消耗;
咱们什么时候须要前端微服务化?
- 项目技术栈过于老旧,相关技能的开发人员少,功能扩展吃力,重构成本高,维护成本高.
- 项目过于庞大,代码编译慢,开发体差,须要一种更高维度的解耦方案.
- 单一技术栈没法知足你的业务需求
其中面临的问题与挑战
咱们即将面临如下问题:github
- 咱们如何实如今一个页面里渲染多种技术栈?
- 不一样技术栈的独立模块之间如何通信?
- 如何经过路由渲染到正确的模块?
- 在不一样技术栈之间的路由该如何正确触发?
- 项目代码别切割以后,经过何种方式合并到一块儿?
- 咱们的每个模块项目如何打包?
- 前端微服务化后咱们该如何编写咱们的代码?
- 独立团队之间该如何协做?
后续的文章我会一一解答以上问题,一块儿挖掘前端微服务的潜力. 跳出概念,实实在在的落地到你的项目中. 未完待续 ...后端
相关文章
前端单页应用微服务化解决方案1 - 思考架构
前端单页应用微服务化解决方案2 - Single-SPAfrontend
前端单页应用微服务化解决方案3 - 模块加载器微服务
前端单页应用微服务化解决方案4 - 消息总线3d
前端单页应用微服务化解决方案5 - 路由分发cdn
前端单页应用微服务化解决方案6 - 构建与部署blog
前端单页应用微服务化解决方案7 - 静态数据共享
前端单页应用微服务化解决方案8 - 二次构建
Demo
前端微服务化 Micro Frontend Demo
微前端模块加载器
微前端Base App示例源码
微前端子项目示例源码