前端微服务化的探索

前端微服务化的探索

 

随着前端工程化的大行其道，现在的项目基本是通过打包工具打包部署，不过这也带来了新的问题，比如某个页面或者组件出现bug，需要修复，整个前端项目都得重新打包，重新部署，重新部署后又可能出现新的Bug，可以影响到其他的相关或者不相关的业务，又得重新打包部署，如此循环往复，以往没有前端工程化的时候，不同页面可能都是不同html或者渲染模板之类的，即使一个页面有bug就改那个页面即可，根本不可能牵一发动全身的感受，现在却不太一样，你得整个工程重新打包，又累又苦逼，关键是新发布的版本不知道又在哪里引发了其他的故障，你还得重新打包整个工程，这个循环的过程只能用恶心来表达FE同学们的感受。

 

微服务的探索

如果你以前有过开发后端臃肿的大型单体项目，然后要改这种大型单体项目的某个Bug，然后不断的影响到一些系统中的其他未知业务，这两种情况实在是太想了。好吧，现在的前端大型工程随着体量越来越大，也开始变成前端大型单体了。既然后端系统已经早早地做了这方面的探索，SOA，微服务，Severless，那前端的系统架构是不是也应该亦步亦趋的循序跟进了呢？是不是我们前端的项目也要拆份业务，拆分为不同业务的多个前端项目，然后在前端的最前端来个前端网关，然后在加个前端微服务注册中心，不同的前端项目注册到注册中心，前端网关根据注册的前端服务，控制多个微前端的路由、调用、链接过程、权限管控等等？

 

墨菲定律的Bug

如果哪个页面或组件出现bug，不用重新打包部署，只需重新部署那个微服务化的组件或者前端微服务（现在的前端工程化，其实也只不过是在重走后端工程化的旧路，从早些的C语言的过程函数到单体工程架构到微服务架构...Serverless?）有没有一种方式做好前端的不同类型业务组件的隔离并微服务化，前端有统一的前端网关，微服务化的不同服务模块注册到前端网关，前端网关通过注册信息进行统一的路由分发，跳转到不同的微服务子系统前端(Vue/React/Agl.)，同时网关可以管控权限配置，检查路由，控制分发，记录微服务跳转的链路过程，记录链路调用错误。不同的微服务系统隔离各自业务，这样即使一个微服务某组件出现Bug，只需要出现部署相应的微服务即可，其他的微服务前端系统正常提供服务支持，这样就可以解决前面每次打包牵一发而动全身的问题。当然问题可不止一个？单体项目太大、目录太多眼花缭乱、打包完体积太多、大型单体前端项目业务太多，可能很多FE同学压根都不知道自己未负责过的业务具体是怎么运作的但是却在同一个项目中，万一不小心一个手抖改坏了，最重要的是，当时并没有Bug，然后隐藏在虚空深处的墨君(墨菲定律)对故障说在最坏时候，安排个召唤师，让上次安插的Bug出来溜达溜达，好显示一下墨君的法则之力😱。好吧，这个说了这么多问题，其实当时单体后端工程也是有这些问题，不过，一直隐藏在深山修行的微哥出世，狠狠的跟墨君硬干了几架，也算是赢回了一些场子。那现在我们说说微哥的法则之力吧。

 

微哥的法则之力

那我们看看微哥在后端领域的法则之力有什么效果呢？

• 复杂度可控: 体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
• 独立部署: 由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。
• 技术选型灵活: 微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。
• 容错: 当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。
• 扩展: 单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。
   

还不错，至少在好几个方面可以限制一下墨君的领域之力，不至于让墨君在很多场景中兴风作浪，祸害广大观众。

 

微哥出山

那问题来了，如何请微哥大佬也到前端这个领域来镇镇场子呢？

再看看微哥可能会为前端领域带来什么镇压效果：

• 复杂度可控: 每一个UI业务模块由独立的前端团队开发,避免代码巨无霸,保持开发时的高速编译,保持较低的复杂度,便于维护与开发效率。
• 独立部署: 每一个模块可单独部署,颗粒度可小到单个组件的UI独立部署,不对其他模块有任何影响。
• 技术选型灵活: 也是最具吸引力的,在同一项目下可以使用如今市面上所有前端技术栈,也包括未来的前端技术栈。
• 容错: 单个模块发生错误,不影响全局。
• 扩展: 每一个服务可以独立横向扩展以满足业务伸缩性，与资源的不必要消耗。
• 微组件库：组件化其实已经可以解决一些情节的问题了，把不同业务的组件或者页面抽离为数个业务逻辑比较独立的组件库，通过多组件来解耦，即使某个组件出了问题，修改那一个组件库就行了，其他的组件库不受影响，关键是可能连某个微服务重新打包部署都可能免了，只要升级组件依赖就行了，不过组件还得重新打包。
• 链路检查：微服务化的前端，在不同微服务跳转时，可以跟踪链路调用，并把调用日志异步发送到某后端服务，根据链路调用的日志，可以实时知道哪些用户在客户端操作时，打开那个界面异常了，异常情况是什么样，这样开发就不必等到有用户反馈，某个功能用不了或者有Bug，然后在去查看和修复，链路调用日志可以把前端的所有调用情况记录的清清楚楚，实时监测异常，同时也可以就此做前端的大数据用户行为分析。
• 限流权控系统化：虽然本来在前端可以写代码进行限流控制和权限控制，但是这不是系统化、服务化的，通过微服务网关，限流、权限控制可以做到系统化，不必每个页面每个业务写各种的限流、防抖等控制，我们通过网关，可以统一的编写相应的中间件处理，而业务代码就只需要关注业务即可。
• 业务专注：不同的业务只需要专注业务即可，因为很多特殊处理，可以由微服务的中间件去承担，相应的中间件专注于处理特定的需要，而业务就专注于业务，这样业务代码量更少，出现问题的情况也更少，代码更加优雅。

令人惊讶，微哥的剑法玩的贼溜，而且都是短剑、细剑、软剑、而且是同时玩多剑，就算是某个剑，没有干到要害，还可以容错补刀，补完刀效果不错还可以站桩扩展持续输出，干完就走，走位灵活，志摩不是说过，我轻飘飘的离开，不带走一片云彩。说的不就是微哥么。毕竟墨君功力太高，喜欢找玩重剑、巨剑、大刀的大侠对干，有句古谚语怎么说的来着：阿蛮，我的大刀已经饥渴难耐了😱？