源宝导读：微软跨平台技术框架—.NET Core已经日趋成熟，已经具备了支撑大型系统稳定运行的条件。本文将介绍明源云ERP平台从.NET Framework向.NET Core迁移过程中的实践经验。
一、背景
随着ERP的产品线越来越多，业务关联也日益复杂，应用间依赖关系也变得错综复杂，单体架构的弱点日趋明显。19年初，由于平台底层支持了分应用部署模式，将ERP从应用子系统层面进行了切割分离，迈出了从单体架构向微服务架构转型的坚实一步。不久的将来，ERP会进一步将各业务拆分成众多的微服务，而微服务势必需要进行容器化部署和运行管理，这就要求ERP技术底层必须支持跨平台，所以将现有ERP系统从.NET Framework迁移到 .NET Core平台势在必行。
前面我介绍了ERP的迁移和调度服务的.NET Core改造过程，当所有的代码已经就绪的时候就要开始考虑发布和部署了。本篇将介绍ERP和周边服务在常见环境下的部署模式。
二、Framework版本的发布
原始的Framwork的发布使用的是编译后拷贝文件的方式进行发布，基本步骤如下：
修改版本号；
nuget还原解决方案；
调用MSBuild命令编译；
编译前端脚本；
拷贝文件；
打包成压缩包；
按需推送给客户。
这其中有一些不合理的地方：
修改版本好是使用一个控制台的程序进行修改,可以用脚本替代；
使用直接使用拷贝文件方式有多余文件,这样在最后一步拷贝文件时候需要排除更多文件；
最后拷贝文件使用的是程序方式进行拷贝,可以用脚本替代。
三、Core版本一般的发布流程
在一般的Core版本中只用调用dotnet publish 进行发布即可，如果要使用Framework中使用MSBuild命令进行发布的话参数非常复杂，并且没有官方文档的有效支撑。
由于Core编译时候并不会将所有文件拷贝到bin目录中，如果是nuget中的包在调试时候会动态在全局的nuget包中进行加载，所以Core版本的Erp发布必须采用dotnet publish发布，这样会将所有dll发布到指定位置。
在本系列的第一篇文章中我们说到了JS文件的复用，通过如下代码将静态文件指向原来Framework的站点目录。
//配置文件中配置
{"Paths": {"HostPath": "../../00根站点","WebContentPath": "../../../00根站点"}
}//Startup.ConfigureServices 中代码
var webPath = Configuration.GetValue<string>("Paths:WebContentPath");
if (!string.IsNullOrEmpty(webPath))HostingEnvironment.WebRootPath = Path.Combine(HostingEnvironment.WebRootPath, Configuration.GetValue<string>("Paths:WebContentPath"));
Core中配置文件有appsettings.json和appsettings.Development.json，其中appsettings.json是生产环境使用，默认将wwwroot作为目录，而和appsettings.Development.json中将根站点的目录加载问web资源目录这样作为调试时候加载。
通过上述方式解决静态资源文件复用和调试模式，生产模式的加载，最后发布时候只要将原来Framework通过拷贝方式复制到发布目录的wwwroot目录即可。
四、ERP的发布
因为Core版本的ERP要支持多种部署模式，包括Windows IIS部署，Linux部署和docker部署， 在ERP的Core版本的发布中做了如下改造：
不依赖于其他程序全部使用脚本进行发布,编写了修改版本和拷贝文件的脚本；
将脚本进行分层,分为发布，docker镜像打包,docker镜像推送；
其中还修复了一些Linux和Docker环境文件大小写的转换。
除了ERP，在调度服务进行发布的时候不光要发布Host程序，还要将任务发布到Host目录中才能算提供完成的调度服务功能，而由上一篇调度服务的架构可知，Host和任务是没有直接的引用关系的，所以发布任务的脚本还要同时支持调试模式下发布到bin目录和发布到最终发布目录，这里给出调度服务的主要脚本，ERP的发布脚本可以查看本系列的第一篇文章。
//发布任务的脚本
@echo offif "%1"=="" ( set root=%cd%
) else ( set root=%1
)if "%2"=="" (set publish_path=%root%\NetCore\MySoft.Scheduler.Host\bin\Debug\netcoreapp2.2\Task
) else (set publish_path=%2\Task
)echo %root%
echo %publish_path%echo 发布数据同步任务
dotnet publish %root%\Tasks\DataSync\Mysoft.Data.Synchronization.Core\Mysoft.Data.Synchronization.Core.csproj -o "%publish_path%\DataSync" -f netstandard2.0
if errorlevel 1 goto fail// 这里省略其他任务的脚本if errorlevel 1 goto fail//发布调度服务的脚本
@echo offif "%1"=="" ( set root=%cd%
) else ( set root=%1
)if "%2"=="" (set publish_path=%root%\ci\publish
) else (set publish_path=%1\Task
)
echo 清理发布目录
rd %publish_path% /S /Qecho 发布主程序，这里采用自寄宿的方式部署
dotnet publish %root%\NetCore\MySoft.Scheduler.Host\MySoft.Scheduler.Host.csproj -o "%publish_path%" --self-contained false -r win7-x64
if errorlevel 1 goto failecho 发布任务
call %root%\ci\publishtask.cmd %root% %publish_path%exit /b 0
:fail
exit /b 1
五、Window部署
在整个ERP的改造过程中，包括ERP，调度服务，文档服务，配置中心的改造，以为文档服务改造和ERP类似，配置中心改造和调度服务类似，所以并没有重复的介绍，这样在Window部署过程就分为两类，一类是IIS部署，一类是Windows服务的部署。
这里看到上述调度服务作为windows发布的时候采用的是独立部署模式，独立部署模式可以脱离于.NET Core的运行时进行部署。
5.1、Windows IIS部署
.NET Core应用要进行WindowsIIS部署，需要安装运行时和捆绑的安装包。基本安装步骤如下：
.NET Core运行时安装；
当前 .NET Core 托管捆绑包安装程序，用于iis部署；
在iis添加网站，注意应用程序池的.NET CLR要改为无托管代码；
按照一般网站挂载步骤加载目录和绑定端口,发布文件在对应git的ci\publish中；
按照上述部署以后启动网站浏览即可。
注意事项：
启动失败：
检查应用程序池中.NET CLR的配置；
检查web.config配置,可以打开日志输出(tdoutLogEnabled=”true”)；
检查应用启动日志。
其他异常：参考老版本的文本日志和数据库日志记录来处理；
5.2、Windows 服务部署
上一篇文章中中我们采用在启动主程序时候使用console参所作为控制台还是服务方式进行运行，windows服务配合简单的脚本即可实现服务的安装，简要脚本如下：
//install.bat
@echo offset currentPath=%~dp0
sc create SchedulerService binpath= "%currentPath%/MySoft.Scheduler.Host.exe --server.urls=http://*:50751"sc start SchedulerServicesc query SchedulerService//uninstall.bat
@echo offsc stop SchedulerServicesc delete SchedulerService
注意事项：
启动失败：打开windows日志查看器查看错误消息后根据文档之前的描述做修正；
访问失败：请检查启动端口是否正常，打开服务管理器有查看属性检查启动参数；
其他异常：请打开应用目录中查看log目录下面日志判断问题；
命令都要基于仓库的根目录运行；
如果以上方式无法确定运行，可以用命令行加入 console参数进行控制台启动来排查问题。
六、Docker单应用部署
改造Core的最终目的就是利用容器部署的便利性，至于Docker的好处网上的说明就太多了，这里就不做介绍，给出使用即可。首先我们看看Dockerfile，比较简单：
//DockerFile
# 加载依赖的镜像
FROM mcr.microsoft.com/dotnet/core/aspnet:2.2# 设置工作目录
WORKDIR /app# 添加文件
COPY ./ /app# 添加环境变量
ENV PersonalDogDirectory dog
ENV ConfigCenter_Uri ""
ENV ASPNETCORE_URLS http://*:80# 导出端口
EXPOSE 80# 启动命令
ENTRYPOINT ["dotnet", "Mysoft.Map6.Web.Core.dll" ]//Docker编译
@echo off
set root=%cd%echo 项目发布
call %root%\ci\publish.cmd %%1echo dock build
pushd %root%\ci\publish
docker build -f netcore.dockerfile -t erp .
popd
//Docker发布 脚本
@echo off
set root=%cd%if "%1"=="" ( set version=1.0.1
) else ( set version=%1
)::build本地境地镜像
call %root%\ci\dockerbuild.cmd %2::修改标签 (注意携带ip端口和版本号)
docker tag erp 10.5.10.47:8073/mysoft/erp:%version%
docker tag erp 10.5.10.47:8073/mysoft/erp:latest::push本地镜像到仓库
docker push 10.5.10.47:8073/mysoft/erp:%version%
docker push 10.5.10.47:8073/mysoft/erp:latest
这里我们使用Nexus作为docker镜像的管理，这里再第一篇文章中也介绍了作为nuget的管理，Nexus的功能比较多，几乎所有常见的包都可以管理，强烈推荐一波。
至于后面的使用只需要简单的docker启动命令即可，命令如下：
//启动erp
docker run -it --rm -p "50751:50751" --name erp 10.5.10.47:8073/mysoft/erp:1.0.1//启动调度服务
docker run -it --rm -p "50751:80" --name scheduler 10.5.10.47:8073/mysoft/scheduler:1.0.1七、DockerCompose整体打包部署
既然我们使用了Docker进行了单个应用的发布部署，那么当然会尝试一下组合的方式进行部署，由于本地我们只尝试了基于dockercomposte的模式进行部署具体的实施方式如下：
首先基于空的演示库进行mssql的docker制作(MSSQL也支持Linux了，赞一个)；
基于配置文件进行配置中心的打包；
编写DockerCompose文件。
MSSQL镜像制作步骤如下：
拉取启动docker镜像 密码自己设置 docker run -it —rm -e ‘ACCEPT_EULA=Y’ -e ‘SA_PASSWORD=123qwe!@#’ -p 1433:1433 —name sqlserver mcr.microsoft.com/mssql/server:2017-latest；
拷贝数据库备份文件到docker目录 docker cp jenkins3_slsys8021.bak sqlserver:/var/opt/mssql/data；
用数据库管理工具进行数据库还原选择文件进行还原；
新建只读账户记住用户名密码默认(dbreader/123qwe!@#),并配置对erp和erp_log的只读权限；
进行配置中心配置，按照之前的用户名密码配置 ,打开erp即可链接测试。
测试连接成功以后执行如下命令：
//将镜像打包
docker commit -m "change somth" sqlserver mssql
//镜像推送 注意对应版本号 %version% 表示版本号
docker tag mssql 10.5.10.47:8073/mysoft/mssql:%version%
docker push 10.5.10.47:8073/mysoft/mssql:%version%
配置中心文件制作之需要规划好Docker部署的端口和地址之后拷贝配置文件即可，这里不做细节的描述。最后给出DockerCompose文件。
version: '3'
services:mymssql:image: 10.5.10.47:8073/mysoft/mssql:1.0.1container_name: mymssqlenvironment:ACCEPT_EULA: "Y"MSSQL_SA_PASSWORD: "szpz3?66jxk!"ports:- "1433:1433"networks:- common-tiermyconfigcenter:build:context: .dockerfile: myconfigcenter.dockerfileargs:image_version: 1.0.1container_name: myconfigcenterports:- "50761:80"networks:- common-tierdepends_on:- mymssqlmyscheduler:image: 10.5.10.47:8073/mysoft/scheduler:1.0.1container_name: myschedulerenvironment:ConfigCenter__Url: "http://myconfigcenter"ports:- "50751:80"networks:- common-tierdepends_on:- mymssql- myconfigcentermydocument:image: 10.5.10.47:8073/mysoft/doc:1.0.1container_name: mydocumentenvironment:ConfigCenter__Url: "http://myconfigcenter"ports:- "50771:80"networks:- common-tier depends_on:- mymssql- myconfigcentermyerp:image: 10.5.10.47:8073/mysoft/xmk:1.0.1container_name: myerpenvironment:ConfigCenter__Url: "http://myconfigcenter"ports:- "50741:80"networks:- common-tierdepends_on:- mymssql- myconfigcenter- myscheduler- mydocument
networks:common-tier:driver: bridge
因为命令比较简单，这里就不做过多的介绍。
八、阿里云部署
ERP有不少客户采用阿里云进行部署，在Core的改造完之后配合项目主数据，面向客户做了阿里云的部署，这里做一个简单的介绍：
逻辑部署图：
物理部署图：
说明：
所有的应用和中间件必须在同一个区域，例如杭州区域；
API网关，分布式集群，存储在同一个区域的不同专有网络中；
应用和中间件互相通信使用内网地址，应用和中间件对外提供服务使用外网地址；
应用使用内网负载均衡提供内网调用，使用外网负载均衡提供外网调用；
Redis采用1主3从的读写分离集群，也可采用1主2副的高可用集群；
k8s至少3个Master，多个Worker的配置，Worker的配置根据应用的内存来选择(ERP一个Pod大概2GB，其他应用大概1GB)，具体需要做性能测试然后做容量规划(EDAS可以很方便的扩容)。
注意事项：
.NET Core的Swagger组件生成的json文件不支持直接导入API网关，需要手动进行配置；
注意规划k8S的内存，尽量大一点；
调度服务只能部署一个Pod，因为是有状态(无状态改造计划中)；
目前配置中心也只能部署一个Pod，因为使用的文件存储，Pod是有状态。
九、总结
在进行阿里云部署的时候反向还得出了后续ERP要更好的贴合云环境容器部署的一些需要改造的部分ERP需要改造的部分：
调度服务和配置中心都需要改造,数据持久化到数据库,不能使用本地文件存储的方式，改造后配置中心可以集群；
配置中心需要分成外网和内网两个地址进行配置，不然从ERP无法跳转到配置中心对应地址(或者全部用外网)；
文档服务需要加入对阿里云OSS的支持；
ERP未来可以支持的功能；
未来要对ERP使用内存进行规范和缩减，合理利用分布式缓存，目前有点太大了。
------ END ------
作者简介
熊同学： 研发工程师，目前负责ERP运行平台的设计与开发工作。
也许您还想看
【复杂系统迁移 .NET Core平台系列】之调度服务改造
【复杂系统迁移 .NET Core平台系列】之WebApi改造
【复杂系统迁移 .NET Core平台系列】之认证和授权
【复杂系统迁移 .NET Core平台系列】之迁移项目工程
【复杂系统迁移 .NET Core平台系列】之界面层
【复杂系统迁移 .NET Core平台系列】之静态文件
![[mybatis]缓存_二级缓存使用细节](https://img-blog.csdnimg.cn/3fd015cb924f49dfbf86664419d725b4.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5ZSQ54Gr,size_20,color_FFFFFF,t_70,g_se,x_16)
![[mybatis]缓存机制介绍_一级缓存二级缓存](https://img-blog.csdnimg.cn/52ebf42b3e5041d78da9033b54c530ad.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5ZSQ54Gr,size_20,color_FFFFFF,t_70,g_se,x_16)
![[mybatis]逆向工程MGB基本编写](https://img-blog.csdnimg.cn/c57070b358c44acb96bf6880ecbfba64.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5ZSQ54Gr,size_20,color_FFFFFF,t_70,g_se,x_16)
![[mybatis]缓存_缓存原理图](https://img-blog.csdnimg.cn/0c5388da3be74cc9a1046259c4c6316b.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5ZSQ54Gr,size_20,color_FFFFFF,t_70,g_se,x_16)
![[SpringBoot2]HelloWorld](https://img-blog.csdnimg.cn/66ada66039cf4ab0abe188e0708df385.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5ZSQ54Gr,size_20,color_FFFFFF,t_70,g_se,x_16)
![[SpringBoot2]容器功能_底层注解配置绑定_@Configuration@Import@Conditional@ImportResource](https://img-blog.csdnimg.cn/f8d41122257d4ffb939a939d9318f357.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5ZSQ54Gr,size_20,color_FFFFFF,t_70,g_se,x_16)
![[SpringBoot2]Lombok](https://img-blog.csdnimg.cn/1f284354f3cc483c8ae8e0de83c3841d.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5ZSQ54Gr,size_20,color_FFFFFF,t_70,g_se,x_16)
![[SpringBoot2]yaml](https://img-blog.csdnimg.cn/03a3b88552d8410aae965321189c7127.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5ZSQ54Gr,size_20,color_FFFFFF,t_70,g_se,x_16)
![[SpringBoot2]web场景_静态资源规则与定制化](https://img-blog.csdnimg.cn/0dcea66a38f649b39eb89ea3824cade4.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5ZSQ54Gr,size_20,color_FFFFFF,t_70,g_se,x_16)