（3）敏捷转型。

（4）交付体系的建立。

2.演进式架构

（1）通过战略分析现有系统与企业战略的差距并选择改造方案。

（2）按设计思维，精益需求，迭代进行架构改造。

（3）持续进行架构治理，让未来遗留系统改造变得简单化。

3.数字化运营

（1）改造数字化前台。

（2）强大的中台能力支持前台的精准化运营。

（3）后台流程数字化，为中台与前台运营打好基础。（3）敏捷转型。

（4）交付体系的建立。

2.演进式架构

（1）通过战略分析现有系统与企业战略的差距并选择改造方案。

（2）按设计思维，精益需求，迭代进行架构改造。

（3）持续进行架构治理，让未来遗留系统改造变得简单化。

3.数字化运营

（1）改造数字化前台。

（2）强大的中台能力支持前台的精准化运营。

（3）后台流程数字化，为中台与前台运营打好基础。第十二章 HZERO升级

软件升级是指软件从低版本向高版本的更新。由于高版本常常修复低版本的部分缺陷，同时高版本往往会带来新的产品功能。因此，经历了软件升级的产品，一般都会比原版本的性能更好，并得到优化的效果，用户也能有更好的体验，满意度更高。

HZERO一路伴随客户的数字化转型，产品本身在不断迭代，其迭代过程是产品架构不断完善的过程，也是技术组件不断沉淀和积累的过程，那么客户必然会遇到一些问题，基于自身的版本现状和使用现状，是否需要升级，以及如何升级、如何规避风险等。

第一节 HZERO升级的范围定义

传统意义的HZERO升级主要有以下几个方面：

（1）HZERO单租户开源版本向商用多租户版本的升级；

（2）HZERO低版本向高版本或者最新版本升级；

（3）HZERO技术组件和服务升级；

（4）底层框架技术组件版本升级引起的HZERO组件和服务的升级。

若将HZERO升级范围进行扩展，包含以下几种场景：第十二章 HZERO升级

软件升级是指软件从低版本向高版本的更新。由于高版本常常修复低版本的部分缺陷，同时高版本往往会带来新的产品功能。因此，经历了软件升级的产品，一般都会比原版本的性能更好，并得到优化的效果，用户也能有更好的体验，满意度更高。

HZERO一路伴随客户的数字化转型，产品本身在不断迭代，其迭代过程是产品架构不断完善的过程，也是技术组件不断沉淀和积累的过程，那么客户必然会遇到一些问题，基于自身的版本现状和使用现状，是否需要升级，以及如何升级、如何规避风险等。

第一节 HZERO升级的范围定义

传统意义的HZERO升级主要有以下几个方面：

（1）HZERO单租户开源版本向商用多租户版本的升级；

（2）HZERO低版本向高版本或者最新版本升级；

（3）HZERO技术组件和服务升级；

（4）底层框架技术组件版本升级引起的HZERO组件和服务的升级。

若将HZERO升级范围进行扩展，包含以下几种场景：（1）单体HAP架构向HZERO分布式微服务架构升级；

（2）Aurora架构向HZERO分布式微服务架构升级；

（3）其他架构向HZERO分布式微服务架构升级。

确定客户针对HZERO进行升级的场景和范围，有助于帮助客户认清升级的目标，制定出合理的升级方案，从而降低升级风险和保证升级项目成功。

第二节 HZERO升级场景

场景一：HZERO单租户版升级到多租户最新版。

这种场景升级比较简单，无特别难点，工作量比较小，也无特别的风险，成本投入比较小，大致可以分为以下几个步骤。

（1）依次执行SQL脚本修复数据，其中SQL数据修复脚本主要是针对角色权限、菜单权限、多语言数据、菜单数据进行删除。

（2）在hzero-resource下执行相应版本的SaaS脚本数据。

（3）将所有基础服务的依赖从OP版本替换为SaaS版本。

（4）重启所有基础服务，完成升级。

关于具体的SQL数据修复脚本，可参考汉得开放平台HZERO升级章节。（1）单体HAP架构向HZERO分布式微服务架构升级；

（2）Aurora架构向HZERO分布式微服务架构升级；

（3）其他架构向HZERO分布式微服务架构升级。

确定客户针对HZERO进行升级的场景和范围，有助于帮助客户认清升级的目标，制定出合理的升级方案，从而降低升级风险和保证升级项目成功。

第二节 HZERO升级场景

场景一：HZERO单租户版升级到多租户最新版。

这种场景升级比较简单，无特别难点，工作量比较小，也无特别的风险，成本投入比较小，大致可以分为以下几个步骤。

（1）依次执行SQL脚本修复数据，其中SQL数据修复脚本主要是针对角色权限、菜单权限、多语言数据、菜单数据进行删除。

（2）在hzero-resource下执行相应版本的SaaS脚本数据。

（3）将所有基础服务的依赖从OP版本替换为SaaS版本。

（4）重启所有基础服务，完成升级。

关于具体的SQL数据修复脚本，可参考汉得开放平台HZERO升级章节。场景二：HZERO低版本向最新版升级。

升级过程中，是否需要升级到HZERO最新版，可以根据实际的需要进行选择，通常建议直接升级到最新版，但是在实际升级过程中，考虑到客户基于HZERO做了大量的二次开发，此时升级需要格外慎重，需要借助开发助手，在升级前进行代码扫描，识别出是否对HZERO基础组件和服务进行了修改。若没有进行修改，则HZERO升级策略会相对简单，风险和成本也相对小一些，若已经对底层的基础组件和服务做了大量的修改，则需要根据开发助手的代码扫描报告，有针对性地出具细节升级方案，针对二开部分需要进行兼容性改造，并进行大量的回归测试，以降低风险，此场景升级的成本也会相对较高。

由于具体的二开场景的升级方案比较复杂且需要根据场景个性化制定，本章节不做过多介绍，但是针对HZERO本身低版本向高版本的核心升级步骤如图12-1所示。

图12-1 核心升级步骤

场景三：HZERO组件升级。场景二：HZERO低版本向最新版升级。

升级过程中，是否需要升级到HZERO最新版，可以根据实际的需要进行选择，通常建议直接升级到最新版，但是在实际升级过程中，考虑到客户基于HZERO做了大量的二次开发，此时升级需要格外慎重，需要借助开发助手，在升级前进行代码扫描，识别出是否对HZERO基础组件和服务进行了修改。若没有进行修改，则HZERO升级策略会相对简单，风险和成本也相对小一些，若已经对底层的基础组件和服务做了大量的修改，则需要根据开发助手的代码扫描报告，有针对性地出具细节升级方案，针对二开部分需要进行兼容性改造，并进行大量的回归测试，以降低风险，此场景升级的成本也会相对较高。

由于具体的二开场景的升级方案比较复杂且需要根据场景个性化制定，本章节不做过多介绍，但是针对HZERO本身低版本向高版本的核心升级步骤如图12-1所示。

图12-1 核心升级步骤

场景三：HZERO组件升级。原则上不允许高版本的组件兼容低版本的HZERO底座，否则可能会造成不可以预料的不可兼容的情况。例如，1.0的底座，用了1.5版本的文件服务是不可以的，因为高版本的组件是依赖高版本的技术架构来运行的，需要整体升级才行，只可以向下兼容，没法向上。

（1）绝对禁止：用高版本的组件代码直接覆盖原有组件代码。

（2）例外：非HZERO底座组件或者客户自己基于底座二开的业务组件，需要评估具体方案再进行升级。

（3）特殊情况：部分组件缺陷的修复，可以单独针对缺陷，参考最新 HZERO版本组件代码，修改原组件代码，重新部署进行升级。

若是需要使用原有组件的新特性和功能或者新的组件功能，则需要对HZERO底座整体升级才可以实现。

场景四：HAP架构和Aurora架构升级到HZERO。

此种场景整体的升级策略是直接基于HZERO进行重构或者将HAP和Aurora的业务应用作为Legacy系统来进行对应，直接跟HZERO通过集成平台进行集成。具体如何将Legacy系统平缓迁移到HZERO上，可以参考第十一章的相关内容。

另外，自主应用产品本身的升级也将其当作Legacy系统来进行处理。原则上不允许高版本的组件兼容低版本的HZERO底座，否则可能会造成不可以预料的不可兼容的情况。例如，1.0的底座，用了1.5版本的文件服务是不可以的，因为高版本的组件是依赖高版本的技术架构来运行的，需要整体升级才行，只可以向下兼容，没法向上。

（1）绝对禁止：用高版本的组件代码直接覆盖原有组件代码。

（2）例外：非HZERO底座组件或者客户自己基于底座二开的业务组件，需要评估具体方案再进行升级。

（3）特殊情况：部分组件缺陷的修复，可以单独针对缺陷，参考最新 HZERO版本组件代码，修改原组件代码，重新部署进行升级。

若是需要使用原有组件的新特性和功能或者新的组件功能，则需要对HZERO底座整体升级才可以实现。

场景四：HAP架构和Aurora架构升级到HZERO。

此种场景整体的升级策略是直接基于HZERO进行重构或者将HAP和Aurora的业务应用作为Legacy系统来进行对应，直接跟HZERO通过集成平台进行集成。具体如何将Legacy系统平缓迁移到HZERO上，可以参考第十一章的相关内容。

另外，自主应用产品本身的升级也将其当作Legacy系统来进行处理。