非得用微服务吗？

[tianshunovel2]

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

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

[ruxuan1306]

没必要，微服务的架构本质来自组织架构。

[Hurriance]

认同一楼的，技术的演化并不完全来自技术本身

[frankies]

没必要

[lovedebug]

没必要，微服务和单体都有自己的场景，千万不要为了微服务而微服务

[gaobh]

等你有十万用户量再改微服务也不早

[BeijingBaby]

单体够你用到项目消失😆

[hefish]

楼上的大佬们说的对，根据自己需要来搞。合适够用是原则。

[est]

微服务是用来 ppt 的东西啊。这玩意从概念到推广到实施都是一家软件外包公司发明的啊。。
你没必要跟自己过意不去。

[CHUB]

这么说吧，以前我们组人多，每个人负责自己的模块，自己交自己的，开发速度嘎嘎快

现在人也少了，项目也少了，偶尔会几个人都集中在同一个项目里干活，互相卡进度的时候想死，merge 的时候也想死，以及，维护老项目那一坨，改一个小的有很多个地方都要一起改，也很想死，有利有弊吧。

省流：微服务适合很多个开发者一起干活的场景，人少单例完全够用。

[bringyou]

说一个曲线救国的歪路子：
正好 op 用 go 语言，可以试试 Google 出的[service weaver 框架]( https://opensource.googleblog.com/2023/03/introducing-service-weaver-framework-for-writing-distributed-applications.html)，它的一个特色就是允许以微服务的架构来写代码，但最终可以部署成为一个单体应用。

[kuituosi]

先搞明白什么是微服务
不是用了微服务框架就叫微服务

[fregie]

你需要的不是微服务，是容器化+无状态服务，要扩容直接加副本

[FrankAdler]

你这种，模块划分清楚就行了。规模大了，团队大了，涉及到不同研发（团队）负责不同功能开发，单独迭代单独发版啥的才是考虑拆分的时候

[blackeeper]

一个人开发，没必要弄得这么复杂

问题 1：可以，前面部署个 NG ，部署 N 个单体应用，然后负责均衡就可以了
问题 2：你可以在 NG 上转发到你拆分的微服务应用
问题 3：监控应用接口是多个层面的，要统计分析：有哪些接口，以及接口的 [调用频次，应用处理时间、SQL 处理时间、调用其它的时间、消耗 CPU 、内存，磁盘 IO]

[cheng6563]

把表弄好一点就够了

[Kumo31]

微服务不解决你说的负载能力问题

[pigspy]

单体架构足够你用到网站倒闭了

[codewld]

微服务各模块独立自治，不会一坏皆坏，提高的是可用性，和负载能力没有直接关系。
如果只是希望提升负载能力，应该考虑将服务改成无状态，然后按需扩容服务层。

[fgsqqq]

微服务 是使 单个服务 的业务内聚性更高
不同的业务 放到不同的地方
对系统解耦 维护扩展更高效

当然 还得看项目规模 和复杂度
小项目 或几个人玩的 可以不用
大厂的 服务 基本上 微服务 因为 业务复杂，承接功能多
抽取独立成一个 ，更易于 维护

[GeekGao]

任何架构模式都是顾及了康威定律而设计的。一个人的项目不需要遵守这些复杂模式。

[Godjack]

当然不是非得用微服务，前些年掀起了一阵微服务热，我最近时不时会在 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]

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

[afeiche]

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

[shellcodecow]

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

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

[me1onsoda]

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

[petergui]

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

[xycost233]

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

[zx900930]

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

[danielxxx]

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