在项目开发中,如果需求将同一套代码部署到多台服务器上,并且代码上的区别只改变后端url指向地址。
如何做这个时候需要思考有哪些解决方案:
一、初版配置
最开始按照最简单的思维方式,针对每一个后端地址进行单独打一个包,这个做法确实能解决问题,但是如果需要更新代码,那么针对每个环境每次都需要重新的打包再上传代码的动作,其实是比较耗时且不友好,如果更新上线后发现地址写错了那么就需要再次打包上传。
1、代码案例
1、首先看下vue环境配置是做的,一般在根节点目录下新建文件:.env.development
(开发环境)、.env.production
文件(生产环境) 在.env.development
(开发环境)文件下写入
js
NODE_ENV='development'
// var ACTION_PATH = "http://192.168.0.121/ysapi";
// var ACTION_PATH = "http://192.168.0.121/onestopapi";
var ACTION_PATH = "http://192.168.0.72:55559";//
在.env.production
(生产环境)文件下写入
js
NODE_ENV='production'
ACTION_PATH = "http://192.168.7.107:8080";//
//ACTION_PATH = "http://192.168.0.72:8300";
//ACTION_PATH = "http://192.168.0.72:55559";
使用调用该变量的时候,通过process.env.
的方式使用,例如下面我要封装axios请求的时候:
js
var api = axios.create({
baseURL:process.env.ACTION_PATH,//请求后端地址
timeout: 7000,//请求超时
withCredentials: true, // 是否发送 cookie
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
},
});
2、代码解释
process.env
对象是Node.js提供的一个全局对象,用于访问当前Node.js进程的环境变量。在Vue项目中,我们可以通过这个对象来获取在启动项目时设置的环境变量。在Vue项目中,我们通常会有一些配置是根据不同的环境来改变的,比如API的地址,在开发环境中我们可能会用到本地的API,在生产环境中则需要用到线上的API。
这时我们可以通过设置环境变量的方式来实现这种需求。在Vue项目中,我们可以在项目根目录下创建一个
.env
文件,然后在这个文件中设置环境变量
自此最简单的将一套代码部署在不同服务器的方案就处理了,那就是每次都去改变ACTION_PATH
值然后再重新打包部署更新上线。
二、优化配置
过一段时间,觉得刚才的那种方式太过痛苦,每次测试上线需要改变两个文件的url,有可能用错了后端环境,并且两个文件对应的开发环境url和生成环境url都是通过备注的方式来记录可能会混乱,对这个环境配置做优化。
这时看到下面一段文档内容:
在 Vue CLI 创建的项目中,
process.env.NODE_ENV
的值会根据你运行的命令自动设置。例如,如果你运行npm run serve
(或yarn serve
),那么process.env.NODE_ENV
的值会被设置为"development"
;如果你运行npm run build
(或yarn build
),那么process.env.NODE_ENV
的值会被设置为"production"
。
1、代码案例
思路设计一个配置文件,通过不同的变量管理不同的环境。利用Node.js设置的环境变量process.env.NODE_ENV
确定当前处于哪种模式(开发模式、测试模式还是生产模式)。
在src/api
文件中创建config.js
文件,文件中写
js
export default {
baseUrl: {
development: 'http://localhost:8081/muyouyu',// 开发环境
production: 'http://localhost:8080/onestop',// 正式环境
},
newbaseUrl: {
development:'http://192.168.0.72:55555',// 开发环境
production: 'http://192.168.0.72:55559',// 正式环境
},
//更多配置 ...
}
同样以刚才封装axios请求的案例:
js
import config from '@/api/config.js'
var api = axios.create({
baseURL: config.baseUrl[process.env.NODE_ENV],//请求后端地址
timeout: 7000,//请求超时
withCredentials: true, // 是否发送 cookie
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
},
});
2、代码解释
上面的案例代码分两个模块:
1、配置文件,它导出了一个对象,对象中有一个baseUrl
属性,这个属性的值也是一个对象,包含了两个属性:development
和production
。这两个属性分别对应了开发环境和生产环境的baseUrl。
2、axios请求引用上述配置文件。config.baseUrl[process.env.NODE_ENV]
这段代码的意思是,根据当前的环境变量process.env.NODE_ENV
的值(development
或production
)来获取对应环境的baseUrl。
三、最终方案
随着项目部署的环境越来越多,使用配置变量也越来越多,同时采用上面方案也没有根本上解决最开始的那问题,自此想到了我上家公司的react开发的sass平台,在public
文件夹创建一个congfig.js
文件,将配置参数都写在这个(public
文件打包编译时不会修改文件内容,会原封不动保留);在此基础上将congfig.js
的配置项挂载到浏览器window对象,页面上调用,通过window.appConfig的方式获取url。
1、代码案例
说干就干,根据刚才的思路写案例demo
第一段代码是在public
文件夹创建一个congfig.js
文件,在全局作用域内定义一个名为window.appConfig
的对象。该对象包含该应用的配置信息,例如应用名称、版本、描述、图标以及配置文件地址等信息。
javascript
window.appConfig = {
// 应用名称
appName: 'vue-admin-beautiful',
// 应用版本
appVersion: '1.0.0',
// 应用描述
appDescription: 'vue-admin-beautiful',
// 应用图标
appLogo: require('@/assets/logo.png'),
// 应用图标高清
// 配置文件地址
configBaseUrl:'https://apitest.xhsbds.com/'//动态环境
}
第二段代码是在主入口文件main.js中导入了上一段代码中定义引用的config.js文件,即应用的配置信息。
arduino
import '../public/config.js'
第三段代码是创造了一个新的 Axios 实例,然后设置了这个实例的请求拦截器。在每次实例发送请求之前,都会先进入请求拦截器。在请求拦截器中,将配置的 base URL 更新为全局配置的 configBaseUrl,也就是将请求的后端地址指向为用户自定义的地址。
javascript
var api = axios.create({
timeout: 7000,//请求超时
withCredentials: true, // 是否发送 cookie
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
},
});
// 请求拦截器
api.interceptors.request.use(
config => {
config.baseURL = window.appConfig.configBaseUrl;//请求后端地址
return config;
},
error => {
return Promise.reject(error);
}
);
2、代码解释
为什么这次的axios配置没有放在create中声明baseURL
后端路径呢?其实也可以,主要是为了方便调试,在控制台更改请求地址后,页面可以实时看到最新请求路径效果。总结来说,这三段代码将用户自定义的配置信息(包括后端地址)注入到所有的后端请求中配置更加灵活。
3、归纳总结
采用这种方式动态设置 base URL 的好处主要有以下几点:
- 灵活性:将 base URL 抽离出来作为配置,可以随时改变请求的服务器而不需要修改代码,只需要修改配置文件即可。
- 统一管理:如果项目中有大量的后端请求,统一将 base URL 作为配置进行管理,可以避免在每个请求的 URL 中都包含相同的 base URL。
- 环境切换方便:在开发过程中,常与多个服务器系统进行交互,如测试环境、预发环境、生产环境等不同环境下的服务器。将 base URL 设置在配置文件中,可以快速在这些环境间切换。
- 便于维护:项目迭代过程中,如果服务端的URL地址或者端口有变化,只需要去修改配置文件就可以了,无需搜索整个项目的网络请求去修改,节约时间并且易于维护。