建站初期这个网站编写初期，为了熟悉 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 程序。服务器也终于轻松了。接下来应该很长一段时间，都不会再想着把它拆回去了。