type
status
date
slug
summary
category
tags
create_time
Jul 6, 2025 04:05 PM
icon
password
my_create_time
🧭 背景介绍
在我刚开始搭建个人博客网站时，只是简单使用一台云服务器部署了 Nginx + Docker。
随着访问量增加、服务增多（如：统计系统、评论系统、nCalendar自研产品等），我逐渐发现单机架构在稳定性、可维护性、扩展性方面面临诸多挑战。
这篇文章记录了我的网站架构从「单机时代」逐步演化到「云原生架构」的全过程，希望对也在探索的朋友有所启发。
PS：刚好近期做完了最终的架构升级，就分享一下~
🛤️ 演进路线
1️⃣ 单机部署：V1.0 版本
V1.0 是我刚正式建站时使用的(在这之前也体验用了下免费的
vercel服务)，买个域名和很小的服务器(2核4G)就开始上了，当时追求的就是快速上线，也没想很多。应用都是采用的
Docker进行部署，好处是一键部署，资源共享，可以部署更多的服务。存在的问题是一旦宕机，服务全停，毕竟都在一台服务器上，同时带宽有限(1M)导致性能也很慢。
架构图如下：
2️⃣ 使用公共云服务：V2.0 版本
随着时间的推移，虽然以上架构简单，但我也很快发现了很多问题，比如有以下几点比较严重的：
- 性能慢：直接访问源站，不仅性能很慢，也不安全。
- 存储不足：默认服务器磁盘就
20G，除去系统本身再加上日志文件和镜像文件，我网站还有很多图片等静态资源肯定是放不下的，如果要升级存储成本又会很高。
- 数据库瓶颈：虽然初期 SQLite 是够用，但是随着服务的增多，不仅多用户是刚需了，对性能也有所要求，原先的太慢了。
基于以上几点，我决定了使用更多的公有云服务来解决这些问题，如：CDN 提高性能、OSS 外部图床、RDS 云数据库，这就诞生了 V2.0 版本，架构如下：
3️⃣ 云原生转型：向 Kubernetes 迁移（无限扩容）
随着服务部署的越来越多，目前已部署近
20个服务了，基本把单机服务器资源压榨的很厉害，更多新的服务也跑不起来了。此时有两种常见选择：
- 升级服务器配置：将2核4G升级到4核8G，但治标不治本，未来还得不断升级，并且成本很高。
- 购买新的服务器：另一种选择是购买新的服务器，然后自己组集群。
以上方案不仅服务器成本高而且也会随着服务器的增多维护成本急剧上升，同时还会造成严重的资源浪费，毕竟不是经常会出现服务器资源利用的刚刚好。
因此还有另外一种选择就是容器服务，这里简单介绍一下阿里云ACS容器服务，它的模式是Serverless，用户无需关注底层节点及集群的运维管理，你用多少资源就付多少钱，并且支持近乎无限的扩容（缺点是需要熟悉k8s, 存在一定学习成本）。
最终整体架构图如下：
这个 V3.0 版本还新增了 ALB 负载均衡，用于将流量转发到原有的ECS服务器和ACS集群。
该版本预计将会持续较久的时间，不仅新的服务会部署到ACS集群内，原有的也会逐步迁移。
不过ECS服务器还是要保留的，一方面是已经包年了，另一方面是涉及到备案，如果把服务器释放了，阿里云可能会申请取消备案，那又很麻烦了。
✅ 总结
最后总结一下架构演进是需求驱动的结果，而非一蹴而就的设计。
从单机走向云原生，不是为了“赶潮流”，而是为了解决实际问题，如性能瓶颈、快速扩容、降低成本等。
云原生不是终点，而是更精细化运维的开始。
谨以此篇分享给同样也在建站的朋友，欢迎大家讨论交流。
PS：后续我将再分享一下此次架构升级的详细过程，中间也踩了不少坑，希望能给大家带来帮助~
有关文章的任何疑问，欢迎您在底部评论区留言，一起交流~
若文章对您有帮助，欢迎 请我喝杯咖啡~
- 作者:青萍叙事
- 链接:https://blog.lusyoe.com/article/website-arch-upgrade
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
