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