在 v1.3 版本之后，SREWorks 团队收集了较多的用户反馈，大家普遍对于 SREWorks 的内网离线安装有较大的诉求。于是团队决定进一步增强这部分的安装能力。

前端工程部分 (frontend)，为了开发者更加敏捷高效的协作开发，以及便于社区开发者参与共建前端组件生态。我们对前端工程架构进行了重新梳理拆分，按照 Monorepo 模式架构演进；同时也对工程构建相关工具进行了优化升级。

下面为 v1.4 的版本功能版本介绍：

(资料图)

1. 前端工程 Monorepo 模式重构

Monorepo 即单仓 (repository) 多包 (package)，大型前端工程项目采用这种模式进行开发管理，能带来诸多的开发和管理便利:

更加清晰的模块结构和依赖关系；更细粒度的独立构建单元便于协作开发和不同更新频率的子包单独发版；更加高效的代码复用等。

我们在 v1.4 版本中采用 lerna + yarn workspace 的技术方案进行了 Monorepo 的架构实践：将原工程拆分为 @sreworks/app 主包应用，和 @sreworks/components、@sreworks/widgets、@sreworks/framework、@sreworks/shared-utils 四个 npm 子依赖包。目录结构变动如下图所示：

工程重构过程中，我们对原有构建工具也进行了优化升级：

主包应用采用 webpack5 作为构建工具，子依赖包采用 Rollup 作为构建工具；通过调优构建配置，将构建时间由 v1.3 版本的 74 秒降低到 23 秒，提升 68%；通过统一各子包依赖版本、合并重复依赖、以及部分 npm 依赖 cdn 引用本地化处理等方式进行了构建体积调优，调优至 1.6M，较 Monorepo 初版本的 5.4M，降低 70%；@sreworks/widget-cli 远程组件脚手架进行了同步的构建升级。

2. 离线安装

早期版本的离线安装，依赖用户的 Maven 源、PIP 源在用户内网做应用的二次构建，用户普遍反馈内网场景对于这些源的支持也不齐全，更希望无构建直接拉起。

于是在 v1.4 版本中，我们将整个底座 (appId: flycore) 也都上架到了运维市场，使得其相关镜像及元信息，能够作为部署基线固化至开源代码中。

经过收敛之后的镜像清单如下链接，后续每次发版有应用版本更新，都会自动更新该镜像清单。

​​https://github.com/alibaba/SREWorks/blob/master/images.txt​​

清单中总共 59 个镜像，共计存储空间约为 5.9G。

下图为通过 SREWorks 前端组件绘制的按照镜像大小排列的清单矩形树图：

离线部署的命令示例如下，底层依赖软件和运维应用的镜像仓库需要分开设置：

镜像仓库以sreworks.io/hub-test为例：

# 下载sreworks到本地git clone http://github.com/alibaba/sreworks.git -b v1.4 sreworkscd sreworks/chart/sreworks-chart# 安装SREWorkshelm install sreworks ./ \--create-namespace --namespace sreworks \--set global.accessMode="nodePort" \--set global.images.tag="v1.4" \--set appmanager.home.url="http://localhost:30767" \--set saas.onlyBase=true \--set global.images.registry="sreworks.io/hub-test" \--set global.images.imagePullPolicy="IfNotPresent" \--set appmanagerbase.kruise.manager.image.repository="sreworks.io/hub-test/kruise-manager" \--set appmanagerbase.mysql.image.registry="sreworks.io" \--set appmanagerbase.mysql.image.repository="hub-test/mysql" \--set appmanagerbase.zookeeper.image.registry="sreworks.io" \--set appmanagerbase.zookeeper.image.repository="hub-test/zookeeper" \--set appmanagerbase.redis.image.registry="sreworks.io" \--set appmanagerbase.redis.image.repository="hub-test/redis" \--set appmanagerbase.minio.image.registry="sreworks.io" \--set appmanagerbase.minio.image.repository="hub-test/minio"

3. 其他

appmanager kankio 构建逻辑优化升级使用 rancher/local-path-provisioner 作为默认存储供应，移除 openebs 依赖skywalking 进行版本升级（从 8.5.0 升级到 9.3.0），解决 skywalking 初始化 es 相关 index 异常的问题

4. 如何从当前版本升级到 v1.4

升级包含底座，页面可能会有 5-10 分钟的不可访问，请注意。用户自行开发的云原生应用不会受影响 (不重启)，SREWorks 网关到应用的流量会有中断。

git clone http://github.com/alibaba/sreworks.git -b v1.4 sreworkscd sreworks./sbin/upgrade-cluster.sh --kubeconfig="****"

如在使用过程中遇到问题，欢迎各位在 GitHub 中提出 Issues 或 Pull requests。

SREWorks 开源地址：​​https://github.com/alibaba/sreworks​​

在此感谢来自开源社区的 @kw214 (Kimmy Wang) 同学在 Monorepo 演进方案中积极的讨论参与以及代码贡献，也欢迎更多的伙伴能够参与到我们的开源工作组中来，一起将项目做的更好（有意向的同学可以联系群中小助手或群管理员进组）