博客的发展3：将博客迁移至Azure并添加访问指标采集
内容提要
作者时隔三年更新博客，将静态网站迁移至Azure，使用AKS托管网站、Azure SQL存储数据，并新增访问指标采集，记录文章访问量、来源、设备等信息。CI/CD改用GitHub Actions，通过OIDC免密构建镜像并部署。作者称此举几乎无需运维，成本约每月七八十美元，后续计划将其他服务也迁至AKS。
延伸解读
从静态到动态：博客架构的演进动因
作者将博客从纯静态网站迁移到Azure上的动态架构，核心动因是添加访问指标采集。静态网站无法记录动态信息，而评论数据此前依赖GitHub Issues。新架构在AKS上托管网站，Azure SQL存储指标数据，实现了文章访问量、来源、设备等信息的采集。这反映了博客从单纯内容展示向数据驱动运营的转变，但作者也指出采集的IP哈希等数据可能涉及隐私，需关注合规性。
成本与运维：Azure免费额度与托管服务的平衡
作者利用微软员工每年150美元的Azure订阅，将网站和数据库迁移至Azure。AKS使用免费托管等级和最便宜的Standard_D2as_v5节点（2C8G），并开启自动伸缩（1-5节点）；Azure SQL Server提供免费额度（10万核心计算时间+32G数据）。估算每月花费70-80美元，主要来自节点虚拟机。这种方案几乎无需手动运维，数据库、扩缩容、TLS证书均由托管服务处理，适合个人项目在有限预算下获得接近生产级的体验。
CI/CD实践：基于OIDC的免密部署流程
作者将CI/CD从简单的GitHub Pages推送改为完整的容器化部署流程：推送代码后，GitHub Actions构建镜像、推送到ACR、登录AKS并触发Deployment更新。整个过程无密码参与，通过OIDC联邦身份认证关联Azure identity，该identity拥有AcrPush和AKS Cluster User Role权限。AKS和ACR之间通过Managed Identity认证拉取镜像。这种方案提升了安全性，也简化了密钥管理，但需要熟悉Azure的RBAC和OIDC概念。
未来优化方向：轻量化与统一运维
作者计划将其他用App Service和VM部署的服务也迁移到AKS，以统一运维流程并减少额外开销。同时，当前博客使用Next.js构建的镜像约300M，推送耗时，未来考虑用Go重写后端逻辑，前端改为Vite+React纯前端，最终构建十几M的纯Go二进制。这体现了对资源效率和运维简化的持续追求，也暗示了技术选型上对轻量级方案的偏好。
Q&A
为什么作者决定把博客迁移到Azure？
作者想添加访问指标采集，而纯静态网站无法记录动态信息；同时他拥有微软员工每年150美元的Azure订阅额度，之前未充分利用，于是借此机会将网站和数据库全部迁移到Azure。
迁移后博客的Azure架构是怎样的？
访问请求先到AKS，AKS上运行网站代码，使用Gateway API暴露服务，cert-manager自动签发TLS证书；数据存放在Azure SQL Server中。AKS使用免费托管等级，Node pool为Standard_D2as_v5虚拟机并开启自动伸缩（1-5节点）。
新的CI/CD流程是如何工作的？
推送代码后，GitHub Actions通过OIDC联邦身份认证关联到Azure identity，以该身份登录Azure，然后构建镜像、推送到ACR、登录AKS并触发deployment更新。整个过程无需密码，AKS和ACR通过Managed Identity认证拉取镜像。
博客现在采集哪些访问指标？
采集的信息包括：文章ID、访问总数、最后访问时间；每次访问的事件ID、时间、文章路径；访客标识、来源页面、推广来源、IP哈希；浏览器、操作系统、设备类型；是否机器人、状态码和耗时字段。
迁移到Azure后每月的成本大概是多少？
每月花费大约70到80美元，主要来自Node pool的虚拟机。作者有微软员工每年150美元的Azure订阅额度，勉强够用。
作者后续对博客和运维有什么计划？
后续打算将用App Service和VM部署的其他服务也迁移到AKS，以减少开销并统一运维流程。另外，考虑将博客逻辑改用Go编写，前端改为Vite+React纯前端，以构建更小的镜像（目前Next.js镜像约300M）。
