• 首页
  • 栏目
  • ERP
  • 【复杂系统迁移 .NET Core平台系列】之应用发布与部署

【复杂系统迁移 .NET Core平台系列】之应用发布与部署

  • 2021-11-06
  • Admin

cd9c80826a0853a3900185a58d2ee5db.png

8c3c9ca136a978aad4541dac90647eb7.png

源宝导读:微软跨平台技术框架—.NET Core已经日趋成熟,已经具备了支撑大型系统稳定运行的条件。本文将介绍明源云ERP平台从.NET Framework向.NET Core迁移过程中的实践经验。

一、背景

    随着ERP的产品线越来越多,业务关联也日益复杂,应用间依赖关系也变得错综复杂,单体架构的弱点日趋明显。19年初,由于平台底层支持了分应用部署模式,将ERP从应用子系统层面进行了切割分离,迈出了从单体架构向微服务架构转型的坚实一步。不久的将来,ERP会进一步将各业务拆分成众多的微服务,而微服务势必需要进行容器化部署和运行管理,这就要求ERP技术底层必须支持跨平台,所以将现有ERP系统从.NET Framework迁移到 .NET Core平台势在必行。

    前面我介绍了ERP的迁移和调度服务的.NET Core改造过程,当所有的代码已经就绪的时候就要开始考虑发布和部署了。本篇将介绍ERP和周边服务在常见环境下的部署模式。

二、Framework版本的发布

    原始的Framwork的发布使用的是编译后拷贝文件的方式进行发布,基本步骤如下:

  1. 修改版本号;

  2. nuget还原解决方案;

  3. 调用MSBuild命令编译;

  4. 编译前端脚本;

  5. 拷贝文件;

  6. 打包成压缩包;

  7. 按需推送给客户。

    这其中有一些不合理的地方:

  • 修改版本好是使用一个控制台的程序进行修改,可以用脚本替代;

  • 使用直接使用拷贝文件方式有多余文件,这样在最后一步拷贝文件时候需要排除更多文件;

  • 最后拷贝文件使用的是程序方式进行拷贝,可以用脚本替代。

三、Core版本一般的发布流程

    在一般的Core版本中只用调用dotnet publish 进行发布即可,如果要使用Framework中使用MSBuild命令进行发布的话参数非常复杂,并且没有官方文档的有效支撑。

    由于Core编译时候并不会将所有文件拷贝到bin目录中,如果是nuget中的包在调试时候会动态在全局的nuget包中进行加载,所以Core版本的Erp发布必须采用dotnet publish发布,这样会将所有dll发布到指定位置。

    在本系列的第一篇文章中我们说到了JS文件的复用,通过如下代码将静态文件指向原来Framework的站点目录。

  1. //配置文件中配置
  2. {
  3. "Paths": {
  4. "HostPath": "../../00根站点",
  5. "WebContentPath": "../../../00根站点"
  6. }
  7. }
  8. //Startup.ConfigureServices 中代码
  9. var webPath = Configuration.GetValue<string>("Paths:WebContentPath");
  10. if (!string.IsNullOrEmpty(webPath))
  11. 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的发布脚本可以查看本系列的第一篇文章

  1. //发布任务的脚本
  2. @echo off
  3. if "%1"=="" (
  4. set root=%cd%
  5. ) else (
  6. set root=%1
  7. )
  8. if "%2"=="" (
  9. set publish_path=%root%\NetCore\MySoft.Scheduler.Host\bin\Debug\netcoreapp2.2\Task
  10. ) else (
  11. set publish_path=%2\Task
  12. )
  13. echo %root%
  14. echo %publish_path%
  15. echo 发布数据同步任务
  16. dotnet publish %root%\Tasks\DataSync\Mysoft.Data.Synchronization.Core\Mysoft.Data.Synchronization.Core.csproj -o "%publish_path%\DataSync" -f netstandard2.0
  17. if errorlevel 1 goto fail
  18. // 这里省略其他任务的脚本
  19. if errorlevel 1 goto fail
  20. //发布调度服务的脚本
  21. @echo off
  22. if "%1"=="" (
  23. set root=%cd%
  24. ) else (
  25. set root=%1
  26. )
  27. if "%2"=="" (
  28. set publish_path=%root%\ci\publish
  29. ) else (
  30. set publish_path=%1\Task
  31. )
  32. echo 清理发布目录
  33. rd %publish_path% /S /Q
  34. echo 发布主程序,这里采用自寄宿的方式部署
  35. dotnet publish %root%\NetCore\MySoft.Scheduler.Host\MySoft.Scheduler.Host.csproj -o "%publish_path%" --self-contained false -r win7-x64
  36. if errorlevel 1 goto fail
  37. echo 发布任务
  38. call %root%\ci\publishtask.cmd %root% %publish_path%
  39. exit /b 0
  40. :fail
  41. exit /b 1

五、Window部署

    在整个ERP的改造过程中,包括ERP,调度服务,文档服务,配置中心的改造,以为文档服务改造和ERP类似,配置中心改造和调度服务类似,所以并没有重复的介绍,这样在Window部署过程就分为两类,一类是IIS部署,一类是Windows服务的部署。

    这里看到上述调度服务作为windows发布的时候采用的是独立部署模式,独立部署模式可以脱离于.NET Core的运行时进行部署。

5.1、Windows IIS部署

    .NET Core应用要进行WindowsIIS部署,需要安装运行时和捆绑的安装包。基本安装步骤如下:

  1. .NET Core运行时安装;

  2. 当前 .NET Core 托管捆绑包安装程序,用于iis部署;

  3. 在iis添加网站,注意应用程序池的.NET CLR要改为无托管代码;

  4. 按照一般网站挂载步骤加载目录和绑定端口,发布文件在对应git的ci\publish中;

  5. 按照上述部署以后启动网站浏览即可。

注意事项:

  1. 启动失败:

    1. 检查应用程序池中.NET CLR的配置;

    2. 检查web.config配置,可以打开日志输出(tdoutLogEnabled=”true”);

    3. 检查应用启动日志。

  2. 其他异常:参考老版本的文本日志和数据库日志记录来处理;

5.2、Windows 服务部署

    上一篇文章中中我们采用在启动主程序时候使用console参所作为控制台还是服务方式进行运行,windows服务配合简单的脚本即可实现服务的安装,简要脚本如下:

  1. //install.bat
  2. @echo off
  3. set currentPath=%~dp0
  4. sc create SchedulerService binpath= "%currentPath%/MySoft.Scheduler.Host.exe --server.urls=http://*:50751"
  5. sc start SchedulerService
  6. sc query SchedulerService
  7. //uninstall.bat
  8. @echo off
  9. sc stop SchedulerService
  10. sc delete SchedulerService

注意事项:

  1. 启动失败:打开windows日志查看器查看错误消息后根据文档之前的描述做修正;

  2. 访问失败:请检查启动端口是否正常,打开服务管理器有查看属性检查启动参数;

  3. 其他异常:请打开应用目录中查看log目录下面日志判断问题;

  4. 命令都要基于仓库的根目录运行;

  5. 如果以上方式无法确定运行,可以用命令行加入 console参数进行控制台启动来排查问题。

六、Docker单应用部署

    改造Core的最终目的就是利用容器部署的便利性,至于Docker的好处网上的说明就太多了,这里就不做介绍,给出使用即可。首先我们看看Dockerfile,比较简单:

  1. //DockerFile
  2. # 加载依赖的镜像
  3. FROM mcr.microsoft.com/dotnet/core/aspnet:2.2
  4. # 设置工作目录
  5. WORKDIR /app
  6. # 添加文件
  7. COPY ./ /app
  8. # 添加环境变量
  9. ENV PersonalDogDirectory dog
  10. ENV ConfigCenter_Uri ""
  11. ENV ASPNETCORE_URLS http://*:80
  12. # 导出端口
  13. EXPOSE 80
  14. # 启动命令
  15. ENTRYPOINT ["dotnet", "Mysoft.Map6.Web.Core.dll" ]
  16. //Docker编译
  17. @echo off
  18. set root=%cd%
  19. echo 项目发布
  20. call %root%\ci\publish.cmd %%1
  21. echo dock build
  22. pushd %root%\ci\publish
  23. docker build -f netcore.dockerfile -t erp .
  24. popd
  25. //Docker发布 脚本
  26. @echo off
  27. set root=%cd%
  28. if "%1"=="" (
  29. set version=1.0.1
  30. ) else (
  31. set version=%1
  32. )
  33. ::build本地境地镜像
  34. call %root%\ci\dockerbuild.cmd %2
  35. ::修改标签 (注意携带ip端口和版本号)
  36. docker tag erp 10.5.10.47:8073/mysoft/erp:%version%
  37. docker tag erp 10.5.10.47:8073/mysoft/erp:latest
  38. ::push本地镜像到仓库
  39. docker push 10.5.10.47:8073/mysoft/erp:%version%
  40. docker push 10.5.10.47:8073/mysoft/erp:latest

    这里我们使用Nexus作为docker镜像的管理,这里再第一篇文章中也介绍了作为nuget的管理,Nexus的功能比较多,几乎所有常见的包都可以管理,强烈推荐一波。

    至于后面的使用只需要简单的docker启动命令即可,命令如下:

  1. //启动erp
  2. docker run -it --rm -p "50751:50751" --name erp 10.5.10.47:8073/mysoft/erp:1.0.1
  3. //启动调度服务
  4. docker run -it --rm -p "50751:80" --name scheduler 10.5.10.47:8073/mysoft/scheduler:1.0.1


七、DockerCompose整体打包部署

    既然我们使用了Docker进行了单个应用的发布部署,那么当然会尝试一下组合的方式进行部署,由于本地我们只尝试了基于dockercomposte的模式进行部署具体的实施方式如下:

  1. 首先基于空的演示库进行mssql的docker制作(MSSQL也支持Linux了,赞一个);

  2. 基于配置文件进行配置中心的打包;

  3. 编写DockerCompose文件。

MSSQL镜像制作步骤如下:

  1. 拉取启动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;

  2. 拷贝数据库备份文件到docker目录 docker cp jenkins3_slsys8021.bak sqlserver:/var/opt/mssql/data;

  3. 用数据库管理工具进行数据库还原选择文件进行还原;

  4. 新建只读账户记住用户名密码默认(dbreader/123qwe!@#),并配置对erp和erp_log的只读权限;

  5. 进行配置中心配置,按照之前的用户名密码配置 ,打开erp即可链接测试。

    测试连接成功以后执行如下命令:

  1. //将镜像打包
  2. docker commit -m "change somth" sqlserver mssql
  3. //镜像推送 注意对应版本号 %version% 表示版本号
  4. docker tag mssql 10.5.10.47:8073/mysoft/mssql:%version%
  5. docker push 10.5.10.47:8073/mysoft/mssql:%version%

    配置中心文件制作之需要规划好Docker部署的端口和地址之后拷贝配置文件即可,这里不做细节的描述。最后给出DockerCompose文件。

  1. version: '3'
  2. services:
  3. mymssql:
  4. image: 10.5.10.47:8073/mysoft/mssql:1.0.1
  5. container_name: mymssql
  6. environment:
  7. ACCEPT_EULA: "Y"
  8. MSSQL_SA_PASSWORD: "szpz3?66jxk!"
  9. ports:
  10. - "1433:1433"
  11. networks:
  12. - common-tier
  13. myconfigcenter:
  14. build:
  15. context: .
  16. dockerfile: myconfigcenter.dockerfile
  17. args:
  18. image_version: 1.0.1
  19. container_name: myconfigcenter
  20. ports:
  21. - "50761:80"
  22. networks:
  23. - common-tier
  24. depends_on:
  25. - mymssql
  26. myscheduler:
  27. image: 10.5.10.47:8073/mysoft/scheduler:1.0.1
  28. container_name: myscheduler
  29. environment:
  30. ConfigCenter__Url: "http://myconfigcenter"
  31. ports:
  32. - "50751:80"
  33. networks:
  34. - common-tier
  35. depends_on:
  36. - mymssql
  37. - myconfigcenter
  38. mydocument:
  39. image: 10.5.10.47:8073/mysoft/doc:1.0.1
  40. container_name: mydocument
  41. environment:
  42. ConfigCenter__Url: "http://myconfigcenter"
  43. ports:
  44. - "50771:80"
  45. networks:
  46. - common-tier
  47. depends_on:
  48. - mymssql
  49. - myconfigcenter
  50. myerp:
  51. image: 10.5.10.47:8073/mysoft/xmk:1.0.1
  52. container_name: myerp
  53. environment:
  54. ConfigCenter__Url: "http://myconfigcenter"
  55. ports:
  56. - "50741:80"
  57. networks:
  58. - common-tier
  59. depends_on:
  60. - mymssql
  61. - myconfigcenter
  62. - myscheduler
  63. - mydocument
  64. networks:
  65. common-tier:
  66. driver: bridge

因为命令比较简单,这里就不做过多的介绍。

八、阿里云部署

    ERP有不少客户采用阿里云进行部署,在Core的改造完之后配合项目主数据,面向客户做了阿里云的部署,这里做一个简单的介绍:

逻辑部署图:

236328c8585556663d91e93d7e14f611.png

物理部署图:

9010705c06ee4bd0825fbc6eea3d0214.png

说明:

  1. 所有的应用和中间件必须在同一个区域,例如杭州区域;

  2. API网关,分布式集群,存储在同一个区域的不同专有网络中;

  3. 应用和中间件互相通信使用内网地址,应用和中间件对外提供服务使用外网地址;

  4. 应用使用内网负载均衡提供内网调用,使用外网负载均衡提供外网调用;

  5. Redis采用1主3从的读写分离集群,也可采用1主2副的高可用集群;

  6. k8s至少3个Master,多个Worker的配置,Worker的配置根据应用的内存来选择(ERP一个Pod大概2GB,其他应用大概1GB),具体需要做性能测试然后做容量规划(EDAS可以很方便的扩容)。

注意事项:

  1. .NET Core的Swagger组件生成的json文件不支持直接导入API网关,需要手动进行配置;

  2. 注意规划k8S的内存,尽量大一点;

  3. 调度服务只能部署一个Pod,因为是有状态(无状态改造计划中);

  4. 目前配置中心也只能部署一个Pod,因为使用的文件存储,Pod是有状态。

九、总结

    在进行阿里云部署的时候反向还得出了后续ERP要更好的贴合云环境容器部署的一些需要改造的部分ERP需要改造的部分:

  1. 调度服务和配置中心都需要改造,数据持久化到数据库,不能使用本地文件存储的方式,改造后配置中心可以集群;

  2. 配置中心需要分成外网和内网两个地址进行配置,不然从ERP无法跳转到配置中心对应地址(或者全部用外网);

  3. 文档服务需要加入对阿里云OSS的支持;

  4. ERP未来可以支持的功能;

  5. 未来要对ERP使用内存进行规范和缩减,合理利用分布式缓存,目前有点太大了。

------ END ------

原文:https://blog.csdn.net/farway000/article/details/121173555

联系站长

QQ:769220720