Microsoft 365 Message Center档案馆

1.8k
Microsoft365Graph APIGithub ActionsGitee

Microsoft 365 Message Center档案馆 ​

Microsoft 365 的 Message Center（消息中心） 很重要，它会通知我们所有微软云服务的更新，包括有的没的的更新以及的更新。

正因为有这些有的没的的更新，导致了大部分管理员都会忽略掉这些通知。

就好比写日记，正经人谁写日记啊？

riji

你不写，我不写，总得有人写吧，那就让AI去写吧？

所以这个站点诞生了：

Microsoft 365 Message Center Archive

它的目标很简单：把 Microsoft 365 Message Center 变成一个可以浏览、搜索、分享的公开归档页面。

更重要的是，在原有项目基础上增加了 由世纪互联运营的 Microsoft 365 中国区 Message Center 数据，让全球云和中国云的消息可以放在同一个界面里查看。

技术栈：一个平平无奇的静态站点 ​

这个网站不是一个复杂的后台系统，它更像是一个“提前把饭做好、访问时直接端上桌”的静态站。

主要技术栈包括：

  • Next.js 13
  • React 18
  • TypeScript
  • Tailwind CSS
  • TanStack React Table
  • Radix UI / shadcn 风格组件
  • Lucide React 图标
  • GitHub Actions
  • Microsoft Graph API

next.config.mjs 里使用了：

js
output: 'export'

这意味着构建时会把页面导出成静态文件。用户访问时，不需要现场查询 Graph，也不需要动态服务器实时渲染。数据已经在构建阶段准备好了。

简单说就是：

Graph 负责“进货”，Next.js 负责“摆货架”，用户只负责“逛超市”。

Gitee的用途 ​

由于国内网络访问Github时好时坏，所以我把代码仓库放在了能稳定访问的Gitee上。

使用Gitee之后，需要增加额外的两步：

  • 在Github上增加了一个workflow，用来定时定量的同步国际版的数据。
  • 通过本地cron任务定时同步Gitee的数据源至本地。

两个脚本分别如下：

github-sync-to-gitee.yml
shell

name: Sync to Gitee

on:
  push:
    branches:
      - main
      - master
  schedule:
    - cron: '0 * * * *'
  workflow_dispatch:

jobs:
  sync:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source repo
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup SSH key
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.GITEE_SSH_PRIVATE_KEY }}" > ~/.ssh/gitee_actions
          chmod 600 ~/.ssh/gitee_actions
          ssh-keyscan gitee.com >> ~/.ssh/known_hosts

      - name: Configure git
        run: |
          git config --global user.name "github-actions[bot]"
          git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com"

      - name: Add Gitee remote
        run: |
          git remote add gitee "${{ secrets.GITEE_REMOTE }}" || git remote set-url gitee "${{ secrets.GITEE_REMOTE }}"

      - name: Push to Gitee
        env:
          GIT_SSH_COMMAND: "ssh -i ~/.ssh/gitee_actions -o StrictHostKeyChecking=yes"
        run: |
          git push gitee HEAD:main --force
gitee-sync-to-local.yml
shell
#!/bin/bash

export PATH=/usr/bin:/bin

REPO_DIR="/path/Gitee_MC"
SRC_DATA_DIR="$REPO_DIR/@data/"
DST_DATA_DIR="/path/21V_MC/@data/"
LOG_FILE="/path/update_mc.log"

echo "==== $(date '+%F %T') start ====" >> $LOG_FILE

cd "$REPO_DIR" || exit 1

# 更新仓库
/usr/bin/git fetch origin >> $LOG_FILE 2>&1
/usr/bin/git reset --hard origin/main >> $LOG_FILE 2>&1

# 同步数据
/usr/bin/rsync -av --delete "$SRC_DATA_DIR" "$DST_DATA_DIR" >> $LOG_FILE 2>&1

echo "==== $(date '+%F %T') done ====" >> $LOG_FILE

数据如何获取？ ​

数据分为2部分，分别是全球云数据和中国云数据，全球云的数据是通过Github Action同步至Gitee仓库，然后写入：

text
@data/messages.json
@data/archive/

其中 @data/messages.json 是全球云当前消息列表，@data/archive/ 用来保存全球云的历史消息。

而中国区的数据则是直接通过 Microsoft Graph 获取 Service Announcement Message，放在：

text
@21v_data/21v_message.json
@21v_data/21v_archive/

有人问我，为什么全球云的数据不直接通过Graph API获取呢？

我说，我没有全球云的账号，所以不能调用全球云的API，只能通过Github拉别人的仓库。

最重要的一步：合并，但不打架 ​

数据合并逻辑在：

text
lib/messages.ts

这里同时导入两个数据源：

ts
import dataMessages from '@/@data/messages.json'
import data21vMessages from '@/@21v_data/21v_message.json'

合并策略很克制：

  • 先保留全球云 @data/messages.json
  • 再加入 21Vianet 中不重复的消息
  • 如果两个数据源里出现同一个 Message ID，以全球云数据为准
  • 最后按 LastModifiedDateTime 倒序排序

这相当于做了一个“主数据源优先”的合并层。UI 不需要知道消息到底来自全球云还是中国云，只要调用：

ts
getAllMessages()
getMessageData(id)

就可以拿到合并后的结果。

同一个按钮，跳到不同的管理中心 ​

还有一个很实用的小细节：详情页里的 Message ID 可以跳回 Microsoft 365 管理中心。

但全球云和中国区的管理中心 URL 不一样，所以项目里做了来源判断：

ts
getMessageCenterUrl(id)

如果消息来自全球云，就跳到：

text
https://admin.microsoft.com/#/MessageCenter/:/messages/{id}

如果消息来自 21Vianet，就跳到：

text
https://portal.partner.microsoftonline.cn/AdminPortal/Home#/MessageCenter/:/messages/{id}

这让用户不需要思考“这条消息属于哪个云”。点进去，系统自己带路。

前端体验优化 ​

首页是一个消息列表，使用 TanStack React Table 实现。它支持按 ID 和标题过滤，列表里可以看到：

  • Message ID
  • 标题
  • 服务名称
  • 最后更新时间
  • 是否 Major Change

重大变更会有一个提示。服务名称用 Badge 展示，比如 Exchange、Teams、SharePoint、Microsoft 365 suite 等。

详情页则展示：

  • Message ID
  • Service
  • Published / Last Updated
  • Tag
  • Roadmap ID
  • Act by
  • Platforms
  • Summary
  • More information

每条消息在构建时都会通过 generateStaticParams() 生成静态详情页，所以访问速度很直接：不是现场查数据库，而是打开一页已经生成好的档案卡。

自动化：让网站自己更新 ​

项目里有2个GitHub Actions，服务器端有2个crontab jobs。通过这些自动化的流程让网站自己主动更新信息。

全球云数据同步通过 workflow 定时跑，站点构建也通过 workflow 定时部署。

已经Archive的消息怎么看？ ​

目前Archive的策略是消息最后一次更新的日期超过一年的，会自动放到archive文件夹下，archive的消息是不展示的。

虽然不展示，但是消息依然是处于保留状态。如果想看的话，得加钱。

总结 ​

Microsoft 365 全球云和中国区经常会有不同节奏的功能发布、管理入口和公告内容。对于做跨区域支持、迁移、合规或客户服务的人来说，只看任何一个区域云的消息是不够的。

这个站点现在可以把两边的消息放在一起：

  • 搜索更方便
  • 分享更方便
  • 查历史更方便
  • 对比全球云和中国区更方便
  • 不必每次都登录管理中心才能看一条公告

它不是要替代租户里的 Message Center。真正做生产决策时，仍然应该以自己租户里的 Message Center 为准。因为不同租户看到的消息可能不同，订阅、区域、功能启用状态也会影响可见内容。

但作为一个公开归档和检索工具，它已经很实用。❤️❤️❤️

深度理解编码方法论
我的2025