杀鸡用牛刀-博客架构迭代记录
发布时间：2022年4月21日
生命不息，折腾不止。
目前这个博客站点是20年底搭建的，其中有一些19年记录的内容其实都是将在政采云时内部或者社区分享的文章重新整合而来，文章的时间手动矫正为初版发布的时间。
搭建博客初版架构时，在一系列博客类程序中选择了 Hexo ，Hexo 程序的优点在于：
- 纯静态资源，打开速度快，便于浏览器做缓存，对SEO友好
- 对服务器性能要求低，只要能够运行 Nginx 就可以搭建起整个网站。
- 稳定性高，不依赖任何三方服务。配置好 nginx 转发规则后，即使服务器宕机，重启后也会自动恢复
在使用 Hexo 生成静态资源后，在对外提供服务方面，共进行了三次迭代
单 Nginx 服务
存在时间：2020年底 - 2021年中
架构图
架构解析
此版本的架构十分简单，就是一个普通的单 Nginx 服务，外部用户访问页面时，Nginx 根据请求信息在本地静态资源目录中查找对应文件并返回给用户。此时整合服务器中只部署了一个博客服务，因此也不存在网关的概念。
整套架构部署起来简单快速稳定，唯一的问题在于每次应用更新后都需要将静态资源同步至服务器中，更新体验较差。
二、k3s 集群
存在时间：2021年中 - 2022年初
架构图
架构解析
本阶段的架构的变动比较大，从一开始的单 Nginx 纯静态服务到集群，基本属于从刀耕火种到坦克飞机了。架构做如此大变动的契机在于腾讯云额外赠送了一台国内的服务区。此时加上之前已有的一台服务器，整合满足了搭建集群的最低条件，搭建一个自己可以任意操作的集群也便于更深入地学习 k8s/docker 相关的知识。
因为我这两台服务器配置较低，每个节点均为 2c2g，用来搭建一个完整的 kubernetes 集群有些吃力，于是最终选择了对性能要求较低的k3s。集群搭建完成后，在两个节点上，共对外提供了三个服务，一个 NodeJS 后台应用以及两个静态的博客应用。由于一个入口对应了多个应用，需要某种机制将用户的访问请求转发到目标应用上，于是 Ingress 网关便出现了。
从上图中，我们可以看到用户访问我们应用时，请求在集群内部的完整流转径。用户访问某个服务时，首先会将请求发送到集群的主节点，接着配置的 Ingress 网关会根据已有的规则与用户的访问路径进行匹配，将请求转发至某一个 SVC，SVC 将请求负载均衡后发送至实际对用户提供服务的应用。
集群中，为了屏蔽外部直接访问我们内部的应用，集群中的服务都不会直接对外提供服务，而是通过 Svc 作为中间方来串起用户和应用之间的数据传递，因此就像架构图中所示，请求的转发路径实际上是这样的：Ingress - Svc - Pod
具体的集群中相关概念，如：Ingress、Deployment、Service等基础概念，请查看博客中的这篇文章 从零搭建一个k3s集群 ，在此就不再赘述，后续我也会将我的 k8s 学习笔记整理后陆续更新到博客中
Docker-Compose
存在时间：2022年3月 - 至今
架构图
架构解析
由于腾讯云的轻量应用服务器即将到期，在单机上 k3s/k8s 此类集群无法正常运行，因此必须要对原有的架构进行调整。
在公司内，除了集群管理相关内容外，对 Docker-Compose 技术也有了一些基础的了解。该方案的优点在于，只需要一台性能足够的服务器，通过 YAML 声明的方式，即可搭建起一整套的应用服务。在多应用 + 单机的条件下，Docker-Compose 技术成了最好的选择。
其实从整体架构上来说，该版本的架构设计与第一版单 Nginx 服务并无太大区别。如果我们将第一版架构中的 Nginx 单机服务调整为基于 Docker 的网关应用，将所有的博客、NodeJS 应用经过 Docker 的封装并运行，大致就实现了这套架构。
不过，相较于手动维护每一个 Docker 容器，Docker-Compose 提供了一套自动管理应用生命周期以及将所有容器组成内网的机制，容器时间的访问只需要通过容器的名称即可，高效且无感知。
同时，通过将静态博客服务容器化的方式，避免了同步静态资源、手动重启后台服务等劳动，再结合 Github 提供的 CI/CD 能力，可以实现：代码变动 - 项目构建 - 镜像打包/推送 的流水线服务。除去更新镜像版外的一切重复劳动，大大提高了更新部署的效率。
总结
正如第一句所说：生命不息，折腾不止。
虽然博客不大，月访问量不足 1000 IP，但每次架构的调整都让我对不同的技术有了更深的应用与理解。每一次的调整都不是一帆风顺，都会遇到各种各样的问题，但定位问题、查找解决方案、解决问题并实现预期目标后，它会给我带来无与伦比的快乐。