近几年,微服务架构在后端技术社区大红大紫,它被认为是IT软件架构的未来技术方向.我们如何借鉴后端微服务的思想来构建一个现代化前端应用?
在这里我提供一个可以在产品中真正可以落地的前端微服务解决方案.
微服务化后端前后端对比
后端微服务化的优势:
- 复杂度可控: 体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
- 独立部署: 由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。
- 技术选型灵活: 微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。
- 容错: 当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。
- 扩展: 单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。
前端微服务化后的优势:
- 复杂度可控: 每一个UI业务模块由独立的前端团队开发,避免代码巨无霸,保持开发时的高速编译,保持较低的复杂度,便于维护与开发效率。
- 独立部署: 每一个模块可单独部署,颗粒度可小到单个组件的UI独立部署,不对其他模块有任何影响。
- 技术选型灵活: 也是最具吸引力的,在同一项目下可以使用如今市面上所有前端技术栈,也包括未来的前端技术栈。
- 容错: 单个模块发生错误,不影响全局。
- 扩展: 每一个服务可以独立横向扩展以满足业务伸缩性，与资源的不必要消耗；
我们何时需要前端微服务化?
- 项目技术栈过于老旧,相关技能的开发人员少,功能扩展吃力,重构成本高,维护成本高.
- 项目过于庞大,代码编译慢,开发体差,需要一种更高维度的解耦方案.
- 单一技术栈无法满足你的业务需求
其中面临的问题与挑战
我们即将面临以下问题:
- 我们如何实现在一个页面里渲染多种技术栈?
- 不同技术栈的独立模块之间如何通讯?
- 如何通过路由渲染到正确的模块?
- 在不同技术栈之间的路由该如何正确触发?
- 项目代码别切割之后,通过何种方式合并到一起?
- 我们的每一个模块项目如何打包?
- 前端微服务化后我们该如何编写我们的代码?
- 独立团队之间该如何协作?
后续的文章我会一一解答以上问题,一起挖掘前端微服务的潜力.
跳出概念,实实在在的落地到你的项目中.
未完待续 ...
