非得用微服务吗？

一开始我用 go 写了个单体架构的小说网站。
后来感觉业务流程没有梳理好，模型也有些乱，打算重构。
研究了微服务，ddd 什么的，我的目的是能够在用户增加的情况下能够很方便的提升负载能力。
但是我发现要划分好多微服务出来，但是就我一个人来开发，有必要弄得那么复杂吗？
而且边界也不好划分啊，就怕到最后互相调用，性能下降不说，改动一个功能，可能就得改动好几个服务，部署好几次。

能同时部署几个单体应用来负载均衡吗？
或者在单体应用里，对某些路由实现微服务？
如何监控到底是哪些接口占用资源高呢？

Godjack

2024-01-01 19:52:44 +08:00

当然不是非得用微服务，前些年掀起了一阵微服务热，我最近时不时会在 hacker news 首页上看到一些反思微服务的文章

https://blogs.newardassociates.com/blog/2023/you-want-modules-not-microservices.html

https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices.html

> 后来感觉业务流程没有梳理好，模型也有些乱，打算重构。

不管是否用微服务，都要把模块划分好

> 研究了微服务，ddd 什么的，我的目的是能够在用户增加的情况下能够很方便的提升负载能力。

单体架构也能「方便」(对于你的小说应用来说应该够用了)提升负载能力。

有时间的话可以看看这个 https://icyfenix.cn/architecture/architect-history/

hangszhang

2024-01-01 20:46:07 +08:00

组织架构决定系统架构，你这就一个人，单体就好

afeiche

2024-01-02 11:32:46 +08:00

以前我们领导天天让我把系统改微服务，都让我顶回去，微服务部署、运维、监控都得有，要是公司不提供这些，自己搞折腾死了

shellcodecow

2024-01-02 14:09:24 +08:00

根据实际的情况出发，流量很一般不需要自动横向扩容，什么微服务，容器化都没必要..

不过既然你是用 go 我觉得可以学习下一些现成的框架..没必要自己研究这些，这些都是面向领导开发的

me1onsoda

2024-01-02 16:44:57 +08:00

回过头来看，很多微服务都是开发给自己简历贴金用的

petergui

2024-01-02 18:22:05 +08:00

个人觉得是基于几层：
1. 开发人员和项目的数量
2. 流量特点，热点服务（有多热？），热点路径
把这些分析清楚了，自然就清楚微服务不微服务。楼上说的对你需要的是高可用。
微服务架构本身提供的应该是多节点多服务隔离，管理，发现，扩展等功能便捷性。

xycost233

2024-01-03 16:22:41 +08:00

估算一下你未来的用户规模，然后纵向切割，横向扩展，只要纵向切割得好，横向业务耦合度高一点问题也不大

zx900930

2024-01-04 09:44:28 +08:00

技术选型是服务实际需求的，如果你们预估的业务规模不会大规模横向扩张，没有多个项目组分开开发发版的需求，根本就没必要上微服务。

danielxxx

286 天前

14 年，后端开发 10 几个人。cto 和架构师都是新来的，上来就给原来.net 一顿重构成 java 微服务，当时微服务的 rpc 也不稳定，别说 springcloud 和 dobbo 了，那会儿 dubbo 没人用基本。
于是领导自己搞了一套 rpc ，后端基于 ddd 开发，有 facade 层，开发只关心业务代码，controller 不用管，吭哧写了 2 年后来进了阿里内网，换成了 hsf 。
所以有时候不是技术框架不合适，而是领导战略要求。

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/1004852

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.