为了在本地模拟线上环境，我差点把我的 Mac 搞崩了

还在用 Nginx + Docker-compose 折腾微服务？听我一句劝

社区里总在讨论：“新项目，应该上单体还是微服务？”

我看过无数技术文章，大佬们分析得头头是道，但我每次自己写点东西，最后都老老实实地用单体。

原因很简单：我害怕。不是怕把代码拆开，而是怕拆开之后，那一堆烂摊子。

一次让我崩溃的尝试

我最近的一个小项目，一开始就是个单体。后来想加一个独立的通知服务，专门用来发邮件和钉钉消息。我想，这不就是微服务的最佳实践吗？

于是我照着网上的教程，开始了我的噩梦：

• 启动服务：为了让主应用和通知服务两个容器能同时跑起来，我花了一整天研究 Docker-compose。

• 服务通信：为了让主应用能调用到通知服务，我又去死磕 Nginx 的反向代理配置。

• 管理数据库：两个服务需要各自的数据库，这意味着我还要处理不同的端口和复杂的连接配置。

两天下来，代码没写几行，项目里多了一堆乱七八糟的配置文件，我感觉自己不像在写代码，像在当网管。

朋友的一句话，点醒了我

周末和朋友吐槽这件事，他听完后，说了一句让我至今印象深刻的话： “你不是搞不定微服务，你是搞不定网络。”

他接着说：“我们对微服务的恐惧，其实都是工具造成的。如果工具足够好，部署十个服务应该和部署一个一样简单。”

顺着他的推荐，我试了一下 Sealos。

这才是微服务的简单玩法

Sealos 的体验，彻底颠覆了我之前的认知。我把我那个失败的尝试在上面重做了一遍：

1.部署两个服务？过程就像填表格。我打开了 Sealos 的“应用管理”，点击“新建应用”。先给主应用起名叫main-app，然后在镜像栏填入它的 Docker 镜像地址。接着，在下面设置它需要对外暴露的端口号，并用鼠标拖动滑块，分配了一点CPU和内存。用完全相同的方式，我又创建了第二个叫notification-service的应用。最后点击“部署”，两个应用就都平稳地运行起来了。

2.服务之间如何通信？平台自动搞定。这是最神奇的地方。过去我需要配置 Nginx，但在 Sealos 里，它们天生就能互相找到对方。我的主应用代码里，需要调用通知服务时，请求的地址可以直接写成通知服务的应用名，平台会自动把这个名字解析成正确的内部地址。我什么网络配置都不用做。

3.每个服务要自己的数据库？应用市场一键启动。我在平台“数据库”里一键启动了两个 PostgreSQL 实例，分别命名为main-db和notify-db。接着，我回到主应用的配置里，添加了一个环境变量，把数据库主机地址的值设置成main-db。通知服务也一样。它们就这样，各自精准地找到了自己的数据库，简单得不可思议。

整个过程，我没有写一行 YAML，没有配一次 Nginx，甚至没有登录一次服务器。我之前花了整整两天都没搞定的事，在 Sealos 上，只用了不到十分钟。

写在最后

经过这次体验，我终于想明白了。

单体还是微服务这个选择，对于我们普通开发者来说，根本不是一个架构设计的哲学问题，而是一个纯粹的工具问题。

当我们手里只有锤子和钉子的时候，造个小板凳还行，想去造个大衣柜，自然会觉得痛苦不堪。Sealos 给我的，就是一套完整的专业工具。它让我可以不用关心那些复杂的底层细节，只需要专注于我的业务逻辑，自由地把我的应用拆分或组合成任何我想要的样子。