前端架构大升级，资源架构重塑全攻略（图文详解）

站长

2024年04月12日 10:54 · 阅读数 11

目前，众多企业都积极涉足基础私有云服务的开发，类似于阿里云、腾讯云等公有云服务。我所在的团队就是负责于这方面的研发，为公司内部各技术部门提供基础云能力。私有云对稳定性要求极高，从公司角度来说，一旦私有云出现问题，将影响公司所有部门的线上产品。像最近引起了广泛关注的阿里云宕机问题，最终导致***。我当时做资源架构重塑时，也面临很大的风险，稍有不慎可能导致事故，进而我也可能***。

为此，我详细整理了这篇文章中，分享我在私有云前端资源架构重塑的方案和实施经验。我认为本文对于前端资源管理、性能优化、配置管理、安全性、解耦、一致性、集成化部署以及用户体验等多个关键方面具有一定的参考价值，并能带来一定的收益产出。

或许目前大家可能用不到，但以后可能会派上用场，建议大家收藏起来。由于文章内容较多，借助目录阅读效果会更好。希望这篇文章对你有所帮助，有所借鉴。

那我们就开始吧！！！

事情的起因

私有云服务产品中涵盖了许多独立的业务项目。当时为了有效整合这些独立的业务项目，前端方面采用了微前端的方式，将它们组合成一个庞大的整体。而其中各业务项目的前端资源，就存放在私有云自研的对象存储中。

前端架构大升级，资源架构重塑全攻略（图文详解）

这样就出现了每次前端资源请求，都必须经过私有云的对象存储服务。所以，一旦该服务出现问题，会导致所有前端资源不可用。不仅公司私有云中的各个业务功能不能使用，而且使用私有云的各个部门都可能会出现问题。目前，测试环境已经出现了该问题，因此迫切需要保证前端资源的独立性，防止与对象存储服务过于耦合。

这个问题也比较普遍，不能因为存储前端资源的服务出问题，就导致所有的产品业务不能使用，那损失就大了。

前端资源现状剖析

最初，有老师提出了一个想法：将私有云各项目的前端资源迁移到阿里云OSS的云存储上，并通过在代码中加载并运行云存储提供的URL来实现。初步来看，这种方法是可行的。然而，从网页资源加载速度的角度来看，用户可能会在后续体验中感受到网页加载速度慢，这与我们期望的最终结果不符。

在后续的调研中，我也发现前端团队的部分项目已经在按需加载、懒加载等方面进行了优化，以加速资源的请求响应。然而，这些优化措施也导致了构建了大量的资源文件。在私有云使用高峰期，页面产生了较高的请求量，需要一定的带宽和负载。这也从侧面印证了最初的想法不太可取。因此，我们需要进一步采取措施，实现更理想的网页加载效果。

继续调研后，我发现私有云目前的前端资源现状分为三种：

资源方式	项目	维护人数	备注
私有云对象存储	对象存储项目、......共13个项目	1人
阿里云OSS	主应用项目、......共2个项目	2人	在微前端架构中，主应用项目是整个应用的主要入口点和控制中心。
服务器	监控项目、.....共3个项目	2人

1. 私有云对象存储

私有云对象存储作为依赖于内部服务器的存储加载方式，带来了一系列优势，包括成本降低、人效提升以及技术上的灵活定制。

然而，这种存储方式也引发了前端资源与对象存储服务之间过于紧密的耦合问题。存储、资源地址用的都是私有云对象存储提供的能力，二者交叉依赖。而且，私有云对象存储服务内部有多个环节处理，一旦某个环节出现问题，对象存储服务不稳定，将直接直接波及其他私有云业务，最严重的后果将是整个私有云业务都不可用。

因此，迫切需要寻求解决方案，确保私有云各业务的独立性和正常运行。

2. 阿里云OSS

阿里云 OSS 不仅提供存储，也允许直接通过阿里云存储提供的资源地址进行访问。它的优势是可以直接访问云资源，简单高效，适用于快速部署和开发。但是缺点也很明显访问云资源在大型文件或负载量大的情况下，会存在一定的访问延迟，另外公共云资源地址可能涉及安全性和隐私风险，还限制了一些高级功能，如资源缓存控制等，扩展性相对较弱。

只使用阿里云 OSS 需要权衡使用场景和需求。

3. 服务器

服务器存储是将前端资源直接存储在服务器内部，直接加载使用。这种存储和加载过程简单高效，适用于对性能要求较高的项目，不依赖外部云服务，可以在团队内部环境中完全掌控资源。但是受到服务器性能和网络环境的限制，服务器故障或不可用可能导致网站前端资源无法加载。

此外还需要额外的维护工作来保持服务器稳定性和可靠性，资源存储和访问负载大的情况下，还需要扩容。

前端架构大升级，资源架构重塑全攻略（图文详解）

这引发了一个问题：对于私有云中的各项目而言，仅仅将资源迁移到新的存储位置就足够了吗？

挑战和实现目标

显然是不够的，我们的目标应该还有对前端资源的高效管理、简捷维护以及良好的扩展性。然而，这在实际操作中复杂而庞大，不仅需要考虑技术方案，也需要考虑人力成本、时间成本等多个因素。但无论如何，最关键的还是要确保资源的稳定性。

在实现这一目标的过程中，虽然面临了一些挑战，但同时更明确了具体的实现目标：

资源存储的管理

问题： 如何有效管理和存储大规模的前端资源文件，确保高效访问和使用？

数据规模巨大： 如何高效管理、追踪、扩容快速增长的资源文件数量和大小。
不同资源的处理： 如何统一存储并管理不同项目、不同类型的资源文件，满足资源针对性的资源配置处理和优化。
安全性和权限控制： 如何确保只有授权用户可以进行资源的上传、删除和修改，避免潜在的安全隐患。
容灾机制：建立容灾机制，迅速切换到备用资源，确保业务稳定运行。

优化前端资源加载速度

问题： 如何优化前端资源加载速度，提升用户体验和网站性能？

网络环境不稳定： 用户的网络连接可能不稳定，网络条件可能会有很大的波动，导致资源加载速度变化较大。
资源文件体积过大： 如何处理大型文件、高频资源，避免影响加载速度。
资源缓存配置： 我计划添加资源缓存策略，再给资源响应加个速。

资源统一管理和灵活配置

问题： 如何建立高效的前端资源管理机制，确保统一管理和维护？如何灵活处理跨域访问等特殊需求，确保资源适用于不同场景？

资源管理体系：如何建立一套资源管理体系，对不同资源、不同环境的资源进行集中的管理和维护。
灵活配置机制：如何统一配置不同项目、不同类型的资源，满足针对性的处理和优化（如跨域、缓存处理）。
复杂场景下的使用：如何满足复杂情况下的使用，如逻辑规则、正则规则等。
安全性和权限控制：如何保障资源管理和维护不同情况下的安全策略和权限控制。
方便且高效的界面：能不能提供一个简捷且高效的可视化界面，简化开发人员的操作，还能减少误操作。

资源迁移的成本控制

问题： 如何控制前端资源迁移的时间、人力成本以及风险成本等？

人力成本：如何最小化人力成本，比如说团队成员的投入人力、团队成员的培训。
时间成本：如何避免对业务开发、业务正常运行的中断，尽可能短的时间内完成。
硬件和软件成本：迁移会不会需要新的硬件设备或软件许可证等，增加的成本如何有效控制。
测试和验证成本：如何在保证稳定性的前提下，降低资源迁移的测试和验证成本。
迁移工具成本：迁移资源如此多，会不会用到迁移工具，从而增加成本。
风险管理成本：这个重要性不言而喻，制定有效的风险管理策略，提前预料到并解决潜在问题，确保出现问题能够迅速恢复。

资源版本更新管理

目前私有云的部分项目中，存在资源无法及时更新的情况，需要用户手动清除缓存，用户体验差。这不仅影响到用户体验，更会对资源迁移的不及时更新带来隐患，所以必须处理。

问题：如何确保及时更新资源版本，保障用户体验、资源迁移以及紧急回滚操作？

版本控制：如何简单有效，便可以实现各项目的版本及时更新和紧急回滚。
资源依赖关系：在更新某一资源时，可能会涉及到其他资源的变动，如何处理好资源之间的依赖关系。
可视化持续部署：充分利用自动化构建部署平台的构建、部署和管理能力，不仅能管理版本更新，更能简化部署发布流程。

代码层面的安全性

问题：如何提升代码层面的安全性，如何防止敏感信息泄露和误操作？

公开访问风险：如何避免直接暴露代码资源存储的风险。
访问权限控制：如何正确配置访问、上传权限，避免访问受限或过于宽松。
传输过程中的安全性：在资源传输过程中，如何保证传输的资源安全性。
敏感信息的存储：如何确保只有授权的用户能够访问和使用敏感信息。

架构重塑后的验证与测试

问题：如何确保重塑后资源能够正常加载和运行？

资源异常：如何提前验证与测试资源是否正常运行。
资源请求链路异常：如何提前确保资源请求链路的正常运行。
项目运行异常：如何提前确保迁移后的项目运行正常。

资源的备份和恢复策略

问题：如何快速有效地恢复到正常状态，确保业务连续性和可靠性？

迁移过程中的不确定性：如何规避架构重塑后的各种不确定因素，如网络问题、配置错误等方面。
业务连续性的保障：如何在架构重塑失败时迅速恢复业务到正常状态。

此外，还有多项目的异构性、资源迁移的一致性等问题需要考虑。这已经不仅仅是迁移资源，需要对前端资源架构进行架构重塑。

综合性系统架构

前端资源架构重塑需要考虑的方面很多，尤其是涉及多项目的情况下。各项目的异构性，不同的打包方式、上传方式和请求头配置不同，增加了前端资源架构方案设计的复杂性。因此需要在综合考虑各项目现有情况的基础上，寻找高效、共通的解决方案来提高效率。

内容存储分发

首先，针对资源存储和资源加速，构建高效的资源内容分发网络。通过将阿里云 OSS 与 CDN 结合使用，不仅能为网站提供高效、稳定和安全的内容分发服务，提升用户的访问体验，同时也能够在团队层面有效控制存储成本和带宽成本。

前端架构大升级，资源架构重塑全攻略（图文详解）

缓存和加速：CDN 通过将静态资源缓存在全球各地的服务器节点上，使用户可以从最近的节点获取内容，从而显著减少了内容加载时间，提升整体性能，改善用户体验。
降低服务器负载：将静态资源存储在 OSS 中可以减轻服务器的负载。 CDN 负责大部分静态资源的分发，服务器可以集中精力处理业务逻辑，从而提高了服务器的效率和稳定性。
节省成本：OSS 提供了经济高效的方式来存储大量的静态资源，而 CDN 则可以帮助你降低带宽成本，为网站运营提供了成本效益。
抵御大流量和提高网站安全性：CDN 不仅能够缓解源服务器承受的大流量压力，还提供一定程度的安全防护，如 DDoS 攻击，从而确保网站的稳定性和安全性。
容灾备份：在源服务器发生故障或不可用的情况下，CDN 可以提供备用内容，确保用户依然能够访问网站的静态资源，增强了网站的容灾能力。

注意：切记！确保OSS上存储了各版本资源文件，以防止突发事件。虽有Hash和缓存配置确保版本唯一性和及时更新，但浏览器不一定加载最新资源，可能使用旧资源，因此OSS的各版本资源文件对防止页面问题至关重要。

搭建中间层服务

为了实现资源的统一管理和灵活配置，考虑在资源链路中间搭建一个中间层服务，作为资源管理的枢纽。中间层服务使用反向代理服务器或者 API 网关来统一管理前端资源的请求，不仅提供统一的配置中心，还能更有效地管理和配置资源。

统一配置中心：建立一个配置中心，集中管理所有项目资源的配置信息，包括域名、请求头、缓存策略等。
配置项分类：通过代理正则匹配进行分类、分组管理，处理不同项目、不同类型的文件。
灵活的配置扩展机制：支持灵活的扩展，通过配置文件方式添加新的配置项，增加正则匹配、逻辑判断等复杂逻辑。
容灾处理：中间层服务打通 OSS 与 CDN 的上下游，可在中间层服务配置中切换 OSS 为 IDC 或腾讯云 COS，增加资源的灵活性（等同于也支持资源的再次迁移）。

系统架构设计

通过将内容存储分发和中间层服务结合，我们构建了一个高性能、可扩展、灵活的前端系统架构。在这个架构中，我们将静态资源存储在 OSS 中，并通过 CDN 实现了这些静态资源的迅速分发。与此同时，中间层服务充当了请求的处理者，提供了灵活的资源管理和配置选项，使得系统更容易扩展并适应不同的业务需求。这种整合方案不仅显著提升了性能，还增强了系统的可靠性和灵活性，为用户提供了更好的使用体验。

前端架构大升级，资源架构重塑全攻略（图文详解）

OSS：优势在于提供可靠的持久化存储，确保资源存储的稳定性。
CDN：优势在于提供资源提速，加速用户访问速度，降低延迟，优化用户体验。
中间层服务：优势在于提供资源灵活管理、配置的功能，使得资源加载链路更加灵活。

这是一种保障链路稳定性、灵活性的方案，可以根据团队成本或技术需求，在 OSS、CDN、中间层服务三个方面进行灵活搭配。例如将 OSS 切换到 IDC 或腾讯云的云存储 COS。

这种配置的优势还在于实现资源的灾备机制，当前配置的云存储出现问题时，可以灵活切换到另外一个云存储服务上。

微前端资源迁移的策略

在前端资源架构重塑的前期铺垫完成后，下一步就开始着手准备和实施资源的迁移。考虑到私有云前端采用微前端的方式，为了更加灵活地控制迁移过程，引入一个开关队列（Queue） 在迁移过程中提供精准的控制，确保迁移的顺序和时机。

这样的设计能够有效降低迁移过程中的风险，为什么呢？我们往下看。

开关队列（Queue）

迁移前端资源时，如何保证迁移前端资源的平稳过渡，对用户感知零影响。这里我对私有云的主应用项目进行代码改造，它最终实现的目标是：

支持原资源和迁移资源之间的灵活切换。
支持项目可以单独/分批迁移。

前端架构大升级，资源架构重塑全攻略（图文详解）

增量迁移：有利于采用增量迁移的方式，可以单个、分批迁移资源。也可以先迁移部分项目进行测试，以降低整体迁移的风险。
简化迁移和恢复成本：可以轻松添加或移除项目到开关队列，简化了迁移和恢复操作。这不仅减少了操作复杂性，还提高了整个迁移过程的可控性。
自动化构建部署工具：结合构建平台的自动化构建部署，使迁移过程更加快捷高效。
不限时间：各项目前端负责人可以合理安排各自时间，随时迁移资源，减少迁移带来的成本。

私有云采用微前端框架 qiankun，其中主应用项目中的 registerMicroApps API 负责处理各子应用的加载。通过在这个 API 执行前增加开关Queue，实现对源资源和迁移资源的灵活控制。简要代码如下：

// 子应用名称
import { PROJECT_A, PROJECT_B } from '@/common/utils/const'
function qiankunEntryConfig (app) {
    // 迁移的新项目
    const appQueue = [PROJECT_A, PROJECT_B]
    const ORIGIN_URL = appQueue.includes(app)
        ? `https://${process.env.VUE_APP_ORIGIN_NEW}/${app}/${process.env.VUE_APP_ENV}/index.html`
        : `https://${process.env.VUE_APP_ORIGIN_OLD}/${app}/${process.env.VUE_APP_ENV}/index.html`
        
    return ORIGIN_URL
}

const qiankunRegisterMicroApps = [
  {
    name: PROJECT_A,
    entry: qiankunEntryConfig(PROJECT_A),
    ...
  },
  {
    name: PROJECT_B,
    entry: qiankunEntryConfig(PROJECT_B),
    ...
  },
]

registerMicroApps(qiankunRegisterMicroApps)

开关 Queue 就像其名字一样，若未打开，项目将永远无法完成迁移，同时也不会对尚未迁移的任何项目产生任何影响。

前端架构大升级，资源架构重塑全攻略（图文详解）

集成化持续部署

由于历史原因，各项目都有自己的一套构建部署方式，而且前端有 3 种资源方式，这对迁移来说带来了不可控性，对以后的扩展性也不好。因此，我结合各自项目的构建部署方式，以及后续继续使用的构建平台，重新整理了一套前端集成化持续部署方案，其中关键步骤如下：

前端架构大升级，资源架构重塑全攻略（图文详解）

统一上传依赖包： 所有项目都采用统一的上传依赖包，以减少上传过程中可能出现的问题。
哈希打包配置： 通过使用哈希值进行打包配置，确保文件的唯一性。再结合缓存策略，实现版本更新和快速切换的功能。
设置镜像源： 在代码中设置镜像源.npmrc，确保在线上和线下均能顺利下载依赖。

代码提供上传能力： 在代码中配置上传依赖包和上传脚本，保持线上与线下的一致性，支持紧急发布保障机制。

"scripts": {
    "uploadAli:tice": "upload-cloud-aly --uploadFrom=dist --uploadTo=demo-fe/tice --config=./oss.tice.conf.json",
    "uploadAli:test": "upload-cloud-aly --uploadFrom=dist --uploadTo=demo-fe/test --config=./oss.test.conf.json",
    "uploadAli:prod": "upload-cloud-aly --uploadFrom=dist --uploadTo=demo-fe/prod --config=./oss.prod.conf.json",
},

可视化的构建平台：使用可视化的自动化构建平台，用来版本构建部署和版本回滚。
文件安全：将敏感文件如SDK密钥文件（config=./oss.prod.conf.json）存放于构建平台，通过构建平台的权限管理确保文件的安全性。
日志监控：利用构建平台的日志记录构建和发布信息，用于追踪问题。
紧急发布保障机制：代码中配置的依赖包和执行脚本，可以在线下本地执行紧急发布，确保线上与线下操作的一致性。

当然，在正常情况下，我们也需要采用 CI/CD 和 Git 的处理方式。在这里，我继续沿用了之前团队已经使用的 GitLab 方法。

迁移步骤文档

为了使各项目的前端负责人能够自行进行迁移，编写了一份详细的迁移步骤文档。这份文档经过多次测试和调试，确保操作简单、统一标准、详细全面，以及配备风险回滚机制。

自上而下的迁移顺序： 文档按照迁移的逻辑流程进行组织，确保用户可以按照文档的顺序进行同步执行，避免混淆和操作错误。
图文并茂： 在文档中加入截图和文字说明，直观展示每个迁移步骤。
迁移步骤简洁： 每个迁移步骤都被精简为必要的操作，避免冗余步骤，需要注意的位置，也会配置注意事项。
一致的迁移步骤： 无论是哪个项目，迁移步骤都是一致的，避免了不同项目之间存在步骤上的差异性，降低学习成本。
风险回滚机制： 文档中明确规定了风险回滚的步骤和方法，确保在发生问题时能够迅速恢复到迁移前的状态。

前端架构大升级，资源架构重塑全攻略（图文详解）

总结起来，私有云迁移的步骤可以分为两个主要阶段：

前期准备：（对迁移项目进行准备）
- 代码方面：Hash打包处理、添加镜像源、上传脚本配置；
- 构建平台：更改构建配置、执行构建发布；
正式迁移：（主应用项目）
- 开关Queue：Push 迁移项目；
- 构建平台：执行构建发布；（此步骤是确保迁移生效的关键。如果未执行此步骤，所有项目都不会受到影响。）

通过这一整体的流程，迁移步骤文档的目的在于确保各项目前端负责人能够简捷地完成资源迁移，减少操作复杂性，提高整个迁移过程的可控性。

资源迁移保障措施

前端架构大升级，资源架构重塑全攻略（图文详解）

为了确保资源迁移的顺利进行，并保障加载的正常性，可以按照以下步骤进行：

确认资源上传到阿里云OSS：申请OSS存储桶权限，确保你有足够的权限来管理和访问存储桶内的资源。检查上传资源的文件后缀和上传日期等信息，确认迁移资源已经成功上传到了阿里云OSS中。
测试单个资源是否可以请求到：使用浏览器或工具如Postman，发送请求获取单个资源。这可以帮助你确认单个资源是否可以正常请求到。
检测迁移后项目所有资源是否正常加载：拦截原项目的入口文件地址，并将其代理到新的资源上（这里我用的是GoRes谷歌浏览器插件），浏览器将直接加载新的资源，从而可以检测迁移后整个项目的所有资源是否能够正常加载。

总结

这次前端资源架构设计和重塑，为私有云服务系统带来改进与优化，尤其是系统在稳定性、资源的高效管理、简捷维护以及良好的扩展性方面。

A. 稳定性提升

资源对服务器的依赖性过高，因此解耦前端与私有云对象存储等服务，从而促使前端能够独立运行并保证稳定性。

前端架构大升级，资源架构重塑全攻略（图文详解）

此外，前端静态资源的频繁访问也会增加服务器负担，因此减少对服务器的依赖可以间接降低服务器的成本。

B. 资源管理体系建立

统一存储位置：通过将所有资源存储在统一的存储位置，可以方便地对其进行管理和访问。这不仅提高了资源管理的集中度，还简化了资源的维护。团队成员在各自的权限下，不仅能轻松地查找、更新和删除资源，还能够轻松地监控和追踪资源的使用情况。
便于管理：通过资源管理体系的建立，可以实现对各类资源的统一管理。这包括对不同资源、不同环境的资源进行集中管理和维护。例如统一配置跨域配置和缓存配置等。
灵活度高和扩展性强：资源统一管理提供灵活的配置选项，使得可以方便地根据具体需求进行定制。例如，可以轻松地调整文件处理的逻辑、添加额外的业务逻辑处理等。