微服务真的很好用吗?

2019-01-22 17:22:34 +08:00
 lcdxiangzi
最近在翻 springcloud 的书,也理解微服务相对于单体系统的优势。
但是,学习过程中,感觉微服务架构带来的新的问题,实在是多,引入了各个模块来解决(打补丁)。

反观单体系统的问题,我认为大部分问题都是因为系统与业务场景配合不够默契,或者说系统解耦等方面设计不够合理导致的。在原有单体系统的设计思路上,如果可以下功夫去理解业务,从系统架构层面多下功夫(说的很虚,具体的要结合实际情况展开讨论)

回到现实,很多公司都积极向微服务转型,一些小公司(比如我们自己),就几个人的团队,个人感觉使用微服务并没有能够实现微服务的价值(真正复杂的系统、人头超过一定限度的团队规模可能更容易体现出微服务的价值)

是不是大家有点无脑跟风的意思啊?

纯粹个人想法,感兴趣的同学希望可以发表一下意见,多沟通,多学习。谢谢
11840 次点击
所在节点    程序员
63 条回复
artandlol
2019-01-22 17:26:52 +08:00
以前微博崩了,大都打不开,现在微博崩了,还能评论下。
lhx2008
2019-01-22 17:27:29 +08:00
是的,大部分就是跟风,单系统没有解决的问题,微服务也不会解决。
lhx2008
2019-01-22 17:31:56 +08:00
我认为微服务本质上是和人员组织有关的,单系统不适合几百人共同开发,所以才要切分,瞎分不知道有啥意义。
daveze
2019-01-22 17:33:14 +08:00
微服务我可以分别上线,分别优化,流量分离,单个服务非常聚焦,服务不要了直接丢弃。
ETiV
2019-01-22 17:34:07 +08:00
dynastysea
2019-01-22 17:34:29 +08:00
我觉得和业务形态也有关系,有些业务很适合解耦。即使拆分得很细维护成本也不高。有些则不同,本来耦合就打,拆开反而增加很多链式调用,这样得到的收益可能就不大了
libook
2019-01-22 17:43:29 +08:00
软件工程没有银弹,虽然我在用微服务架构,但不鼓励无脑从众,微服务思想只是个工具,在合适的地方好用,在不合适的地方不好用。

微服务背后其实是计算机科学上降低系统复杂度一种策略——分层解耦。所以只有在某个系统内部因功能互相耦合导致复杂度高的情况才适用,而且用也不是拆得越细越好,因为有些功能从业务上来讲就是一体的,比如订单和商品。

微服务化之后一方面功能模块之间使用有限的 API 进行沟通,只要 API 不变,内部变化的灵活性很高,不会出现牵一发动全身的问题;另一方面可以按功能模块拆成小团队,便于管理。

微服务规模到了一定程度就会遇到新的问题,比如一致性、响应时间、容灾,所以做设计的时候要充分考虑清楚得失,看究竟是否划算采用微服务思想。
lcdxiangzi
2019-01-22 17:45:18 +08:00
@artandlol 微博这种体量,我认为微服务时有意义的,但是除去这些大厂的产品,剩下的绝大多数产品的数量级都要小很多,大家再来套用微服务,成本和收益是否划得来,我觉得是要打问号的。
lcdxiangzi
2019-01-22 17:49:23 +08:00
@daveze 单个服务聚焦的同时,服务间的调用必然会增多。

@ all
其实说白了,这是一个度的问题,每个人对这个度的把握都是不一样的,说到底还是人的问题。。。
zzzzzzZ
2019-01-22 17:57:03 +08:00
大部分跟风,它只是架构而已,用不用看人

就像你说的,觉得很多小公司上微服务就是杀鸡用牛刀
这些年主要是有很多 P2P 公司,或者说金融相关(小额贷等等),它们要做相关的业务,不上就崩
公司再小也要拿这把牛刀才能砍

至于整个大环境动不动就谈微服务之类的,都是跟风,你不也最近跟风开始学了吗
PureWhiteWu
2019-01-22 17:58:14 +08:00
小流量小架构,没必要,微服务会引入很多额外的复杂的问题。
等真的规模上来了,微服务才有意义。
passerbytiny
2019-01-22 17:58:45 +08:00
Java 有一个很有意思的名词,企业级应用,以前的 Java EE,现在的 Jakarta EE。如果只是打算做个网站或者业务只有 CRUD,那么用微服务确实自讨苦吃。基本上,主程人数在 10 人以下,或者技术团队 50 人以下,微服务学习一下就行了,别真用。
lihongjie0209
2019-01-22 18:42:36 +08:00
[Imgur]( )
[Imgur]( )
[Imgur]( )
ColinWang
2019-01-22 19:06:59 +08:00
可以了解一下康威定律,大概意思就是系统设计的结构必定复制设计该系统的组织的沟通结构。
ShangAliyun
2019-01-22 19:11:13 +08:00
想明白必要性,在决定用不用。
我想说的是,面对用户量疯长。能简单的增加服务器数量来增加负载能力,那么微服务这种结构非常适用。
如果小企业,一个项目到 die 的一天还几百几千用户,那么使用微服务就没意义了
exiaohao
2019-01-22 19:49:52 +08:00
![]( )
cyril4free
2019-01-22 19:50:59 +08:00
取决于系统够不够大
jorneyr
2019-01-22 20:55:42 +08:00
可能大项目里的微服务中一个服务就提供上千个 API,而大多数系统可能一起也就提供百八十个 API,所以微到什么样子需要和服务一起讨论,微和不微不同情况下需要量化才知道好不好,没有统一的标准。
wangxiaoaer
2019-01-22 21:07:35 +08:00
互联网应用可以考虑微服务,企业应用就算了吧,到处复制、到处部署是个问题,虽然 docker 可以解决一些, 但是也麻烦。
salmon5
2019-01-22 21:15:37 +08:00
@artandlol 微博多少人的技术团队?市值多少亿?

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

https://www.v2ex.com/t/529531

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

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

© 2021 V2EX