微前端从Golang开始 |

确认一遍

• 对你没看错，微前端是从Golang开始
• 核心观点：所有脱离业务场景的技术讨论都是耍流氓
• 微前端实践过程中的感悟：juejin.im/post/686082…
• 关键词：样式，事件，缓存的相互冲突，特性代码的规则方案，通信机制的建立

需求背景

• 新旧多系统集成
• 日均上xx的独立用户访问
• 跨多个业务部门合作方式

主要问题

• 前端系统多技术栈，新旧项目错综复杂，有维护了6年的jq项目，也有新加入的react项目
• 后端完全失控，虽然前端页面是多个后端系统集合体现，但是对于各个子系统状态一无所知

解决方案

• 前端区分项目复杂度提供两种模式的嵌入方式，ifream和qiankun并存，以中心底座项目为通信基座，消息适配
• 后端超级网关方案：对所有子系统服务状态等进行全链路，大方向定位追踪可视化管理，钉钉实时告警

弯路汇总

• 整体方案设计逻辑个人感觉还是没毛病的
• 技术选型还是太急于求成，本人基于nodejs,egg.js加consul实现了服务发现，动态转发等等，说白了新增或者修改一个新的微服务，可以通过修改consul的配置或者nodejs接口，轻轻松松，加多少，改多少全部都可以动态适配，无需重启ng。nodejs团队语言切合度高，劣势性能差，安全性低，环境依赖(这是当时的判断，却依然选择，为了快速实现)。性能和配置化的劣势明显(倾听运维团队的意见)，面对当前系统日均xx访问的考虑不足，配置化也是依赖egg.js的config实现对于环境场景的支撑薄弱。
• 实践方案详见juejin.im/post/686529…

痛定思痛从头再来

• 选型有三个大类（JAVA,nodejs，GO）
• JAVA社区完善场景支撑丰富，劣势前端团队语言瓶颈
• nodejs优势快速开发，劣势大型项目支撑力度不足
• GO优势性能优势，跨平台先天优势，类型检查，劣势团队经验不足
• 配置化可视化页面缺失

技术方案

• 语言 Golang
• 框架 gin(41.7k),vue(快速开发，页面简单)
• 注册中心 consul(跨平台，无依赖，本身基于go实现)
• 数据库 sqlite (轻量级数据库，内嵌方式，零配置，迁移方便，业务字段简单)
• 测试工具 ab.exe

效果预览

资源地址

• github:github.com/fodelf/easy…
• 设计地址：modao.cc/app/5ee1502…

总结

• 以qiankun和golang 实现微服务网关对老旧项目进行前端微服务进行高性能，无依赖，可配置，可监控的深入重构

进度

• 持续开源中，功能还没写完嘿嘿!

结束