课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
我们在前几期的文章中给大家简单介绍了微服务架构的一些基础知识等内容,而本文我们就继续来学习一下,前端微服务适用场景以及优缺点分析。
适用场景
一般来说,有以下需求的项目可以考虑使用微服务:
维护时间长
维护人员多
祖传代码迁移平滑
在老项目中使用新技术
前两点描述的是项目的不可维护性,后两点描述的是技术的迁移升级成本。
那么,的场景,就是各大公司企业级的ToB项目了。
优点/价值
技术栈无关主框架不限制接入应用的技术栈,子应用具备完全自主权。
独立开发、独立部署子应用仓库独立,前后端可独立开发,部署完成后主框架自动完成同步更新。
增量升级在面对各种复杂场景时,我们通常很难对一个已经存在的系统做全量的技术栈升级或重构,而微前端是一种非常好的实施渐进式重构的手段和策略。
独立运行时每个子应用之间状态隔离,运行时状态不共享。
•简单、解耦的代码库打包、热更新都会加速。
采用微服务的架构,最重要的一点,是解决遗留系统,在不需要重写原有项目的基础下,可以使用新的技术。
实现微前端的方式
使用HTTP服务器的路由来重定向多个应用
在不同的框架之上设计通讯、加载机制
通过组合多个独立应用、组件来构建一个单体应用
iFrame。使用iFrame及自定义消息传递机制
使用纯WebComponents构建应用
结合WebComponents构建
缺点
传输内容变大重复的公共依赖,会导致最终文件体积变大。
环境差异当开发环境和生产环境差异较大时,可能会导致问题,尤其是容器本身和其他微服务中的全局样式。
运维和管理复杂性前端将会需要管理更多的仓库、工具、构建部署、更多的域。
业务价值
如果微前端只存在工程上的价值是不值得大张旗鼓去做的。--张克军
产品的组合能力
widget的产品输出能力
具体的业务价值,视领域不同,可大可小。场景是云平台,期望是对不同用户提供产品的不同组合,那么微服务的提供的平台、产品的被集成能力就非常契合。
各厂分析实现
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。