VedAstro 是一个免费开源的吠陀占星（Vedic Astrology）项目，本文带你拆解它的部署架构：前端采用Blazor WebAssembly单页应用，托管在Azure Static Web App静态存储上，再由Azure CDN 规则引擎解决 SPA 路由 404 与 SEO 静态页问题，计算密集的 API 则运行在 Azure Functions。整套架构几乎零服务器成本，非常适合想要"前端重、后端轻"的开源项目参考。

一、整体架构：一张图看懂 VedAstro 部署分层

VedAstro 把项目拆成四个相互独立的部分：核心计算库（Core Library）、API 库（API Library）、客户端（Client）以及面向各平台的分发形式。占星计算逻辑全部集中在 .NET 核心库中，Web 端只是一个"调用者"。

官方 README 中用一张 ASCII 图概括了线上请求流向：

+--------+ +------------------------+ +------------------+ | User | <------+ | Website | -------------> | API | | | +------> | - Blazor WebAssembly | <------------- | - Azure Functions| +--------+ GUI | - Azure Static WebApp | XML | | +------------------------+ +------------------+

可以看到三个关键点：

• Website：Blazor WebAssembly 前端 + Azure Static Web App 静态托管
• API：Azure Functions 无服务器计算服务
• User 浏览器：直接运行 .NET 代码（WebAssembly），与 API 通信

二、前端实战：为什么选 Blazor WebAssembly

打开 Website/Website.csproj，可以看到几个关键配置：

• Microsoft.NET.Sdk.BlazorWebAssembly：标准 Blazor WASM 项目模板
• TargetFramework为net8.0，开启PublishTrimmed裁剪，减小 .wasm 体积
• 通过Flavor区分AOT_ON/AOT_OFF两种构建，注释里坦诚写着 AOT 在 Android Chrome 上存在问题，可随时切换

启动入口 Website/Program.cs 做了两件与部署相关的事：

1. 注册一个Timeout设为无限的HttpClient（因为占星计算耗时较长，不能靠默认超时）
2. 注入自定义的UnhandledExceptionSender，把未处理异常上报到服务端日志——官方注释说这确保"地球上任何一次崩溃都不会被忽视"

而 Website/wwwroot/index.html 是整个 SPA 的外壳：它先显示一个加载动画，挂好#blazor-error-ui错误兜底 UI，最后才以defer方式加载_framework/blazor.webassembly.js启动应用。所有 CSS/JS 第三方库（Bootstrap、Chart.js、Tabulator 等）都走公共 CDN。

💡 这套结构意味着：服务器上根本没有 .NET 进程。所有 C# 代码都在浏览器里运行，静态资源放 Blob Storage 即可。

三、一键部署到 Azure Static Web App：最快发布步骤

发布流程被压缩在一个脚本里——Website/Start.ps1：

dotnet run swa deploy ./bin/Release/net7.0/publish/wwwroot --deployment-token

• 第一行本地调试；第二行用swaCLI 把wwwroot发布目录上传到 Azure Static Web App，通过 deployment-token 免登录认证
• 发布后资源落在 Azure 的 Blob Storage，前端由 Azure CDN 加速分发

配合 Website/staticwebapp.config.json 里的navigationFallback（所有未命中文件的路径 rewrite 到/index.html），Static Web App 层先做第一轮 SPA 兜底。

四、CDN 规则引擎实战：Blazor 直接访问页面不 404

Blazor SPA 部署在静态存储上有个经典难题：用户直接输入/LifePredictor.html这类深层链接时，服务器上并没有这个文件，直接 404。VedAstro 的解法是在 Azure CDN 规则引擎（Rules Engine）里加一条精确的 URL 重写规则，只放行"真正的页面导航请求"：

命中后执行两个动作：把路径重写（rewrite）回/让 Blazor 前端接管路由，并在响应头追加rule-engine: StopBlazorDirectPage404便于排查。规则引擎的原始截图如下：

README 的 Design Decision Notes 里还提到另一类规则用途：Handling SEO bots via Rules——搜索引擎爬虫访问时返回干净、静态的 HTML 而不是 JS 应用。仓库里Website/wwwroot/seo/目录正是一套为此准备的纯 HTML 页面（Website/wwwroot/seo/index.html、Horoscope、LifePredictor 等工具页各有一份），配合sitemap.xml做 SEO 收录。

缓存怎么刷？项目把 CDN 刷新命令也存成了文件——Website/CDNPurge.txt：

az cdn endpoint purge --resource-group VedAstro --profile-name CDNProfile --name vedastro --content-paths "/*"

五、域名与路由：一条 CDN 如何分出 Web 和两套 API

README 记录了 2023 年 3 月的域名转发设计，三条链路全部走 Azure DNS + Azure CDN：

• Web：vedastro.org→ 域名注册商 → Azure DNS → Azure CDN → Web Blob Storage
• API 稳定版：api.vedastro.org→ Azure DNS → Azure CDN → 稳定版 API 服务器
• API Beta 版：beta.api.vedastro.org→ Azure DNS → Azure CDN → Azure 上的 Beta API

也就是说，同一个 CDN 端点通过规则引擎把不同的子域/路径路由到不同后端（api.vedastro.org/...与/nlp/...走 API，其余走静态站），证书则由 Let's Encrypt ACME 机器人（Azure Function）自动续期管理。

六、后端 API：Azure Functions 隔离模式 + Docker 自托管

API 项目（API/Program.cs）只有十几行代码，核心是ConfigureFunctionsWorkerDefaults()，说明它运行在Azure Functions 隔离宿主（isolated worker）上，无服务器按需计费。

API/Dockerfile 则提供本地/自建部署路径：基于azure-functions/dotnet-isolated官方镜像，用sdk镜像做 build → publish 多阶段构建，最终复制到final阶段。Dockerfile 注释特别强调"路径值至关重要，因为它们是大多数失败的原因"。

七、关键文件清单：按这张表就能找到架构证据

八、总结：这套架构值得借鉴的 3 个点

1. 计算下沉到浏览器：占星计算跑在 Blazor WebAssembly 里，静态托管即可服务全球用户，成本极低
2. 规则引擎替代网关：用 CDN Rules Engine 同时完成 SPA 防 404、API 子域路由、SEO 爬虫处理三件事，省掉一层反向代理
3. 命令即文档：部署脚本、CDN 刷新命令、设计决策全部以文件形式留在仓库里，新人接手一眼就能看懂

如果你想亲自体验，可以 clone 仓库后按 Website/Start.ps1 的两行命令本地跑通前端，再对照上表逐一查看各模块源码。