前言
周一是美团实习的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的需求，那么我们就需要在某个泳道上同时部署前端项目与后端服务，然后交付给产品验收。
前端部署时的泳道
其实在talos（mt部署平台）上部署时配置的swimlane，完全等价于在swimlane上部署一个后端服务，我们的前端资源就属于这个泳道，在浏览器中通过url访问我们的前端项目时就是发送http网络请求，自然就会经过nginx，然后根据泳道找对应的前端静态资源。如果通过ModHeader等插件设置了swimlane，那么自然访问对应泳道上部署的前端项目，如果没有通过插件添加swimlane，自然就访问主干链路上的前端静态资源了
（所以上面删除线划掉的部分纯属扯淡，算是最初的学习误区） 更新于2024.09.13
