EOS Low-Code Platform 8
学习指南
更新说明
初见EOS
专业代码开发手册
智能体开发手册
公共服务框架
运维指南

# 部署步骤指南

原则：可执行、可回滚、幂等

# 1. 环境准备

按照性能调优指南进行性能测试，以性能测试为基准数据，进行硬件需求估算出所需硬件，如果是已有系统，则根据新的业务，评估是否需要扩容或者缩容。

确定上线所需机器数量（服务器/实例数）是系统架构设计和容量规划中的关键环节。

它直接影响系统的性能、稳定性、成本和扩展性。

以下是一个简单的估算示例：

1、单机性能基准测试

在目标生产环境配置（或接近的测试环境）中，对单台机器进行压测，获取其极限能力：

  • 单机最大TPS（无错误、延迟达标）
  • CPU 使用率 ≤ 70% 时的稳定TPS（推荐安全水位）
  • 内存、磁盘 I/O、网络带宽瓶颈点
  • 示例：
    一台 4C8G 的应用服务器，100用户并发，平均响应时间 <= 200ms 条件下，可稳定支撑 500 TPS。

2、业务数据收集

  • 最大并发用户数：500
  • 峰值TPS：3000
  • 数据存储总量：2TB

如果没有历史数据，可通过类比竞品估算。

3、根据业务数据进行估算

所需机器数 = ⌈峰值TPS ÷ 单机安全TPS⌉

示例：

  • 峰值 TPS = 3,000
  • 单机安全 TPS = 500
  • 理论数量 = ⌈3000 / 500⌉ = 6 台

4、考虑高可用与冗余

为避免单点故障，需增加冗余：

至少 2 台（防单机宕机）；

跨可用区部署（如 AWS/Aliyun 多 AZ）；

滚动升级/发布 需额外容量（建议 +20%~30%）

  • 调整后：6 × 1.3 ≈ 8 台

5、分层评估（不同组件独立计算）

  • app服务器：8 台（4C8G）
  • 数据库（主从）：主 1 + 从 2（16C64G + SSD），存储4TB
  • 缓存（Redis）：3 节点集群（32G 内存）
  • 静态资源（CDN/Nginx）：CDN 承载，源站 2 台（4C8G）
  • nacos服务器：2 台（4C8G） 总计：18台

如果是微服务架构，其他组件的估算：

  • afc服务器：8 台（4C8G）
  • bps服务器：4~8 台（4C8G），根据流程压力可以适当调整
  • gateway服务器：2 台（4C8G） 总计：22~26台

# 2. 备份当前系统

备份数据库和应用配置

  # 备份数据库
  mysqldump -h mysql-prod -u backup_user -p --single-transaction mydb > /backup/mydb_$(date +%Y%m%d).sql

  # 备份应用配置
  tar -czf /backup/app-config-$(date +%Y%m%d).tar.gz /etc/myapp/

# 3. 执行数据库升级或者迁移

  # 执行升级脚本
  mysql -h prod-db.example.com -u deploy_user -p mydb < scripts/xx_upgrade.sql

  # 数据库迁移
  mysql -h mysql-prod -u migrate_user -p mydb < scripts/migration_v23.sql

# 4. 部署新应用包

  # 下载新版本
  scp release-v2.3.0.tar.gz deploy@10.0.10.101:/opt/apps/

  # 停止老应用
  /opt/apps/current/bin/shutdown.sh

  # 解压
  ssh deploy@10.0.10.101 "cd /opt/apps/current && tar -xzf release-v2.3.0.tar.gz"

# 5. 启动应用服务 & 验证

  # 启动应用服务
  /opt/apps/current/bin/startup.sh
  sleep 60
  curl -s http://localhost:8080/health | grep '"status":"UP"'

# 6. 验证核心功能

  • 用户能正常登录
  • 其他核心功能

# 7. 回滚方案

  • 停止当前服务：/opt/apps/current/bin/shutdown.sh
  • 切换旧版本appy应用包
  • 数据库回滚（如有结构变更）：执行 rollback_v23.sql（需提前准备），或从备份恢复（耗时较长，仅限紧急情况）
  • 启动老服务：/opt/apps/current/bin/startup.sh
  • 验证老功能正常

# 8.组织人员数据同步

# 方案一：平台数据导入

平台数据导入步骤：

第一步：导入组织机构信息，参见管理组织机构信息。

第二步：导入员工及账号信息，参见管理员工和账号信息。

# 方案二：自定义编码同步

自定义编码同步是通过编写代码的方式，调用三方系统的组织机构和员工账号信息，组装成AFC平台的组织人员账号对应实体数据格式，然后插入到AFC的数据库中。

# 涉及的实体表

自定义编码同步主要涉及以下AFCenter核心表：

表名 说明
afc_dimension 组织维度表，区分组织的维度，不同维度下的组织互不相同
afc_org 组织机构表，记录公司的组织机构信息
afc_position 岗位表，存储岗位信息
afc_employee 员工表，存储员工的个人信息
afc_user 账号表，存储账号信息，通过EMPLOYEE_ID与员工表关联
afc_r_org_position 机构员工映射表，存储员工和机构、岗位的关系

# 注意事项

1 同步org信息时除了基础信息另外还要补充机构实体信息中的ORG_LEVEL、PARENT_ID、FULL_CODE_PATH、DIMENSION_ID、STATUS、TENANT_ID等关键字段信息。

ORG_LEVEL: 机构级别,当前机构处于机构树的第几层级
PARENT_ID： 父机构主键id，根机构值为null
FULL_CODE_PATH： 上级机构的主键合集，例如/1/12，代表当前机构位于根机构主键为1下的子机构主键为12下的子机构；当前机构为根机构时值为/
DIMENSION_ID：维度ID，默认使用系统默认维度的主键值
STATUS：状态，默认为1
TENANT_ID: 租户id，默认为系统租户sys_tenant

2 同步employee信息时除了基础信息另外还要补充员工实体信息中的STATUS、TENANT_ID关键字段信息。

STATUS：状态，默认为1
TENANT_ID: 租户id，默认为系统租户sys_tenant

3 同步user信息时除了基础信息另外还要补充账号实体信息中的IS_ADMIN、PASSWORD_INIT、PASSWORD_UPDATE_TIME、IS_LOCK、LAST_LOGIN_TIME、STATUS、TENANT_ID、EMPLOYEE_ID关键字段信息。

IS_ADMIN：是否为管理员(0不是,1是)
PASSWORD_INIT：密码是否默认密码(0不是1是)
PASSWORD_UPDATE_TIME：更新密码的时间（取当前时间）
IS_LOCK：是否锁定(0否,1是)
LAST_LOGIN_TIME：上次登录时间（取当前时间）
STATUS：账号状态(0禁止,1启用)
TENANT_ID: 租户id，默认为系统租户sys_tenant
EMPLOYEE_ID：员工ID，与AFC_EMPLOYEE表中主键对应

其他表信息同步数据前，可在平台组织中心中新增数据查看表数据插入规则即可。

表结构参考：详细的表结构说明请参考AFCenter表结构说明。

← 第一个表单 →