3. 插件隔离概念：进程隔离 vs 线程隔离 vs 沙箱隔离，Backstage中的隔离策略选择

在Backstage插件架构中，隔离是保障平台稳定性与安全性的核心机制。不同的隔离级别决定了插件故障的爆炸半径、资源争用的程度以及运维的复杂度。本节将系统对比三种主流隔离模型，并给出Backstage场景下的选型建议。

3.1 三种隔离模型的核心差异

隔离的本质是限制故障域。下表从资源边界、故障影响、性能开销和适用场景四个维度进行对比：

3.2 Backstage中的隔离策略选择

Backstage默认采用进程级隔离作为主要策略，同时结合沙箱隔离处理不可信插件。具体选择逻辑如下：

• 核心插件（Core Plugins）：如catalog、scaffolder、techdocs，运行在Backstage主进程中，采用线程隔离（通过Node.js Worker Threads处理CPU密集型任务），降低延迟。
• 社区插件（Community Plugins）：推荐部署为独立微服务（进程隔离），通过Service-to-Service通信与主平台交互，避免插件故障影响核心。
• 第三方/不可信插件：必须运行在沙箱环境（如isolated-vm或WebAssembly），限制文件系统、网络和内存访问权限。

3.3 隔离策略的故障域对比

下图展示了三种隔离策略在Backstage架构中的故障域范围：

3.4 Backstage隔离策略选型决策树

在实际部署中，可以按照以下决策树选择隔离策略：

1. 插件是否来自官方或可信团队？
   • 是 → 使用线程隔离（Worker Threads）处理计算密集型任务
   • 否 → 进入下一步
2. 插件是否需要访问文件系统或网络？
   • 是 → 使用进程隔离（独立容器或进程）
   • 否 → 使用沙箱隔离（isolated-vm）
3. 插件是否对延迟敏感？
   • 是 → 优先线程隔离，避免IPC开销
   • 否 → 优先进程隔离，获得最强稳定性

3.5 配置示例：Backstage插件隔离策略配置

以下是一个典型的app-config.yaml片段，展示了如何为不同插件配置隔离策略：

backend:
  plugins:
    # 核心插件 - 使用线程隔离
    catalog:
      isolation: thread
      workerPoolSize: 4
    scaffolder:
      isolation: thread
      workerPoolSize: 2
    
    # 社区插件 - 使用进程隔离
    'plugin-jira':
      isolation: process
      command: 'node plugins/jira-backend/dist/index.cjs'
      healthCheck: '/health'
    
    # 第三方插件 - 使用沙箱隔离
    'plugin-untrusted':
      isolation: sandbox
      sandboxConfig:
        memoryLimit: 128
        cpuLimit: 0.5
        allowedModules: ['lodash', 'axios']
        deniedModules: ['child_process', 'fs']

3.6 隔离策略的监控与告警

无论选择哪种隔离策略，都需要建立对应的监控指标：