网站技术架构全解析：从入门到实战

学习目标

从一次浏览器访问开始，理解前端、后端、数据库、部署、安全与静态网站的完整协作方式，并能根据项目规模选择不过度设计的技术方案。

一、一次访问背后发生了什么

当用户在浏览器输入域名并访问网站时，通常会经历下面的过程：

输入域名
↓
DNS 查询域名对应的 IP 地址
↓
与服务器建立连接（HTTP 为 TCP；HTTPS 还会进行 TLS 握手）
↓
Web 服务器或应用服务器处理请求
↓
浏览器收到 HTML、CSS、JavaScript、图片等资源
↓
浏览器解析、渲染页面，并按需发起后续请求

这里最容易混淆的是“服务器”和“后端”。服务器是一台运行程序的计算机或云资源；后端则是运行在服务器上的应用逻辑。纯静态网站可以只有 Web 服务器和静态文件，不一定需要数据库或自定义后端程序。

DNS、HTTP 与 HTTPS 的职责

• DNS：把 yilantinyu.cn 这样的域名解析为服务器 IP。
• HTTP：定义浏览器与服务器交换请求和响应的规则。
• HTTPS：在 HTTP 外增加 TLS 加密和身份校验，避免传输内容被轻易窃听或篡改。

HTTPS 不是“有证书就结束”。还应让 HTTP 自动跳转到 HTTPS，并确保网页中的接口、图片和脚本也使用 HTTPS，避免出现混合内容。

二、前端：用户实际看到的部分

前端最基础的三项技术仍然是 HTML、CSS 和 JavaScript：

技术	核心职责	常见问题
HTML	内容结构与语义	标题层级混乱、缺少图片替代文本
CSS	布局、颜色、响应式显示	小屏溢出、页面跳动、样式重复
JavaScript	交互、表单、异步请求	依赖过多、错误处理不足、接口地址写死

HTML 应优先表达内容结构，例如每个详情页只有一个主标题（H1），正文再从 H2 开始。CSS 负责视觉呈现，JavaScript 则只在确实需要交互时加入。

框架并不是所有网站的必需品

Vue、React、Angular 适合复杂交互、登录态、多页面数据协作或单页应用。它们的价值在于组件化、状态管理和工程化，而不只是“用了虚拟 DOM”。

对于以文章阅读为主的网站，静态生成器通常更简单：先把 Markdown 构建成 HTML，再让 Nginx 或静态托管服务直接返回文件。这样访问链路短、故障点少、搜索引擎也更容易读取正文。

三、后端、接口与数据库

当网站需要用户注册、订单、权限、实时数据或复杂查询时，通常需要后端和数据库。

浏览器
↓ API 请求
后端路由 / 控制器
↓
业务逻辑与权限校验
↓
数据库、缓存、文件存储或第三方服务

后端可使用 Java、Python、Node.js、PHP、Go 等不同技术。选型不应只看“性能排名”，还应考虑团队熟悉度、生态、部署方式、可维护性和业务复杂度。

数据存储怎么选

• MySQL / PostgreSQL：适合需要事务、关联查询和数据一致性的业务。
• Redis：常用于缓存、限流、会话或短期数据，不应替代所有长期存储。
• MongoDB 等文档数据库：适合文档结构变化频繁、查询模型明确的场景。
• 对象存储：适合图片、附件、音视频等大文件。

不存在“一个数据库解决所有问题”的通用答案。应先看数据结构、读写比例、查询方式、恢复要求和成本，再决定是否增加缓存或拆分存储。

四、部署层：让网站稳定对外提供服务

Nginx 的位置

Nginx 常放在网站访问入口，用于：

• 提供静态 HTML、CSS、JS、图片等文件
• 将特定路径转发给后端服务，例如评论或管理接口
• 配置域名、HTTPS 证书和 HTTP 跳转
• 设置访问控制、缓存和请求大小限制

反向代理不等于“万能安全层”。后台接口仍需要身份认证、输入校验和最小权限设计。

Docker、Kubernetes 与 CI/CD

Docker 解决的是“应用与依赖如何一致打包和运行”；Kubernetes 解决的是多容器、多机器环境下的调度和扩缩容。小型个人网站不必一开始就使用 Kubernetes，复杂度可能超过收益。

CI/CD 则是把测试、构建和发布流程自动化。即使没有完整流水线，也应做到：发布前构建、校验内容、保留 Git 历史、失败时可以回滚。

五、静态网站与 CMS 的区别

静态网站

静态网站将 Markdown、模板和资源预先构建为 HTML：

Markdown + 模板 + 图片
↓
静态站点生成器
↓
HTML / CSS / JS / 图片
↓
Nginx 或静态托管平台

优点是速度快、攻击面相对小、服务器资源需求低；限制是在线编辑、登录、数据查询等动态能力需要额外服务支持。

CMS

CMS 不是“没有后端”，而是已经集成了内容管理后台、数据库和常见业务功能。WordPress 这类 CMS 适合希望快速获得可视化管理能力的场景，但仍需要更新、备份、插件管理和安全维护。

六、本网站的实际架构

当前网站采用的是“静态网站为主，少量动态能力补充”的方案：

Markdown 学习笔记与页面模板
↓
Eleventy（11ty）构建静态网站
↓
Nginx 提供 HTTPS 访问
├─ 静态页面、图片与样式
├─ /twikoo 评论接口反向代理
└─ 受认证保护的内容管理接口
↓
服务器保存源码并自动同步 GitHub

这个方案没有为文章展示引入数据库：绝大多数访问只是读取构建好的页面。评论和在线内容管理是单独的动态服务，通过 Nginx 的指定路径接入。

这种分层的好处是：阅读页面保持简单稳定；需要写入数据的功能单独限制权限；网站源码还有 GitHub 历史可追溯。

七、安全与可靠性不是最后才补的功能

网站上线后，至少应关注这些基础项：

• HTTPS：所有公开访问和后台入口统一使用 HTTPS。
• 身份认证：后台不只依赖隐藏路径，还应有账号、口令或更完善的登录机制。
• 密钥管理：SSH 私钥、接口 token、邮箱授权码不要写入公开仓库或前端文件。
• 输入处理：后端校验输入，数据库使用参数化查询，页面输出注意 XSS 风险。
• 备份与回滚：保留 Git 提交、网站发布备份和重要数据备份。
• 日志与更新：定期查看服务日志，及时更新系统、Nginx 和依赖。

安全的目标不是追求“绝对不出问题”，而是在问题出现时减少损失、快速发现并能够恢复。

八、技术选型建议

项目类型	优先考虑	不必急着加入
个人博客、作品集	静态生成器、Git、Nginx、HTTPS	数据库、微服务、Kubernetes
内容网站、知识库	静态站点或 CMS、搜索、对象存储	复杂实时系统
中小业务系统	后端 API、关系型数据库、认证、日志	过早拆分微服务
高并发或多团队平台	缓存、队列、监控、自动化部署	一次性重构全部系统

技术选型的原则是：用当前问题需要的最小复杂度解决问题，同时为未来增长留出合理空间。

本篇小结

网站架构不是一张固定的技术清单，而是根据内容类型、访问量、团队能力和维护成本做出的取舍。

从个人静态网站开始，先理解域名、HTTPS、构建、部署、Git 和备份；等确实需要用户系统、实时数据或复杂业务时，再逐步加入后端、数据库、缓存和自动化能力。这样更容易建立稳定、可维护的网站系统。