这是基于vue-vben-admin 模板适用于abp vNext的前端管理项目

12 KiB

Raw Blame History

插件打包与部署

**本文档引用的文件** - [deploy.ps1](file://deploy/deploy.ps1) - [docker-compose.yml](file://docker-compose.yml) - [docker-compose.override.yml](file://docker-compose.override.yml) - [docker-compose.middleware.yml](file://docker-compose.middleware.yml) - [tye.yaml](file://tye.yaml) - [pack.ps1](file://aspnet-core/templates/pack.ps1) - [Migrate.ps1](file://aspnet-core/migrations/Migrate.ps1) - [Dockerfile](file://gateways/internal/LINGYUN.MicroService.Internal.ApiGateway/src/LINGYUN.MicroService.Internal.Gateway/Dockerfile) - [00.auto-config-docker.cmd](file://starter/00.auto-config-docker.cmd) - [readme.md](file://starter/readme.md)

概述

ABP Next Admin是一个基于ABP框架的现代化企业级应用平台，采用微服务架构设计。该项目提供了完整的插件打包与部署解决方案，支持多种部署模式，包括单体应用和微服务架构。本文档详细介绍了插件的打包、版本控制、依赖管理和在不同环境中的部署策略。

项目架构分析

整体架构概览

graph TB
subgraph "前端层"
UI[Vue Vben Admin]
React[React Admin]
end
subgraph "网关层"
IG[内部网关]
WG[Web网关]
end
subgraph "服务层"
Admin[管理服务]
Auth[认证服务]
Platform[平台服务]
Messages[消息服务]
Tasks[任务服务]
Webhooks[Webhook服务]
Workflow[工作流服务]
Wechat[微信服务]
end
subgraph "基础设施层"
MySQL[(MySQL数据库)]
Redis[(Redis缓存)]
RabbitMQ[(RabbitMQ消息)]
ES[(Elasticsearch)]
Kibana[Kibana监控]
end
UI --> WG
React --> WG
WG --> IG
IG --> Admin
IG --> Auth
IG --> Platform
IG --> Messages
IG --> Tasks
IG --> Webhooks
IG --> Workflow
IG --> Wechat
Admin --> MySQL
Auth --> MySQL
Platform --> MySQL
Messages --> MySQL
Tasks --> MySQL
Webhooks --> MySQL
Workflow --> MySQL
Wechat --> MySQL
Admin --> Redis
Auth --> Redis
Platform --> Redis
Messages --> Redis
Tasks --> Redis
Webhooks --> Redis
Workflow --> Redis
Wechat --> Redis
Admin --> RabbitMQ
Auth --> RabbitMQ
Platform --> RabbitMQ
Messages --> RabbitMQ
Tasks --> RabbitMQ
Webhooks --> RabbitMQ
Workflow --> RabbitMQ
Wechat --> RabbitMQ
Admin --> ES
Auth --> ES
Platform --> ES
Messages --> ES
Tasks --> ES
Webhooks --> ES
Workflow --> ES
Wechat --> ES

图表来源

docker-compose.yml
tye.yaml

服务组件分析

系统由以下核心组件构成：

管理服务 (Admin): 提供用户管理、权限控制等核心功能
认证服务 (Auth): 实现OAuth2.0和OpenID Connect认证
平台服务 (Platform): 提供基础平台功能
消息服务 (Messages): 处理实时消息和通知
任务服务 (Tasks): 管理后台任务和作业
Webhook服务 (Webhooks): 处理外部事件回调
工作流服务 (Workflow): 实现业务流程自动化
微信服务 (Wechat): 集成微信相关功能

章节来源

docker-compose.yml
tye.yaml

插件打包流程

NuGet包打包机制

项目提供了完整的NuGet包打包解决方案，支持微服务模板和AllInOne模板两种打包方式。

flowchart TD
Start([开始打包流程]) --> CleanBuild["清理构建目录"]
CleanBuild --> ShowMenu["显示打包菜单"]
ShowMenu --> Choice{"选择打包类型"}
Choice --> |1| MicroPack["打包微服务模板"]
Choice --> |2| AioPack["打包AllInOne模板"]
Choice --> |3| BothPack["打包全部模板"]
MicroPack --> DotNetPack1["dotnet pack<br/>./micro/PackageName.CompanyName.ProjectName.csproj"]
AioPack --> DotNetPack2["dotnet pack<br/>./aio/PackageName.CompanyName.ProjectName.AIO.csproj"]
BothPack --> DotNetPack1
BothPack --> DotNetPack2
DotNetPack1 --> PublishCheck{"是否发布到NuGet?"}
DotNetPack2 --> PublishCheck
PublishCheck --> |是| NuGetPush["推送NuGet包"]
PublishCheck --> |否| SavePackage["保存本地包"]
NuGetPush --> End([打包完成])
SavePackage --> End

图表来源

pack.ps1

打包脚本详解

打包脚本提供了三种打包选项：

微服务模板: 适用于独立部署的微服务模块
AllInOne模板: 适用于单体应用的完整包
全部打包: 同时生成两种类型的包

每个包都会包含：

编译后的DLL文件
相关的依赖项
NuSpec元数据文件
版本信息

章节来源

pack.ps1

发布到NuGet服务器

系统支持自动发布到自定义NuGet服务器：

# 发布命令示例
dotnet nuget push PackageName.1.0.0.nupkg 
    --source "https://custom.nuget.net/nuget/abp/v3/index.json" 
    --api-key "your-api-key" 
    --skip-duplicate

Docker容器化部署

容器编排架构

graph TB
subgraph "Docker Compose编排"
DC[docker-compose.yml]
DCO[docker-compose.override.yml]
DCM[docker-compose.middleware.yml]
end
subgraph "中间件服务"
MySQL[MySQL数据库]
Redis[Redis缓存]
Rabbit[RabbitMQ消息队列]
ES[Elasticsearch]
Kibana[Kibana监控]
end
subgraph "应用服务"
AdminSvc[管理服务容器]
AuthSvc[认证服务容器]
PlatformSvc[平台服务容器]
Gateway[网关服务容器]
UI[前端应用容器]
end
DC --> MySQL
DC --> Redis
DC --> Rabbit
DC --> ES
DC --> Kibana
DCO --> AdminSvc
DCO --> AuthSvc
DCO --> PlatformSvc
DCO --> Gateway
DCO --> UI
DCM --> MySQL
DCM --> Redis
DCM --> Rabbit
DCM --> ES
DCM --> Kibana

图表来源

docker-compose.yml
docker-compose.override.yml
docker-compose.middleware.yml

Dockerfile构建流程

每个服务都包含专门的Dockerfile，用于容器化部署：

FROM mcr.microsoft.com/dotnet/aspnet:8.0
LABEL maintainer="colin.in@foxmail.com"
WORKDIR /app

COPY . /app

EXPOSE 80/tcp
VOLUME [ "./app/Logs" ]
VOLUME [ "./app/Modules" ]

ENTRYPOINT ["dotnet", "ServiceName.dll"]

多阶段构建优化

系统采用多阶段构建策略：

构建阶段: 编译.NET应用程序
复制阶段: 将编译结果复制到最终镜像
运行阶段: 启动应用程序容器

章节来源

Dockerfile

环境变量配置

每个服务都支持通过环境变量进行配置：

environment:
  - ASPNETCORE_ENVIRONMENT=Development
  - ASPNETCORE_HTTP_PORTS=80
  - TZ=Asia/Shanghai
  - ConnectionStrings__Default=Server=mysql;Database=abp;Uid=root;Pwd=123456;

章节来源

docker-compose.yml

多环境部署策略

开发环境部署

开发环境采用快速启动策略：

sequenceDiagram
participant Dev as 开发者
participant Script as 启动脚本
participant Docker as Docker引擎
participant Services as 应用服务
Dev->>Script : 执行启动脚本
Script->>Docker : 启动中间件容器
Docker-->>Services : 中间件就绪
Script->>Script : 创建数据库
Script->>Script : 执行数据库迁移
Script->>Script : 发布.NET项目
Script->>Docker : 构建应用容器
Script->>Docker : 启动应用服务
Docker-->>Dev : 服务启动完成

图表来源

deploy.ps1

生产环境部署

生产环境采用更严格的部署策略：

预检查: 验证环境配置和依赖项
蓝绿部署: 新版本部署到备用实例
流量切换: 平滑切换到新版本
健康检查: 确认服务正常运行
回滚准备: 准备回滚到旧版本

灰度发布策略

系统支持灰度发布，通过以下方式实现：

# 灰度发布配置示例
services:
  admin-api:
    deploy:
      replicas: 2
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure

章节来源

deploy.ps1

版本控制与依赖管理

数据库迁移管理

flowchart TD
Start([开始迁移]) --> SelectDB["选择数据库上下文"]
SelectDB --> GetMigration["获取迁移名称"]
GetMigration --> CreateMigration["创建迁移文件"]
CreateMigration --> ApplyMigration["应用迁移"]
ApplyMigration --> GenerateSQL["生成SQL脚本"]
GenerateSQL --> ExportSQL["导出SQL文件"]
ExportSQL --> End([迁移完成])
ApplyMigration --> HealthCheck{"健康检查"}
HealthCheck --> |失败| Rollback["回滚迁移"]
HealthCheck --> |成功| ExportSQL
Rollback --> End

图表来源

Migrate.ps1

版本控制策略

系统采用语义化版本控制：

主版本号: 不兼容的API修改
次版本号: 向下兼容的功能性新增
修订号: 向下兼容的问题修正

依赖管理

项目使用以下依赖管理策略：

NuGet包管理: 统一的包版本控制
Docker镜像标签: 基于Git标签的镜像版本
数据库迁移: 版本化的数据库变更

章节来源

Migrate.ps1

部署验证与监控

健康检查机制

每个服务都配置了健康检查：

healthcheck:
  test: ["CMD-SHELL", "wget --spider http://localhost/healthz || exit"]
  interval: 10s
  timeout: 5s
  retries: 5

监控指标

系统监控以下关键指标：

服务可用性: 健康检查状态
响应时间: API响应延迟
错误率: HTTP错误统计
资源使用: CPU和内存使用情况
数据库连接: 数据库连接池状态

日志管理

graph LR
subgraph "日志收集"
App[应用日志]
Container[容器日志]
Middleware[中间件日志]
end
subgraph "日志处理"
Logstash[Logstash处理器]
Elasticsearch[Elasticsearch存储]
end
subgraph "可视化"
Kibana[Kibana仪表板]
Dashboard[监控面板]
end
App --> Logstash
Container --> Logstash
Middleware --> Logstash
Logstash --> Elasticsearch
Elasticsearch --> Kibana
Kibana --> Dashboard

图表来源

docker-compose.middleware.yml

故障排除指南

常见部署问题

容器启动失败
- 检查端口占用
- 验证环境变量配置
- 查看容器日志
数据库连接问题
- 确认数据库服务状态
- 检查连接字符串
- 验证网络连通性
服务间通信失败
- 检查DNS解析
- 验证服务发现配置
- 确认防火墙设置

调试工具

系统提供了多种调试工具：

# 查看容器状态
docker-compose ps

# 查看服务日志
docker-compose logs service-name

# 进入容器调试
docker exec -it container-name bash

回滚策略

当部署出现问题时，系统支持快速回滚：

停止新版本服务
恢复备份数据
重启旧版本服务
验证服务状态

最佳实践建议

部署前准备

环境验证: 确保目标环境满足要求
备份数据: 在部署前备份重要数据
测试验证: 在测试环境中验证部署流程
文档记录: 记录部署步骤和注意事项

部署过程优化

并行部署: 同时部署多个独立的服务
资源预留: 为部署过程预留足够的系统资源
监控告警: 设置关键指标的监控告警
自动化测试: 部署后自动运行集成测试

运维管理

定期维护: 定期更新容器镜像和依赖包
性能调优: 根据实际负载调整资源配置
安全加固: 定期检查安全漏洞和配置
容量规划: 根据业务增长预测资源需求

持续改进

反馈收集: 收集运维团队的反馈意见
流程优化: 不断优化部署流程和工具
知识分享: 建立知识库和最佳实践文档
培训提升: 定期组织技术培训和经验分享

通过遵循这些最佳实践，可以确保插件的稳定部署和高效运维，为企业级应用提供可靠的技术支撑。

12 KiB Raw Blame History

插件打包与部署

目录

概述

项目架构分析

整体架构概览

服务组件分析

插件打包流程

NuGet包打包机制

打包脚本详解

发布到NuGet服务器

Docker容器化部署

容器编排架构

Dockerfile构建流程

多阶段构建优化

环境变量配置

多环境部署策略

开发环境部署

生产环境部署

灰度发布策略

版本控制与依赖管理

数据库迁移管理

版本控制策略

依赖管理

部署验证与监控

健康检查机制

监控指标

日志管理

故障排除指南

常见部署问题

调试工具

回滚策略

最佳实践建议

部署前准备

部署过程优化

运维管理

持续改进

12 KiB

Raw Blame History