建站初期
这个网站编写初期，为了熟悉 Spring Cloud 微服务架构，我便用 Spring Cloud 编写了这个网站。
当时总共分为了四个服务，分别是：
- eureka_server：注册服务中心
- gateway_service：网关
- pub_api：核心 API 调用接口
- blog_api：博客相关 API 调用接口
- ai_api: AI相关API调用接口 (后来因服务器资源紧张,临时关掉了)
面临的问题
刚开始其实没觉得有什么问题，毕竟那时候做这个网站的主要目的之一就是学习 Spring Cloud，所以该拆的服务拆了，该用的组件也都用了。
但是后来随着服务器上运行的东西越来越多，服务器资源也开始越来越紧张。
这几个 Java 服务，每个运行起来基本都要占用几百 MB 的内存。
看起来一个服务几百 MB 好像还好，但是四个服务加起来就已经接近两个 G 了。
而我的服务器总共也才 4G 内存。
除了这几个服务之外，还要运行 MySQL、Redis、Nginx，以及其他一些东西。
所以后来经常能看到服务器的内存已经所剩无几。
其实对于我这个网站来说，继续使用微服务已经没有太大的意义了。
微服务当然有它的优点，但是这些优点更多还是建立在项目足够大、业务足够复杂、团队人数足够多的情况下。
而我的网站本质上就是一个个人网站。
访问量不算大，业务也没有复杂到需要把不同模块单独部署，更不存在几十个人同时开发不同服务的情况。
为了一个个人网站，常驻一个 Eureka，再跑一个 Gateway，然后博客接口和公共接口还分别启动两个 JVM。
多少有点为了微服务而微服务了。
集思广益 推倒重写
所以最后还是决定把它重新改成单体项目。
本来最开始想的是直接把几个 Spring Cloud 服务合并成一个 Spring Boot 项目，这样至少可以少启动几个 JVM。
但是后来想了一下，既然都准备重新折腾了，不如顺便换个语言。
于是就有了现在这个 Go 版本。
其实我之前并没有正经写过 Go。
对 Go 的印象基本就停留在性能不错、内存占用低、部署方便这些比较表面的地方。
真正开始写以后，最大的感受反而是简单。
至少对于这种个人项目来说确实很舒服。
不需要 Eureka，不需要 Gateway，也不用一堆服务之间互相调用。
编译以后就是一个二进制文件：
nys-go-api
上传到服务器，然后：
nohup ./nys-go-api > app.log 2>&1 &
就跑起来了。
甚至连 Java 环境都不需要。
当然，真正让我觉得这次重构没有白折腾的，还是服务器内存。
之前 Spring Cloud 那几个服务运行的时候，光 Java 进程加起来就能吃掉接近两个 G 的内存。
改成Go后的优点
换成 Go 单体之后，我重新看了一眼服务器：
总内存 3.6G，当前已使用甚至不到 1G，可用内存还有 2.4G 左右。
服务器瞬间像空出来了一大半。
这种感觉还是挺明显的。
以前登录服务器第一反应是：
“还有多少内存？”
现在基本不用考虑这个问题了。
java微服务项目多到一只手数不过来
Go项目就非常清爽 (或者说是单体项目)
结语
当然，这并不是说 Go 就一定比 Java 好，也不是说微服务不好。
如果现在让我重新评价当初用 Spring Cloud 写这个网站这件事，我还是觉得没有选错。
因为当时我的目的本来就是学习微服务。
Eureka、Gateway、服务注册、服务发现、服务之间的调用，这些东西如果没有真正自己搭过一遍，光看文档其实很难有什么感觉。
只是现在这个网站已经过了拿来练 Spring Cloud 的阶段。
对于一个访问量不大的个人网站来说，我现在更在意的是：
简单、稳定、省资源、方便维护。
那微服务反而成了一种负担。
有时候技术选型可能就是这样。
并不是越复杂越好，也不是用了更多技术就代表项目更高级。
Spring Cloud 用了几年，最后又被我亲手删掉了。
但也不能说这几年白用了。
至少现在我知道，什么时候需要微服务，也知道什么时候根本不需要。
目前 Go 版本已经基本把原来的功能迁移过来了。
从四个 Java 服务，变成一个 Go 程序。
服务器也终于轻松了。
接下来应该很长一段时间，都不会再想着把它拆回去了。