大组件、小组件生命周期管理设想.md

概述

大组件、小组件统一升级、安装、回滚、取消安装、卸载、强制卸载逻辑

在大型软件的生命周期管理中，选择使用配置文件的方法还是约定优于配置的方法，取决于具体的需求和系统的复杂性。以下是对两种方法的比较及其适用场景的详细分析：

组件生命周期

总控生命周期

sequenceDiagram
    participant User
    participant UI as Command User Interface
    participant Able
    participant mysql as mysql
    participant installer as installer
    participant sc as sc

    User ->> User: 解压总控组件包
    User ->> UI: 执行安装脚本 install.sh，校验合法性
    UI ->> Able: 解析依赖，开始安装总控各组件
    Able ->> mysql: 安装组件
    mysql -->> Able: 安装成功 
    Able ->> sc: 安装组件
    alt install sc 成功
        sc -->> Able: 升级成功
    else
        sc -->> Able: 升级失败
    end
        
        
    
    Able ->> installer: 安装组件

组件依赖关系

组件依赖关系说明

解释依赖关系

dependencies: 列出当前组件所依赖的其他组件。在安装或卸载当前组件之前，先处理这些依赖组件的生命周期步骤。

Able 处理依赖关系

在 Able 中处理依赖关系时，可以按以下步骤进行：
安装操作

解析依赖关系：读取组件的 JSON 配置文件，获取依赖列表。
递归安装依赖组件：按照依赖关系的顺序递归安装每个依赖组件。确保所有依赖组件安装成功后，再安装当前组件。
执行安装步骤：安装当前组件。

卸载操作

解析依赖关系：读取组件的 JSON 配置文件，获取依赖列表。
递归卸载当前组件：在卸载当前组件之前，检查是否有其他组件依赖于它。
卸载依赖组件：按照依赖关系的顺序递归卸载每个依赖组件。确保所有依赖组件卸载成功后，再卸载当前组件。

Able 处理逻辑

扫描目录：Able 程序扫描所有子目录，查找包含 able.json 文件的目录，并将其识别为组件。
解析依赖关系：读取每个组件的 able.json 文件，解析其依赖关系，构建组件依赖关系图。
生命周期管理：
    安装：按照依赖关系的顺序，依次安装每个组件。确保依赖组件先行安装。
    卸载：按照依赖关系的反向顺序，依次卸载每个组件。确保先卸载当前组件后，再卸载其依赖组件。
    升级：先升级依赖组件，然后升级当前组件。
    初始化：同样按依赖关系的顺序初始化每个组件。
    回滚：当某步骤失败时，按依赖关系的反向顺序回滚操作。
    取消安装：在安装过程中遇到问题时，执行取消安装逻辑。
    强制卸载：不考虑依赖关系，直接卸载组件。
    回退：用于将组件回退到之前的版本或状态。

各组件 able.json 文件结构

{
  "name": "sc",                   // 组件名
  "version": "1.5.9",             // 组件版本号，版本号相同则不升级（mysql kube-apiserver etcd）
  "dependencies": [               // 依赖
    "mysql",
    "redis",    
  ],              
  "lifecycle": {                  // 生命周期配置
    "install": {                  // 安装
      "command": "./scripts/install.sh",
      "previous": "echo 'Starting installation'",
      "after": "echo 'Installation complete'",
      "check": "./check_install.sh",
      "retry": 3,                 // 重试次数， 不填就 不重试
      "timeout": 60,              // 超时 second， 默认 3 min
    },
    "init": {                     // 初始化阶段，用于初始化配置（总控、引擎修改 IP 这种需求）、数据库、数据迁移等用途
      "command": "./scripts/init.sh",
      "previous": "echo 'Starting initialization'",
      "after": "echo 'Initialization complete'",
      "check": "./check_init.sh",
      "trigger_on_dependency_change": true      // 当依赖变化时自动初始化
    },
    "upgrade": {                  // 升级
      "command": "./scripts/upgrade.sh",
      "previous": "echo 'Starting upgrade'",
      "after": "echo 'Upgrade complete'",
      "check": "./check_upgrade.sh"
    },
    "commit": {                   // 升级成功确认，说明整个软件已升级完成，将清理前版本数据备份
      "command": "./scripts/commit.sh",
      "previous": "echo 'Starting commit'",
      "after": "echo 'Commit complete'",
      "check": "./check_commit.sh"
    },
    "rollback": {                 // 回滚
      "command": "./scripts/rollback.sh",
      "previous": "echo 'Starting rollback'",
      "after": "echo 'Rollback complete'",
      "check": "./check_rollback.sh"
    },
    "cancel_install": {            // 取消安装
      "command": "./scripts/cancel_install.sh",
      "previous": "echo 'Starting cancel install'",
      "after": "echo 'Cancel install complete'",
      "check": "./check_cancel_install.sh"
    },
    "cancel_upgrade": {            // 取消升级
      "command": "./scripts/cancel_upgrade.sh",
      "previous": "echo 'Starting cancel upgrade'",
      "after": "echo 'Cancel upgrade complete'",
      "check": "./check_cancel_upgrade.sh"
    },
    "uninstall": {                 // 卸载，场景类似于优雅关闭
      "command": "./scripts/uninstall.sh",
      "previous": "echo 'Starting uninstallation'",
      "after": "echo 'Uninstallation complete'",
      "check": "./check_uninstall.sh"
    },
    "force_uninstall": {           // 强制卸载, 杀死进程，清理目录
      "command": "./scripts/force_uninstall.sh",
      "previous": "echo 'Starting force uninstallation'",
      "after": "echo 'Force uninstallation complete'",
      "check": "./check_force_uninstall.sh"
    },
//    "revert": {                     // 回退 （为后面预留）
//      "command": "./scripts/revert.sh",
//      "previous": "echo 'Starting revert'",
//      "after": "echo 'Revert complete'",
//      "check": "./check_force_uninstall.sh"
//    }
  },
  "proto_version": "1",     // 与 able 的协议版本
}

{
  "name": "webserver",                   // 组件名
  "version": "2.1.7",             // 组件版本号，版本号相同则不升级
  "dependencies": {               // 依赖组件
    "kube-apiserver"                       // 其他组件名
    "etcd",
  },
  "suits": ["m", "s", "w"],       // 目前有 m , s , w , 流量引擎的组件必须定义这个字段，最后在 able 中整合，安装套件就安装对应组件即可，根据目前调研的结果，各组件满足这种安装
  "lifecycle": {                  // 生命周期配置
    "install": {                  // 安装
      "command": "./scripts/install.sh",
      "previous": "echo 'Starting installation'",
      "after": "echo 'Installation complete'",
      "check": "./check_install.sh",
      "retry": 3,                 // 重试次数
      "timeout": 60,              // 超时 second
    },
    "init": {                     // 初始化阶段，用于初始化配置、数据库、数据迁移等用途
      "command": "./scripts/init.sh",
      "previous": "echo 'Starting initialization'",
      "after": "echo 'Initialization complete'",
      "check": "./check_init.sh",
      "trigger_on_dependency_change": true      // 当依赖变化后自动初始化
    },
    "upgrade": {                  // 升级
      "command": "./scripts/upgrade.sh",
      "previous": "echo 'Starting upgrade'",
      "after": "echo 'Upgrade complete'",
      "check": "./check_upgrade.sh"
    },
    "rollback": {                 // 回滚
      "command": "./scripts/rollback.sh",
      "previous": "echo 'Starting rollback'",
      "after": "echo 'Rollback complete'",
      "check": "./check_rollback.sh"
    },
    "cancel_install": {            // 取消安装
      "command": "./scripts/cancel_install.sh",
      "previous": "echo 'Starting cancel install'",
      "after": "echo 'Cancel install complete'",
      "check": "./check_cancel_install.sh"
    },
    "uninstall": {                 // 卸载
      "command": "./scripts/uninstall.sh",
      "previous": "echo 'Starting uninstallation'",
      "after": "echo 'Uninstallation complete'",
      "check": "./check_uninstall.sh"
    },
    "force_uninstall": {           // 强制卸载
      "command": "./scripts/force_uninstall.sh",
      "previous": "echo 'Starting force uninstallation'",
      "after": "echo 'Force uninstallation complete'",
      "check": "./check_force_uninstall.sh"
    },
  },
  "proto_version": "1",     // 与 able 的协议版本
}

时序图

sequenceDiagram
    participant User
    participant UI as User Interface
    participant Able
    participant DB as Database
    participant installer as installer
    participant sc as sc
    participant mysql as mysql

    User ->> UI: 导入软件包
    UI ->> Able: 上传软件包
    Able ->> Able: 解析包内容
    Able ->> DB: 记录包信息到数据库
    DB ->> Able: 记录成功
    Able ->> UI: 显示安装、升级、卸载等选项

    User ->> UI: 点击安装
    UI ->> Able: 请求安装
    Able ->> DB: 获取组件依赖信息
    DB ->> Able: 返回依赖信息

    Able ->> installer: 检查依赖 (sc, mysql)
    alt sc 未安装
        Able ->> sc: 安装 sc
        sc ->> Able: 安装成功
    end
    alt mysql 未安装
        Able ->> mysql: 安装 mysql
        mysql ->> Able: 安装成功
    end

    Able ->> installer: 安装 installer
    installer ->> Able: 安装成功

    Able ->> installer: 初始化 installer
    installer ->> Able: 初始化成功

    Able ->> UI: 安装完成

    User ->> UI: 点击升级
    UI ->> Able: 请求升级
    Able ->> DB: 获取组件依赖信息
    DB ->> Able: 返回依赖信息

    Able ->> installer: 检查依赖 (sc, mysql)
    alt sc 需升级
        Able ->> sc: 升级 sc
        sc ->> Able: 升级成功
    end
    alt mysql 需升级
        Able ->> mysql: 升级 mysql
        mysql ->> Able: 升级成功
    end

    Able ->> installer: 升级 installer
    installer ->> Able: 升级成功

    Able ->> installer: 重新初始化 installer
    installer ->> Able: 初始化成功

    Able ->> UI: 升级完成

    User ->> UI: 点击卸载
    UI ->> Able: 请求卸载
    Able ->> DB: 获取组件依赖信息
    DB ->> Able: 返回依赖信息

    Able ->> installer: 检查依赖 (sc, mysql)
    Able ->> installer: 卸载 installer
    installer ->> Able: 卸载成功

    alt sc 无其他依赖
        Able ->> sc: 卸载 sc
        sc ->> Able: 卸载成功
    end
    alt mysql 无其他依赖
        Able ->> mysql: 卸载 mysql
        mysql ->> Able: 卸载成功
    end

    Able ->> UI: 卸载完成

总控安装顺序

installer 中的安装脚本，用户输入
公共常量写入

内部机制

公共常量的要求

各个组件可能需要支持安装到同一机器，所以各组件的常量不能冲突，防止出现情况

A 组件安装时，注入环境变量 a=1 b=2 c=3
B 组件安装到同一节点，注入环境变量 a=21 b=2 c=3
这样最后 a 的值被覆盖了，不准确的，需要整理出，与环境无关，与 A B 组件本身有关的常量

（流量引擎）节点相关常量（变量） .env 文件

GS_VIRD=
GS_Mode=
GS=
GS_EE=
GS_MasterIP=
GS_IsMaster=
GS_ArbiterIP=
GS_DaIface=
GS_LocalIP=
GS_NodeUID=
GS_DaIP=

# 可能保存下面的作为兼容
VIRD=      // 路由ID
Mode=      // "代理模式", "透明部署模式", "路由模式",  1 2 3
GS=        // token
GS_EE=     // 引擎SN
MasterIP=  // 管理IP

公共常量的传递

一些公共常量在安装时的传递过程

安装组件
数据库
安装对应节点 /opt/public/.env 中
各组件通过 LoadEnv GetEnv 获取这些公共常量

问题

@产品，是否还有其他对总控、引擎、Agent 其他的生命周期管理方法，如重启，回退版本

目前总控、引擎组件名整理

总控侧

sc
manager
sc-core
mysql
nsq
redis
apione
journal
layer

流量引擎

webserver
adminDam
dataDam
polycube
nuclei
envoy
data_ha
data_worker
admin_ha
keepalive (它不会启动服务)

边车引擎

webserver
envoy
polycube

镜像引擎

webserver
agent-server
st-controller
suricata

流量Agent

sr-agent

工具

golang-kit

// 加载 env 文件
// LoadEnv(publicEnv)  "/opt/public/.env"
func LoadEnv(envPath string) error {
	// Load the .env file
	err := godotenv.Load(envPath)
	if err != nil {
		log.Fatal("Error loading .env file: ", err)
	}
	return nil
}

// 加载 env 文件
nodeId := os.Getenv(EnvNodeID)

总控安装逻辑

调用 installer 中的 install.sh 脚本
解析用户输入，校验值合法性，构建公共常量
解析各组件依赖关系，被依赖的组件先安装，逐步安装完所有组件
安装完后信息展示

调度逻辑

总控、引擎安装调度逻辑

able 后台开始一个异步安装任务（获取到安装进度，根据已安装组件/总组件的数量计算进度）
拷贝组件包到对应位置

配置文件方法和目录约定方法的比较

优点

灵活性：配置文件可以根据需要灵活定义各种参数和脚本路径，适应不同的需求。
可扩展性：可以很容易地添加新的配置选项或调整现有配置，而不需要改变目录结构或命名约定。
明确性：配置文件可以清晰地描述组件的所有生命周期步骤和相关参数，易于阅读和维护。
版本控制：配置文件可以方便地进行版本控制和管理，便于跟踪和回滚更改。

缺点

复杂性：需要编写和维护配置文件，可能会增加一定的复杂性和工作量。
标准化难度：不同团队可能会有不同的配置文件格式和习惯，需要制定和遵守统一的标准。

适用场景

复杂系统：当系统涉及到复杂的依赖关系和多样化的配置需求时，使用配置文件更为合适。
需要高度自定义：如果每个组件的生命周期管理需要高度自定义的操作和参数，配置文件可以提供更大的灵活性。

约定优于配置方法

优点

简单易用：通过遵循约定，减少了显式配置的需求，使得系统更简单和一致。
快速上手：团队成员可以快速了解和遵循约定，不需要花费大量时间编写配置文件。
减少出错：统一的目录结构和命名约定可以减少配置错误，提高可靠性。

缺点

灵活性有限：约定通常是固定的，灵活性可能不如配置文件高。
扩展性受限：在需要添加新的生命周期步骤或复杂的自定义操作时，可能需要修改约定和实现。

适用场景

简单系统：当系统相对简单且生命周期管理步骤较为标准化时，约定优于配置的方法更加合适。
快速开发：在需要快速开发和部署的场景下，约定优于配置的方法可以提高效率。

综合比较

在大型软件系统中，配置文件方法和约定优于配置的方法各有优缺点。综合考虑，配置文件方法通常更适用于大型软件的生命周期管理，主要原因包括：

复杂性管理：大型系统通常具有复杂的依赖关系和多样化的需求，配置文件提供了足够的灵活性来应对这些复杂性。
可维护性：配置文件明确描述了每个组件的生命周期步骤和参数，便于维护和管理。
可扩展性：配置文件可以方便地进行扩展和调整，适应系统不断变化的需求。

然而，在一些特定的场景下，如需要快速开发、部署且系统相对简单时，约定优于配置的方法也可以作为一种高效的选择。

实施建议

为了兼顾两种方法的优点，可以考虑以下混合策略：

基础约定：使用约定优于配置的方法定义基础的目录结构和命名规则，确保简单、快速的生命周期管理。
配置扩展：在约定的基础上，提供可选的配置文件，用于定义复杂的自定义操作和参数，以满足更高的灵活性需求。

这种混合策略可以在保持系统简单性的同时，提供足够的灵活性和扩展性，适应大型软件系统的生命周期管理需求。

大组件、小组件生命周期管理设想.md

https://abrance.github.io/2024/06/20/project/sr/基础设施相关/大组件、小组件生命周期管理设想/

Author

xiaoy

Posted on

June 20, 2024

Licensed under

sr通信端口、链路整理.md Previous

大组件、小组件生命周期管理设想.md Next

大组件、小组件生命周期管理设想.md

概述

组件生命周期

总控生命周期

组件依赖关系

组件依赖关系说明

Able 处理逻辑

各组件 able.json 文件结构

时序图

总控安装顺序

内部机制

公共常量的要求

公共常量的传递

问题

@产品，是否还有其他对总控、引擎、Agent 其他的生命周期管理方法，如 重启，回退版本

目前总控、引擎组件名整理

工具

golang-kit

总控安装逻辑

调度逻辑

配置文件方法和目录约定方法的比较

优点

缺点

适用场景

约定优于配置方法

优点

缺点

适用场景

综合比较

实施建议

@产品，是否还有其他对总控、引擎、Agent 其他的生命周期管理方法，如重启，回退版本