微前端架构下 Redux 与 MobX 共存的 CI/CD 及数据持久化方案

平台向微前端架构的迁移决策已定。随之而来的并非一片坦途，而是更具体的实现分歧。负责高频交易模块的 A 团队，坚持使用 Redux，理由是其严格的单向数据流和可追溯性对金融业务的审计需求至关重要。而负责市场营销活动模块的 B 团队，则倾向于 MobX，因为其响应式特性和较少的样板代码能极大提升迭代速度。

技术委员会的核心议题迅速从“Redux 与 MobX 的优劣”转变为一个更棘手的工程问题：如何构建一个统一的平台，使其能够支撑这两种截然不同的状态管理方案，同时不牺牲开发体验、部署效率和数据模型的一致性。这意味着我们需要一个能处理异构前端的 CI/CD 流水线，以及一个能与两种状态库优雅交互的后端数据持久化策略。

方案A：强制统一技术栈

最直接的思路是强制所有微前端应用统一技术栈，例如，全部采用 Redux。

优势分析:

1. CI/CD 简化: GitLab CI/CD 流水线可以基于一套模板创建。编译、测试、代码扫描和部署的脚本可以高度复用，极大地降低了 DevOps 的维护成本。
2. 知识共享: 团队间的开发者可以无缝切换，因为他们面对的是相同的技术范式。新人入职的培训成本也更低。
3. 依赖管理: 共享库、基础组件的开发会非常简单，无需考虑对多种状态管理库的兼容性。
4. 数据交互: 状态的格式、获取和持久化逻辑可以标准化，与后端 NoSQL 数据库的交互模型也得以统一。

劣势分析:

1. 扼杀创新与效率: 对于 B 团队这类需要快速响应市场变化的业务，Redux 繁琐的样板代码（Action, Reducer, Dispatch）会成为一种负担，降低开发效率。强迫他们使用不顺手的工具，会直接影响业务交付速度。
2. 团队自主性受损: 微前端的核心思想之一是团队自治（”You build it, you run it”）。强制统一技术栈与这一理念背道而驰，可能导致顶尖工程师流失。
3. 技术选型僵化: 无法根据具体场景选择最优解。交易模块确实从 Redux 的可预测性中受益，但营销模块使用 MobX 的收益同样巨大。一刀切的方案是典型的架构懒政。

一个为“统一 Redux 方案”设计的 .gitlab-ci.yml 片段可能如下，其结构清晰但缺乏弹性：

# .gitlab-ci.yml for a Redux-only world

variables:
  NODE_IMAGE: node:18-alpine

.base_job:
  image: $NODE_IMAGE
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - .npm/

before_script:
  - npm ci --cache .npm --prefer-offline

stages:
  - setup
  - test
  - build
  - deploy

install_dependencies:
  stage: setup
  script:
    - echo "Dependencies installed."

unit_test:
  stage: test
  script:
    - npm run test:unit
  artifacts:
    when: always
    reports:
      junit: junit.xml

lint_check:
  stage: test
  script:
    - npm run lint

build_app:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - build/

这个方案在工程上是“干净”的，但在组织和业务层面可能是有害的。

方案B：拥抱异构技术栈

另一个方向是接受并管理这种技术多样性。平台工程团队的职责不是消除差异，而是构建一个足够强大的基础设施来包容差异。

优势分析:

1. 团队赋能: 允许各业务团队根据自身产品的特点和团队成员的技术栈偏好，选择最合适的工具，最大化开发效率和产品质量。
2. 架构弹性: 系统更具弹性，未来可以方便地引入新的状态管理库（如 Zustand, Valtio），而不需要对整个平台进行颠覆性改造。
3. 技术吸引力: 一个开放和包容的技术环境对吸引和留住优秀工程师更具优势。

劣势分析:

1. 基础设施复杂度剧增: CI/CD 流水线必须具备动态识别和处理不同技术栈的能力。
2. 跨应用通信: 微前端之间的通信变得复杂。如果一个 Redux 应用需要和 MobX 应用交互，直接共享 Store 是不可能的，必须依赖于更上层的通信机制，如 Custom Events 或路由传参。
3. 状态持久化: 如何设计一个通用的数据层，既能为 Redux 提供纯粹的、可序列化的数据，又能与 MobX 的可观察对象（Observables）协同工作？
4. 运维成本: 平台团队需要理解并维护多种技术的构建和测试环境，增加了心智负担。

最终选择与理由：拥抱并管理复杂性

我们最终选择了方案 B。决策的核心逻辑是：平台的目标是提升业务交付的效率和质量，而不是追求工程上的整洁。通过在基础设施层增加投资来管理复杂性，换取业务团队的敏捷性和自主性，是符合微前端架构精神的正确权衡。

平台工程团队的任务清单因此变得清晰：

1. 构建一个与状态管理无关的、抽象的数据获取层。
2. 设计一条能识别项目技术栈并执行相应逻辑的动态 GitLab CI/CD 流水线。
3. 定义一套微前端之间的标准通信协议。

核心实现概览

1. 抽象数据层与 NoSQL 持久化

我们决定开发一个名为 @platform/data-client 的内部 NPM 包。这个包负责所有与后端 API 的通信，并以一种框架无关的方式返回数据。后端的数据库选用 MongoDB，其灵活的文档模型非常适合存储前端不同模块所需聚合的、非结构化的视图状态。

假设我们有一个用户配置页面，由两个微前端组成：“基础信息”模块（Redux）和“偏好设置”模块（MobX）。它们都依赖同一个用户文档。

MongoDB 文档结构示例 (users collection):

{
  "_id": "user-123",
  "profile": {
    "name": "Alice",
    "email": "alice@example.com",
    "registrationDate": "2023-01-15T10:00:00Z"
  },
  "preferences": {
    "theme": "dark",
    "notifications": {
      "email": true,
      "sms": false
    }
  },
  "metadata": {
    "lastLogin": "2023-10-27T09:00:00Z",
    "version": 2
  }
}

@platform/data-client 的实现:

这个客户端内部使用 axios 或 fetch，但对外暴露简单的方法。关键在于它返回的是纯粹的 JavaScript 对象，而不是任何特定状态库的实例。

// packages/data-client/src/index.ts

import axios, { AxiosInstance } from 'axios';

// 模拟API地址
const API_BASE_URL = process.env.API_URL || '/api';

interface UserProfile {
  name: string;
  email: string;
  registrationDate: string;
}

interface UserPreferences {
  theme: 'dark' | 'light';
  notifications: {
    email: boolean;
    sms: boolean;
  };
}

class DataClient {
  private client: AxiosInstance;

  constructor() {
    this.client = axios.create({
      baseURL: API_BASE_URL,
      timeout: 5000,
      headers: { 'Content-Type': 'application/json' },
    });

    // 在这里配置请求拦截器，用于注入认证Token等
    this.client.interceptors.response.use(
      (response) => response.data,
      (error) => {
        // 统一的错误处理和日志记录
        console.error('API Error:', error.response?.data || error.message);
        return Promise.reject(error);
      }
    );
  }

  async fetchUserProfile(userId: string): Promise<UserProfile> {
    // API端点设计为可以按需获取文档的一部分
    const data = await this.client.get(`/users/${userId}?fields=profile`);
    return data.profile;
  }

  async fetchUserPreferences(userId: string): Promise<UserPreferences> {
    const data = await this.client.get(`/users/${userId}?fields=preferences`);
    return data.preferences;
  }

  async updateUserPreferences(userId: string, prefs: Partial<UserPreferences>): Promise<UserPreferences> {
    // 使用 PATCH 方法进行局部更新
    const data = await this.client.patch(`/users/${userId}/preferences`, prefs);
    return data.preferences;
  }
}

// 导出一个单例
export const platformDataClient = new DataClient();

在 Redux 微前端中集成:

Redux 的集成遵循其标准模式：使用 thunk action 来处理异步请求。

// micro-frontends/profile-app/src/store/profileSlice.ts

import { createSlice, createAsyncThunk } from '@reduxjs/toolkit';
import { platformDataClient } from '@platform/data-client';

export const fetchProfile = createAsyncThunk(
  'profile/fetch',
  async (userId: string, { rejectWithValue }) => {
    try {
      const profileData = await platformDataClient.fetchUserProfile(userId);
      return profileData;
    } catch (error) {
      return rejectWithValue('Failed to fetch profile');
    }
  }
);

const profileSlice = createSlice({
  name: 'profile',
  initialState: { data: null, status: 'idle', error: null },
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(fetchProfile.pending, (state) => {
        state.status = 'loading';
      })
      .addCase(fetchProfile.fulfilled, (state, action) => {
        state.status = 'succeeded';
        state.data = action.payload;
      })
      .addCase(fetchProfile.rejected, (state, action) => {
        state.status = 'failed';
        state.error = action.payload;
      });
  },
});

export default profileSlice.reducer;

在 MobX 微前端中集成:

MobX 的集成则更加直接，通常在 store 的 action 中调用。

// micro-frontends/preferences-app/src/store/PreferencesStore.ts

import { makeAutoObservable, runInAction } from 'mobx';
import { platformDataClient } from '@platform/data-client';

class PreferencesStore {
  theme: 'dark' | 'light' = 'light';
  notifications = { email: false, sms: false };
  status: 'idle' | 'loading' | 'error' = 'idle';

  constructor() {
    makeAutoObservable(this);
  }

  async loadPreferences(userId: string) {
    this.status = 'loading';
    try {
      const prefs = await platformDataClient.fetchUserPreferences(userId);
      // runInAction 用于在异步操作后安全地修改状态
      runInAction(() => {
        this.theme = prefs.theme;
        this.notifications = prefs.notifications;
        this.status = 'idle';
      });
    } catch (error) {
      runInAction(() => {
        this.status = 'error';
      });
    }
  }

  async toggleEmailNotifications(userId: string, enabled: boolean) {
    // 乐观更新
    const originalValue = this.notifications.email;
    this.notifications.email = enabled;

    try {
      await platformDataClient.updateUserPreferences(userId, { 
        notifications: { email: enabled } 
      });
    } catch (error) {
      // 失败回滚
      runInAction(() => {
        this.notifications.email = originalValue;
      });
      // 可以在这里向用户显示错误提示
    }
  }
}

export const preferencesStore = new PreferencesStore();

通过这种方式，数据获取逻辑被统一封装，而状态管理则由各个微前端自由选择。NoSQL 文档模型的灵活性也得到了充分利用，API 可以轻松地返回文档的子集，避免了数据过度获取。

sequenceDiagram
    participant Component as React Component
    participant DataClient as @platform/data-client
    participant API as Backend API
    participant MongoDB as NoSQL DB

    Component->>+DataClient: fetchUserProfile("user-123")
    DataClient->>+API: GET /api/users/user-123?fields=profile
    API->>+MongoDB: findOne({_id: "user-123"}, {projection: {profile: 1}})
    MongoDB-->>-API: Returns profile document fragment
    API-->>-DataClient: { profile: { ... } }
    DataClient-->>-Component: Returns plain JS object
    Component->>Store: Dispatches action with data (Redux) or updates observable (MobX)

2. 动态化的 GitLab CI/CD 流水线

这是支撑异构方案的核心。我们利用 GitLab CI/CD 的 rules:exists 关键字来检测项目中是否存在特定文件，从而动态地决定执行哪个任务。

约定:

• 使用 Redux 的项目，在 src/store/ 目录下必须有一个 redux 文件夹。
• 使用 MobX 的项目，在 src/store/ 目录下必须有一个 mobx 文件夹。

.gitlab-ci.yml 实现:

# .gitlab-ci.yml for a hybrid world

variables:
  NODE_IMAGE: node:18-alpine

stages:
  - setup
  - validate
  - test
  - build
  - deploy

.base_job:
  image: $NODE_IMAGE
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - .npm/
  before_script:
    - npm ci --cache .npm --prefer-offline

install_dependencies:
  stage: setup
  extends: .base_job
  script:
    - echo "Dependencies installed."

# --- Validation Jobs ---
lint_code:
  stage: validate
  extends: .base_job
  script:
    - npm run lint

# --- Test Jobs - The Dynamic Part ---
.test_template:
  stage: test
  extends: .base_job
  artifacts:
    when: always
    reports:
      junit: coverage/junit.xml
      cobertura: coverage/cobertura-coverage.xml

# Job for Redux projects
test:redux:
  extends: .test_template
  script:
    - echo "Running Redux-specific test suite..."
    # 可能会有针对 Redux store 的特定测试覆盖率命令
    - npm run test -- --coverage --testPathPattern=redux
  rules:
    - if: '$CI_COMMIT_BRANCH'
      exists:
        - 'src/store/redux/**/*' # 检测是否存在Redux目录

# Job for MobX projects
test:mobx:
  extends: .test_template
  script:
    - echo "Running MobX-specific test suite..."
    # MobX 测试可能不需要特殊命令，但可以分离以备将来之需
    - npm run test -- --coverage --testPathPattern=mobx
  rules:
    - if: '$CI_COMMIT_BRANCH'
      exists:
        - 'src/store/mobx/**/*' # 检测是否存在MobX目录

# A fallback job if neither is detected, maybe for pure component libraries
test:generic:
  extends: .test_template
  script:
    - echo "Running generic test suite..."
    - npm run test -- --coverage
  rules:
    - if: '$CI_COMMIT_BRANCH'
      when: on_success
    - when: never # This job only runs if the others don't match. An explicit `when: never` on the base case can be tricky. A better approach is to ensure rules are mutually exclusive or use workflow rules.

# --- Build Job ---
build_application:
  stage: build
  extends: .base_job
  script:
    - echo "Building application..."
    # Build a command might be the same, but this structure allows for divergence
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 day

# Deploy stage would consume build artifacts
# ...

这个流水线通过 rules:exists 实现了“配置即约定”。只要微前端项目遵循文件结构约定，CI/CD 就能自动运行正确的测试套件。这既保持了灵活性，又通过约定施加了必要的规范。

graph TD
    A[Start Pipeline] --> B{Check File Structure};
    B -- "src/store/redux/** exists" --> C[Run test:redux Job];
    B -- "src/store/mobx/** exists" --> D[Run test:mobx Job];
    C --> F[Build Job];
    D --> F[Build Job];
    B -- "Neither exists" --> E[Run test:generic Job];
    E --> F;
    F --> G[Deploy Job];

架构的扩展性与局限性

该方案为平台带来了极大的扩展性。当未来出现新的、更优秀的状态管理库时，我们只需要在 CI/CD 配置中增加一个新的检测规则和对应的任务，并在 @platform/data-client 中确保其兼容性即可，核心架构无需变动。

然而，这套方案并非没有代价，其局限性也相当明确：

1. 平台维护成本: 平台工程团队必须对 Redux 和 MobX 都有深入的理解，以便能够调试和优化两种技术栈的构建和测试流程。这增加了团队的技术广度要求。
2. 跨端通信的挑战: 虽然我们定义了使用 Custom Events 进行通信，但这是一种弱约束。在复杂的交互场景下，保证事件的命名、载荷结构的一致性，需要额外的工具和强有力的团队规范来保障，否则会演变成一场调试噩梦。
3. 服务端渲染（SSR）复杂度: 如果未来需要引入 SSR，为异构的微前端进行状态注水（Hydration）将是一个巨大的挑战。需要在服务端构建一个复杂的聚合层，分别执行不同微前端的渲染逻辑，并收集它们的状态，再统一注入到客户端。这比单一技术栈的 SSR 要复杂一个数量级。
4. 共享逻辑的边界: @platform/data-client 很好地抽象了数据获取，但对于更复杂的共享业务逻辑（例如，表单校验规则、权限判断），如果这些逻辑需要深度嵌入状态管理器，抽象的难度会大大增加。强行抽象可能会导致 API 臃肿且难以使用。这些问题是我们下一阶段需要攻克的堡垒。