|
|
@@ -373,30 +373,31 @@ litemall是一个简单的商场系统,基于现有的开源项目,重新实
|
|
|
|
|
|
其次,需要明确的是各模块之间的关系:
|
|
|
|
|
|
- * litemall-os-api模块会包含litemall-db模块,部署在服务器中
|
|
|
- * litemall-wx-api模块会包含litemall-db模块,部署在服务器中
|
|
|
- * litemall-admin-api模块会包含litemall-db模块,部署在服务器中
|
|
|
- * litemall-wx模块部署在腾讯官方平台中,此外数据API地址指向litemall-wx-api所在服务qi地址
|
|
|
+ * litemall-os-api模块会包含litemall-core模块和litemall-db模块,部署在服务器中
|
|
|
+ * litemall-wx-api模块会包含litemall-core模块和litemall-db模块,部署在服务器中
|
|
|
+ * litemall-admin-api模块会包含litemall-core模块和litemall-db模块,部署在服务器中
|
|
|
+ * litemall-wx模块部署在微信开发者工具中,此外数据API地址指向litemall-wx-api所在服务qi地址
|
|
|
* litemall-admin编译出的静态文件放在web服务器或者tomcat服务器,此外服务器地址设置指向3中litemall-admin-api所在地址
|
|
|
|
|
|
注意
|
|
|
> * 这里litemall-os-api、litemall-admin-api和litemall-wx-api也可以选择编译成jar模式的可执行文件(因为内嵌tomcat服务器),然后直接运行。
|
|
|
-> * litemall-wx正式部署时需要设置https开头的合法域名,因此litemall-wx-api所在的服务器需要配置合适的域名和SSL证书,具体参见官方文档。
|
|
|
+> * litemall-wx部署时可以放在微信开发者工具中测试,但是上线时必须设置https开头的合法域名,因此litemall-wx-api所在的服务器需要配置合适的域名和SSL证书,
|
|
|
+> 具体参见官方文档和本项目的1.6节。
|
|
|
|
|
|
-最后,**如果项目正式部署,请一定要在以下文件中或代码中修改相应的配置。**
|
|
|
+最后,**如果项目部署,则根据开发者的部署环境在以下文件中或代码中修改相应的配置。**
|
|
|
|
|
|
1. MySQL数据库设置合适的用户名和密码等信息,同时在litemall-os-api、litemall-wx-api和litemall-admin-api模块
|
|
|
- 的`resources/application-prod.properties` 中设置正确的数据库配置信息。
|
|
|
+ 的`resources/application-dep.properties` 中设置正确的数据库配置信息。
|
|
|
2. litemall-wx模块`config/api.js`设置正确的`WxApiRoot`和`StorageApi`。
|
|
|
如果采用第三方对象存储服务,`StorageApi`指向第三方即可。
|
|
|
-3. litemall-wx-api模块`config/WeixinConfig.java`中设置所申请的微信小程序APP和微信支付相应的信息。
|
|
|
-4. litemall-os-api模块`resources/application-prod.properties` 中设置litemall-os-api服务所在的域名和端口地址
|
|
|
+3. litemall-wx-api模块的`resources/application-dep.properties` 中设置所申请的微信小程序APPID和微信支付等信息。
|
|
|
+4. litemall-os-api模块`resources/application-dep.properties` 中设置litemall-os-api服务所在的IP和端口地址
|
|
|
```
|
|
|
- org.linlinjava.litemall.os.address=http://XXX.com
|
|
|
- org.linlinjava.litemall.os.port=80
|
|
|
+ org.linlinjava.litemall.os.address=http://xxx.xxx.xxx.xxx
|
|
|
+ org.linlinjava.litemall.os.port=8081
|
|
|
```
|
|
|
如果采用第三方对象存储服务,那么litemall-os-api可以不部署,这里的配置开忽略。
|
|
|
-5. litemall-admin模块`config/prod.env.js`中设置正确的`BASE_API`和`OS_API`。
|
|
|
+5. litemall-admin模块`config/dep.env.js`中设置正确的`BASE_API`和`OS_API`。
|
|
|
如果采用第三方对象存储服务,`OS_API`指向第三方即可。
|
|
|
|
|
|
实际上,最终的部署方案是灵活的:
|
|
|
@@ -413,40 +414,6 @@ litemall是一个简单的商场系统,基于现有的开源项目,重新实
|
|
|
|
|
|
以下简单列举几种方案。
|
|
|
|
|
|
-### 1.5.1 windows下本机测试部署方案
|
|
|
-
|
|
|
-这里,我们是把window作为开发环境进行本项目的开发工作。
|
|
|
-而项目开发完毕以后,在正式部署之前,可以先进行一个简单的本机测试部署方案。
|
|
|
-
|
|
|
-首先,需要确保本地MySQL已经安装并且导入了litemall.sql数据;
|
|
|
-
|
|
|
-其次,项目打包
|
|
|
-```
|
|
|
-cd litemall
|
|
|
-mvn clean
|
|
|
-mvn package
|
|
|
-```
|
|
|
-最后,本机测试性部署三个Spring Boot应用
|
|
|
-```
|
|
|
-cd litemall
|
|
|
-java -jar ./litemall-os-api/target/litemall-os-api-0.1.0-exec.jar &
|
|
|
-java -jar ./litemall-wx-api/target/litemall-wx-api-0.1.0-exec.jar &
|
|
|
-java -jar ./litemall-admin-api/target/litemall-admin-api-0.1.0-exec.jar &
|
|
|
-```
|
|
|
-如果,能够访问以下链接的数据,则表明本地测试部署成功:
|
|
|
-```
|
|
|
-http://localhost:8081/os/index/index
|
|
|
-http://localhost:8082/wx/index/index
|
|
|
-http://localhost:8083/admin/index/index
|
|
|
-```
|
|
|
-
|
|
|
-注意
|
|
|
-> 由于这里使用`&`设置成后台运行,因此测试结束以后,开发者需要自行通过任务管理器或其他软件关闭这三个后台Spring Boot应用。
|
|
|
-
|
|
|
-### 1.5.2 简单局域网方案
|
|
|
-
|
|
|
-局域网方案,面向的是最终服务器数据和部分应用程序部署在局域网内的场景。
|
|
|
-
|
|
|
### 1.5.3 基于ubuntu腾讯云的单机云部署方案
|
|
|
单机云部署方案,面向的是服务器数据和应用部署在云主机单机中用于演示的场景。
|
|
|
|
|
|
@@ -656,7 +623,7 @@ mvn package
|
|
|
|
|
|
````bash
|
|
|
cd litemall/litemall-admin
|
|
|
-cnpm run build:prod
|
|
|
+cnpm run build:dep
|
|
|
````
|
|
|
|
|
|
此时,litemall-admin模块的dist文件夹中就是最终部署时的代码,可以先压缩,上传到云主机,再解压缩。
|
|
|
@@ -707,39 +674,47 @@ https://docs.spring.io/spring-boot/docs/1.5.10.RELEASE/reference/htmlsingle/#dep
|
|
|
http://xxx.xxx.xxx.xxx:8080/#/login
|
|
|
```
|
|
|
|
|
|
-7. 自动上传脚本
|
|
|
+#### 1.5.3.8 部署脚本
|
|
|
|
|
|
- 为了简化步骤1和步骤2,完成了deploy/util/upload.sh脚本,开发者需要设置相应的云主机IP和密钥文件路径。
|
|
|
- 该脚本会自动把当前项目不同模块下的最终部署文件复制到deploy文件夹中,然后上传到云主机。
|
|
|
- 注意:
|
|
|
- > 上传脚本没有自动做Spring Boot项目打包和Vue项目打包工作
|
|
|
+为了简化步骤1和步骤2,完成了deploy/util/upload.sh上传脚本和deploy/util/lazy.sh部署脚本,
|
|
|
+
|
|
|
+注意:
|
|
|
+> 1. 开发者需要在deploy/util/upload.sh和deploy/util/lazy.sh中设置相应的云主机登录账号和密钥文件路径。
|
|
|
+> 2. 开发者需要在deploy/util/reset.sh设置云主机的MySQL的root登录账户。
|
|
|
+> 3. 请先执行1.5.3中上述步骤,确保部署环境成功。
|
|
|
|
|
|
- 如下图所示,上传脚本自动上传deploy文件夹到云主机:
|
|
|
- 
|
|
|
- 需要指出的是,这里的upload.sh脚本是private文件夹中的文件,因为private文件夹是
|
|
|
- 在.gitignore中设置忽略,因此upload.sh脚本里面可以包含一些隐私信息,
|
|
|
- 如云主机IP和当前系统私钥文件地址,而其他内容则和deploy/util/upload.sh完全一致。
|
|
|
+* 上传脚本
|
|
|
|
|
|
- 如果开发者需要先编译项目再上传,也可以运行util/lazy.sh。
|
|
|
- 注意,运行命令必须在项目主目录中,类似如下命令:
|
|
|
- ```bash
|
|
|
- cd litemall
|
|
|
- ./deploy/util/lazy.sh
|
|
|
- ```
|
|
|
+该脚本会自动把当前项目不同模块下的最终部署文件复制到deploy文件夹中,然后上传到云主机。
|
|
|
+该上传脚本没有自动做Spring Boot项目打包和Vue项目打包工作
|
|
|
+
|
|
|
+* 部署脚本
|
|
|
+
|
|
|
+该脚本会编译项目,再上传deploy文件,最后ssh登录远程主机执行bin下面的deploy.sh脚本。
|
|
|
+
|
|
|
+注意,运行命令必须在项目主目录中,类似如下命令:
|
|
|
+```bash
|
|
|
+cd litemall
|
|
|
+./deploy/util/lazy.sh
|
|
|
+```
|
|
|
|
|
|
-### 1.5.4 分布式云部署方案
|
|
|
+注意:
|
|
|
+> 本项目的deploy文件夹以及其中的部署相关脚本只能适用于本节部署方式。
|
|
|
+> 目前灵活性较差,开发者可以参考实现自己的相关脚本,简化开发工作。
|
|
|
+
|
|
|
+### 1.5.4 集群式云部署方案
|
|
|
|
|
|
由于本项目是面向微小型企业的小商城系统,因此预期的分布式部署方案是
|
|
|
1. 专门的云数据库部署数据
|
|
|
2. 专门的云存储方案
|
|
|
3. 专门的CDN分发管理后台的静态文件
|
|
|
4. 一台云主机部署管理后台的后台服务
|
|
|
-5. 一台云主机部署小商场的后台服务
|
|
|
+5. 一台或多台云主机部署小商场的后台服务
|
|
|
|
|
|
-虽然由于环境原因没有正式测试过,但是这种简单的分布式场景应该是可行的。
|
|
|
+虽然由于环境原因没有正式测试过,但是这种简单的集群式场景应该是可行的。
|
|
|
在1.5.3节中所演示的四个服务是独立的,因此延伸到这里分布式是非常容易的。
|
|
|
|
|
|
-但是,如果需要实现互联网式分布式云部署,目前的项目架构和方案会存在很多问题。
|
|
|
+但是,如果需要实现互联网式分布式云部署,目前的项目架构和方案不支持。
|
|
|
至少每个功能模块应该是独立服务系统。此外,需要引入单点登录系统、集群、缓存
|
|
|
和消息队列等多种技术。因此如果开发者需要这种形式的分布式方案,请参考其他项目。
|
|
|
|
|
|
@@ -747,6 +722,8 @@ https://docs.spring.io/spring-boot/docs/1.5.10.RELEASE/reference/htmlsingle/#dep
|
|
|
|
|
|
这里介绍另外一种单主机单服务的方案,即四个服务打包成一个war格式的项目部署包。
|
|
|
|
|
|
+
|
|
|
+
|
|
|
和1.5.3节相比,采用这样方案的原因是:
|
|
|
1. 安装方便,是传统的web项目安装方式,在tomcat里面部署一个war项目包,即可完成安装;
|
|
|
2. 内存消耗少。在1.5.3节中四个独立的java环境消耗的内存大概1.2G多,而这里部署以后
|
|
|
@@ -768,7 +745,7 @@ https://docs.spring.io/spring-boot/docs/1.5.10.RELEASE/reference/htmlsingle/#dep
|
|
|
|
|
|
## 1.6 上线方案
|
|
|
|
|
|
-在1.5节部署方案中,我们介绍了多种部署的方案,但是实际上这些方案都不能直接用于正式环境:
|
|
|
+在1.5节部署方案中,我们介绍了多种部署的方案,但是实际上这些方案都不能立即用于正式环境:
|
|
|
1. 正式环境需要域名和HTTPS证书
|
|
|
2. 小商场的小程序端对服务器域名存在接入要求。
|
|
|
|
|
|
@@ -967,23 +944,44 @@ http://www.example.com
|
|
|
特别是`appid`要设置成开发者申请的appid。
|
|
|
|
|
|
|
|
|
-### 1.6.4 上线脚本
|
|
|
+### 1.6.4 后台服务上线
|
|
|
+
|
|
|
+后台服务上线,则开发者需要自己的线上环境在以下文件中或代码中修改相应的配置。
|
|
|
+
|
|
|
+1. MySQL数据库设置合适的用户名和密码等信息,同时在litemall-os-api、litemall-wx-api和litemall-admin-api模块
|
|
|
+ 的`resources/application-prod.properties` 中设置正确的数据库配置信息。
|
|
|
+2. litemall-wx模块`config/api.js`设置正确的`WxApiRoot`和`StorageApi`。
|
|
|
+ 如果采用第三方对象存储服务,`StorageApi`指向第三方即可。
|
|
|
+3. litemall-wx-api模块的`resources/application-prod.properties` 中设置所申请的微信小程序APPID和微信支付等信息。
|
|
|
+4. litemall-os-api模块`resources/application-prod.properties` 中设置litemall-os-api服务所在的IP和端口地址
|
|
|
+ ```
|
|
|
+ org.linlinjava.litemall.os.address=https://www.example.com
|
|
|
+ org.linlinjava.litemall.os.port=80
|
|
|
+ ```
|
|
|
+ 如果采用第三方对象存储服务,那么litemall-os-api可以不部署,这里的配置开忽略。
|
|
|
+5. litemall-admin模块`config/prod.env.js`中设置正确的`BASE_API`和`OS_API`。
|
|
|
+ 如果采用第三方对象存储服务,`OS_API`指向第三方即可。
|
|
|
+
|
|
|
+
|
|
|
+### 1.6.5 上线脚本
|
|
|
+
|
|
|
+本项目的deploy文件夹是用于
|
|
|
|
|
|
-### 1.6.5 优化
|
|
|
+### 1.6.6 优化
|
|
|
|
|
|
以下是部署方案中出现而在上线方案中可以优化的一些步骤。
|
|
|
|
|
|
-#### 1.6.5.1 卸载tomcat
|
|
|
+#### 1.6.6.1 卸载tomcat
|
|
|
|
|
|
如果部署方案中采用tomcat而8080端口访问后台,而这里配置nginx后,
|
|
|
可以直接采用80端口访问,因此tomcat可以卸载。
|
|
|
|
|
|
-#### 1.6.5.2 静态文件托管CDN
|
|
|
+#### 1.6.6.2 静态文件托管CDN
|
|
|
|
|
|
在上节中,建议采用卸载tomcat,采用nginx托管管理后台的静态文件。
|
|
|
这里可以进一步地,把静态文件托管到CDN,当然这里是需要收费。
|
|
|
|
|
|
-#### 1.6.5.3 后台服务内部访问
|
|
|
+#### 1.6.6.3 后台服务内部访问
|
|
|
|
|
|
原来后台服务可以通过域名或者IP直接对外服务,而这里采用nginx反向代理后可以
|
|
|
通过80端口访问后台服务。因此,会存在这样一种结果:
|
|
|
@@ -994,7 +992,7 @@ http://www.example.com
|
|
|
而如果取消后台服务的对外访问,这样可以保证用户只能采用安全的https协议访问后台服务。
|
|
|
同时,对外也能屏蔽内部具体技术架构细节。
|
|
|
|
|
|
-#### 1.6.5.4 nginx优化
|
|
|
+#### 1.6.6.4 nginx优化
|
|
|
|
|
|
本人对nginx不是很熟悉,而nginx还存在很多可以调整优化的部分,这里建议开发者
|
|
|
根据自己业务或架构情况优化。
|