确认一遍
- 对你没看错，微前端是从Golang开始
- 核心观点：所有脱离业务场景的技术讨论都是耍流氓
- 微前端实践过程中的感悟：juejin.cn/post/686082…
- 关键词：样式，事件，缓存的相互冲突，特性代码的规则方案，通信机制的建立
需求背景
- 新旧多系统集成
- 日均上xx的独立用户访问
- 跨多个业务部门合作方式
主要问题
- 前端系统多技术栈，新旧项目错综复杂，有维护了6年的jq项目，也有新加入的react项目
- 后端完全失控，虽然前端页面是多个后端系统集合体现，但是对于各个子系统状态一无所知
解决方案
- 前端区分项目复杂度提供两种模式的嵌入方式，ifream和qiankun并存，以中心底座项目为通信基座，消息适配
- 后端超级网关方案：对所有子系统服务状态等进行全链路，大方向定位追踪可视化管理，钉钉实时告警
弯路汇总
- 整体方案设计逻辑个人感觉还是没毛病的
- 技术选型还是太急于求成，本人基于nodejs,egg.js加consul实现了服务发现，动态转发等等，说白了新增或者修改一个新的微服务，可以通过修改consul的配置或者nodejs接口，轻轻松松，加多少，改多少全部都可以动态适配，无需重启ng。nodejs团队语言切合度高，劣势性能差，安全性低，环境依赖(这是当时的判断，却依然选择，为了快速实现)。性能和配置化的劣势明显(倾听运维团队的意见)，面对当前系统日均xx访问的考虑不足，配置化也是依赖egg.js的config实现对于环境场景的支撑薄弱。
- 实践方案详见juejin.cn/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 实现微服务网关对老旧项目进行前端微服务进行高性能，无依赖，可配置，可监控的深入重构
进度
- 持续开源中，功能还没写完嘿嘿!
结束
