前端中的“收口”思想与“泳道”

前端中的“收口”思想与“泳道”

前言

周一是美团实习的lastday(2023.11.20-2024.3.4),现在已经回到学校躺平了,但是实习中学习到的两个点还未整理,今天给实习收收尾简单记录一下。

前端中的“收口”思想与“泳道”

“收口”思想

比如在低代码项目中,编辑物料配置时,修改与后端进行交互的表单对象的属性的时候,需要调用changeNodeProperty(currentNode, { // 需要修改的key-value })方法而不是直接对currentNode进行赋值修改,这样其实就是对修改配置对象这个行为进行“收口”,好处是对这个方法进行逻辑修改就可以作用到所有此方法的调用处,这样肯定是牺牲了一定的开发效率,但是毋庸置疑是利于后期维护与管理的!

有了上面的思考,其实也就不难理解axios单例模式的用意了,全局共享一个axios实例,对这个实例添加拦截器,配置请求转发,取消重复请求等等逻辑作用在了所有请求中,其实整个项目的请求都在这个axios实例处得到“收口”!

大到系统设计,小到setTimeout等api都应该具备这种“收口”思想。

泳道

对服务链按需求进行分组复制,并实现逻辑、物理的隔离,使得不同需求的服务链运行在相隔的物理机器上,逻辑上如同游泳场中的泳道。

或者通俗具体一点:

一个泳道对应一个物理机器,请求某个服务时优先找指定泳道上的服务;有一个物理机器上部署了整个服务链的所有服务,这个物理机器对应的泳道就是“骨干链路”;不同泳道(包括骨干链路)上的相同服务是相互独立的,像泳道一样隔离。

前端中的“收口”思想与“泳道”

项目中所有的请求都会先到达Nginx,Nginx收到请求之后会根据请求头中的swimline字段进行请求转发,将请求转发至对应的泳道上的服务,如果没有对应泳道或者说对应泳道上没有部署目标服务,那么就会转发至“骨干链路”上的服务。

至于新建一个泳道,其实说白了就是我新建了一个部署环境,或者说新申请了一个物理机器,然后我可以在这个环境中部署服务。如果单纯是部署前端项目,那么当前泳道是啥完全不用关心,因为泳道是针对后端服务的概念。对于前端项目来讲,泳道只是一个普通的部署环境而已(可以类比为一个部署服务器)。

如上图,我们前端项目依赖于泳道-2中的服务A,那么我就要在前端项目的请求头中添加swimline=泳道-2,请求发出,Nginx收到请求后根据请求头的swimline字段转发至泳道-2上的服务A;服务A又依赖于服务B(服务A请求头中也有swimline=泳道-2,某个服务发出的请求头也携带swimline这件事可能是Nginx做的事情了),所以服务A也会优先请求泳道-2中的服务B;服务B依赖于服务C,但是泳道-2中没有部署服务C,所以Nginx最终将请求转发至骨干链路,最终使用的服务C、D、E、F都是骨干链路上的服务。

所以我们前端开发中只需要借助一些浏览器插件给请求添加请求头swimline=xxx即可使用对应泳道上的后端服务。

如果某个纯前端需求,我们只需要在自己的泳道上部署然后给产品进行验收即可(因为使用骨干链路上的后端服务即可);如果某个涉及前后端都有update的需求,那么我们就需要在某个泳道上同时部署前端项目与后端服务,然后交付给产品验收。

原文链接:https://juejin.cn/post/7343132138667016231 作者:荣达

(0)
上一篇 2024年3月7日 上午10:59
下一篇 2024年3月7日 上午11:09

相关推荐

发表回复

登录后才能评论