这是一个创建于 365 天前的主题，其中的信息可能已经有所发展或是发生改变。
一开始我用 go 写了个单体架构的小说网站。
后来感觉业务流程没有梳理好，模型也有些乱，打算重构。
研究了微服务，ddd 什么的，我的目的是能够在用户增加的情况下能够很方便的提升负载能力。
但是我发现要划分好多微服务出来，但是就我一个人来开发，有必要弄得那么复杂吗？
而且边界也不好划分啊，就怕到最后互相调用，性能下降不说，改动一个功能，可能就得改动好几个服务，部署好几次。
能同时部署几个单体应用来负载均衡吗？
或者在单体应用里，对某些路由实现微服务？
如何监控到底是哪些接口占用资源高呢？
后来感觉业务流程没有梳理好，模型也有些乱，打算重构。
研究了微服务，ddd 什么的，我的目的是能够在用户增加的情况下能够很方便的提升负载能力。
但是我发现要划分好多微服务出来，但是就我一个人来开发，有必要弄得那么复杂吗？
而且边界也不好划分啊，就怕到最后互相调用，性能下降不说，改动一个功能，可能就得改动好几个服务，部署好几次。
能同时部署几个单体应用来负载均衡吗？
或者在单体应用里，对某些路由实现微服务？
如何监控到底是哪些接口占用资源高呢？
 |
1
ruxuan1306 2023-12-31 21:41:03 +08:00  8
没必要，微服务的架构本质来自组织架构。
|
 |
2
Hurriance 2023-12-31 22:21:49 +08:00
认同一楼的，技术的演化并不完全来自技术本身
|
 |
3
frankies 2023-12-31 22:22:56 +08:00 via Android
没必要
|
 |
4
lovedebug 2023-12-31 22:23:36 +08:00
没必要，微服务和单体都有自己的场景，千万不要为了微服务而微服务
|
 |
5
gaobh 2023-12-31 22:25:55 +08:00 via iPhone
等你有十万用户量再改微服务也不早
|
 |
6
BeijingBaby 2023-12-31 22:27:46 +08:00 via iPhone 2
单体够你用到项目消失😆
|
 |
7
hefish 2023-12-31 22:36:36 +08:00
楼上的大佬们说的对，根据自己需要来搞。合适够用是原则。
|
 |
8
est 2023-12-31 22:41:04 +08:00
微服务是用来 ppt 的东西啊。这玩意从概念到推广到实施都是一家软件外包公司发明的啊。。
你没必要跟自己过意不去。 |
 |
9
CHUB 2023-12-31 22:48:33 +08:00 via Android
这么说吧，以前我们组人多，每个人负责自己的模块，自己交自己的，开发速度嘎嘎快
现在人也少了，项目也少了，偶尔会几个人都集中在同一个项目里干活，互相卡进度的时候想死，merge 的时候也想死，以及，维护老项目那一坨，改一个小的有很多个地方都要一起改，也很想死，有利有弊吧。 省流：微服务适合很多个开发者一起干活的场景，人少单例完全够用。 |
 |
10
bringyou 2023-12-31 23:07:40 +08:00
说一个曲线救国的歪路子：
正好 op 用 go 语言，可以试试 Google 出的[service weaver 框架]( https://opensource.googleblog.com/2023/03/introducing-service-weaver-framework-for-writing-distributed-applications.html)，它的一个特色就是允许以微服务的架构来写代码，但最终可以部署成为一个单体应用。 |
 |
11
kuituosi 2023-12-31 23:12:10 +08:00
先搞明白什么是微服务
不是用了微服务框架就叫微服务 |
 |
12
fregie 2023-12-31 23:30:45 +08:00 4
你需要的不是微服务，是容器化+无状态服务，要扩容直接加副本
|
 |
13
FrankAdler 2023-12-31 23:36:18 +08:00 via Android
你这种，模块划分清楚就行了。规模大了，团队大了，涉及到不同研发（团队）负责不同功能开发，单独迭代单独发版啥的才是考虑拆分的时候
|
 |
14
blackeeper 2023-12-31 23:46:52 +08:00
一个人开发，没必要弄得这么复杂
问题 1：可以，前面部署个 NG ，部署 N 个单体应用，然后负责均衡就可以了 问题 2：你可以在 NG 上转发到你拆分的微服务应用 问题 3：监控应用接口是多个层面的，要统计分析：有哪些接口，以及接口的 [调用频次，应用处理时间、SQL 处理时间、调用其它的时间、消耗 CPU 、内存，磁盘 IO] |
 |
15
cheng6563 2024-01-01 00:36:47 +08:00
把表弄好一点就够了
|
 |
16
Kumo31 2024-01-01 00:59:58 +08:00
微服务不解决你说的负载能力问题
|
 |
17
pigspy 2024-01-01 11:48:52 +08:00
单体架构足够你用到网站倒闭了
|
 |
18
codewld 2024-01-01 13:42:52 +08:00 via iPhone 1
微服务各模块独立自治，不会一坏皆坏，提高的是可用性，和负载能力没有直接关系。
如果只是希望提升负载能力，应该考虑将服务改成无状态，然后按需扩容服务层。 |
 |
19
fgsqqq 364 天前
微服务 是使 单个服务 的业务内聚性更高
不同的业务 放到不同的地方 对系统解耦 维护扩展更高效 当然 还得看项目规模 和复杂度 小项目 或几个人玩的 可以不用 大厂的 服务 基本上 微服务 因为 业务复杂，承接功能多 抽取独立成一个 ，更易于 维护 |
 |
20
GeekGao 364 天前
任何架构模式都是顾及了康威定律而设计的。一个人的项目不需要遵守这些复杂模式。
|
 |
21
Godjack 364 天前
当然不是非得用微服务，前些年掀起了一阵微服务热，我最近时不时会在 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/ |
 |
22
hangszhang 364 天前
组织架构决定系统架构，你这就一个人，单体就好
|
 |
23
afeiche 364 天前
以前我们领导天天让我把系统改微服务，都让我顶回去，微服务部署、运维、监控都得有，要是公司不提供这些，自己搞折腾死了
|
 |
24
shellcodecow 364 天前
根据实际的情况出发，流量很一般 不需要自动横向扩容，什么微服务，容器化都没必要..
不过既然你是用 go 我觉得可以学习下一些现成的框架..没必要自己研究这些，这些都是面向领导开发的 |
 |
25
me1onsoda 363 天前
回过头来看，很多微服务都是开发给自己简历贴金用的
|
 |
26
petergui 363 天前
个人觉得是基于几层：
1. 开发人员和项目的数量 2. 流量特点， 热点服务（有多热？），热点路径 把这些分析清楚了，自然就清楚微服务不微服务。 楼上说的对 你需要的是高可用。 微服务架构本身提供的应该是多节点多服务隔离，管理，发现，扩展 等功能便捷性。 |
 |
27
xycost233 362 天前
估算一下你未来的用户规模，然后纵向切割，横向扩展，只要纵向切割得好，横向业务耦合度高一点问题也不大
|
 |
28
zx900930 362 天前
技术选型是服务实际需求的，如果你们预估的业务规模不会大规模横向扩张，没有多个项目组分开开发发版的需求，根本就没必要上微服务。
|
 |
29
danielxxx 93 天前
14 年，后端开发 10 几个人。cto 和架构师都是新来的，上来就给原来.net 一顿重构成 java 微服务，当时微服务的 rpc 也不稳定，别说 springcloud 和 dobbo 了，那会儿 dubbo 没人用基本。
于是领导自己搞了一套 rpc ，后端基于 ddd 开发，有 facade 层，开发只关心业务代码，controller 不用管，吭哧写了 2 年后来进了阿里内网，换成了 hsf 。 所以有时候不是技术框架不合适，而是领导战略要求。 |
Select Language