ruoyi-cloud的执行流程分析
前端登录的时候，会发出
localhost:1024/dev-api/auth/login
的请求，该请求经过vue框架的proxy后，其实是去访问localhost:8080，这个要看一下ruoyi-ui中的vue.config.js中的proxy模块是咋写的。
然后再看后台代码ruoyi-gateway的bootstrap.yml文件中的server.port=8080，说明这个前端请求是先到了gateway模块的。
然后在gateway模块的配置中发现/auth/**的请求应该发送到lb://ruoyi-auth模块，于是该请求被转发到了ruoyi-auth模块。
去ruoyi-auth模块，果然看到了有处理/login的方法。
接着我们需要重点看一下这个login方法的处理流程。
下面ruoyi-auth模块中TokenController的login方法的源代码：
可以看到login方法调用了remoteUserService对象的getUserInfo方法。那么remoteUserService对象是怎么来的呢？
我们看一下RemoteUserService的源代码，发现RemoteUserService有一个@FeignClient的注释，说明其实在调用remoteUserService的方法时，会被feign自动转发到ruoyi-system模块中去，比如刚才login方法中调用的getUserInfo方法，其实是去调用了ruoyi-system的/user/info/{username}方法了
所以一个简单的/login方法，是先第一步请求了gateway模块，然后gateway模块根据nacos中的配置知道要把这个/auth/**开头的请求转发给auth模块，auth模块交给了login方法去处理，然后login方法其实是调用了ruoyi-system中的方法去实际处理的。
-------------------------------
同理，分析一下http://localhost:1024/dev-api/system/menu/getRouters这个请求的转发路径。
首先localhost:1024是先去访问vue的，vue前端框架自带的proxy转发到了localhost：8080
于是请求变成了http://localhost:8080/system/menu/getRouters
8080是后台的gateway模块监听的地址，该模块会读取nacos中的路径规则来转发请求，我们去nacos中的gateway的配置中可以看到如下内容：
这个predicates会去预判path是不是符合/system/**的规则，匹配的话就会把请求转发给lb://ruoyi-system，而lb://ruoyi-system代表的含义就是均衡地将请求发送给注册中心的名为ruoyi-system的服务。
由于ruoyi-system这个名字的微服务是由后台代码ruoyi-system模块启动带来的，所以请求会被转发给这个模块的controller去处理。
所以下一步就是去看ruoyi-system模块的SysMenuController.java的代码，应该能看到处理/getRouters的方法
不出所料，果然是在SysMenuController.java文件的getRouters的方法中看到了如何处理的。
---------------------
至于http://localhost:1024/dev-api/system/user/getInfo这个请求，和上面分析的一样一样的，就不具体展开讲了。
后续的其他所有的请求其实也都是类似的一个处理过程。
总结一下：
就是浏览器发起的请求先到vue框架，vue框架自带的proxy会把1024端口或者80端口转为后台的端口，所以我们在浏览器看到的地址是前端的地址而看不到后端具体请求的地址的。
然后vue框架代为请求经过转换后的地址，在这篇文章中是localhost:8080地址。
8080是gateway模块监听的地址，gateway模块中再去nacos获取spring.cloud.gateway对应的路径映射规则。如下图所示，nacos的配置是如何被读取到gateway中来的：
紧接着就是到auth或者直接到system模块，到auth模块的，其实后续auth也会通过feign来访问system或者其他模块的微服务的。
