非得用微服务吗？

[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]

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