微服务真的很好用吗?

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

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

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

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

纯粹个人想法,感兴趣的同学希望可以发表一下意见,多沟通,多学习。谢谢
12125 次点击
所在节点    程序员
63 条回复
lcdxiangzi
2019-01-23 11:04:42 +08:00
@passerbytiny #28 金融行业天生适合微服务吗?按照我对金融业务场景的理解,事务性管理以及业务逻辑严格把控的需求。和微服务不算是很搭吧?
单说事务性管理,在微服务中就要搞出一堆控件来实现各种补偿机制吧?
从 CAP 角度来看,我反而觉得金融机构会主动放弃 P,单体系统不是更完美吗?(不考虑项目硬件成本的前提下)

不知道是不是我没有理解清楚?还是?
lcdxiangzi
2019-01-23 11:06:04 +08:00
@yamedie #36 我觉得这种调调最要命了,如果单纯从项目发展的角度看,不考虑其他的外围因素。
lcdxiangzi
2019-01-23 11:12:52 +08:00
@dremy #39 我不是很认同呢,微服务确实配有很多好用的工具,比如 K8S 或者 docker,但是真的复杂业务场景,业务逻辑流程都会变长,在微服务里面,一次优化或者迭代可能就涉及到多个服务模块,在测试或者部署时,模块内部的工作量确实降低了,但是服务间的调用关系和部署顺序,我认为变得复杂的多了。如果考虑到这些技术的出现时间。

窃以为,这些工具可能就是为了填坑才引进的呢。。。
demomacro
2019-01-23 11:22:56 +08:00
看到十三楼的,就想到把 shit 山拆成一份份的小 shit...
passerbytiny
2019-01-23 13:07:31 +08:00
@lcdxiangzi #33 给你说个最简单的例子,从 A 银行转账到 B 银行,你准备做一个怎样的“单体”系统能让 A 银行和 B 银行都接受。
事务性这个就更扯淡了,就一个最简单的行内取钱操作,就涉及到个人账户、支行账户、总行账户等多方面的数据,想要原子提交,你准备让用户等多久。
ericls
2019-01-23 13:10:15 +08:00
十个可用性 99%的服务 加起来 就是一个 90% 可用性的服务了

还不算 传输的 overhead
lcdxiangzi
2019-01-23 13:25:09 +08:00
@passerbytiny #45 上面这些业务场景我都理解,但是我了解到的大行,确实是原子操作。为什么五大行到现在离不开 IBM 的大机,就是他们为了保住 C 和 A,而不得已,必须放弃 P 了。
至少我是这样理解的。
passerbytiny
2019-01-23 13:46:45 +08:00
@lcdxiangzi #39 请举出事实。

再纠正你一点错误:CAP 是分布式系统的理论,当你讨论到 CAP 的时候,已经是分布式系统了。下面摘自维基百科:

在理论计算机科学中,CAP 定理( CAP theorem ),又被称作布鲁尔定理( Brewer's theorem ),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:[1][2]

一致性( Consistency ) (等同于所有节点访问同一份最新的数据副本)
可用性( Availability )(每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据)
分区容错性( Partition tolerance )(以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在 C 和 A 之间做出选择[3]。)

根据定理,分布式系统只能满足三项中的两项而不可能满足全部三项[4]。理解 CAP 理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致,即丧失了 C 性质。如果为了保证数据一致性,将分区一侧的节点设置为不可用,那么又丧失了 A 性质。除非两个节点可以互相通信,才能既保证 C 又保证 A,这又会导致丧失 P 性质。
lcdxiangzi
2019-01-23 13:54:35 +08:00
@passerbytiny 这个是我混淆概念了,想表达类似的意思,所以拿过来用了。
arthas2234
2019-01-23 14:20:36 +08:00
微服务就是扯淡的,就跟区块链一样,是个公司都想插一脚,显得高大上,实际上没有几个用得上。有这个时间还不如把自己的项目优化好
Kraken
2019-01-23 14:24:50 +08:00
我觉得分布式系统本身就是为了解决高流量下的高并发问题的 小公司确实不适合上微服务 第一项目没到那个体量,第二 上了微服务之后有很多的问题需要解决,比如分布式事务什么的。有解决这些问题的时间,用单机架构可能已经写好上了第一版了,而且流量小的时候也不会崩,项目到了一定体量再考虑重构也不是不行。 不过用 springcloud 对开发来说可以提升技术,没什么不好的。
lcdxiangzi
2019-01-23 14:27:18 +08:00
https://dzone.com/articles/microservices-please-dont
这篇文章,大家感兴趣可以看看
lcdxiangzi
2019-01-23 14:31:23 +08:00
@guolaopi 我个人的理解,大家谈 SOA 好像更多的是一种架构思路,微服务好像更偏向具体的技术实现。
我也觉得这两个东西没有太大差别,/DOGE
guolaopi
2019-01-23 14:41:25 +08:00
@lcdxiangzi 所以就是和十年前的分布式现在叫云了一个意思吗?
luoer
2019-01-23 14:49:55 +08:00
凡事不是非黑即白的。 一定要说“微服务垃圾”才是正确? 单体系统有单体系统的优势,微服务自然也有也有优劣,技术选型需要对症下药。 我们有时候就是太迷恋新技术新架构,从来不考虑优劣确实是个问题。
dhq
2019-01-23 18:02:25 +08:00
单机部署多个服务的网络消耗代价也很大吧
imwalson
2019-01-23 19:43:49 +08:00
之前的公司两个人开发项目用什么微服务架构,徒增各种各样的麻烦,搞的总是不能按时交付项目,在我看来这种就是盲目跟风的结果
chanchan
2019-01-24 09:04:30 +08:00
@lihongjie0209 我就知道会有这图 哈哈哈
linhua
2019-01-24 09:41:26 +08:00
想到了 宏内核( monolithic kernel ) 和 微内核( microkernel )
Linux 系统就是宏内核 , 而 Google 正在开发的 Fuchsia 系统则是微内核的
cobol
2020-02-04 11:12:36 +08:00
@passerbytiny 哥们,看了你的回复,觉得你应该从来没有做过银行项目啊,你举的例子都是你自己想象出来的场景呢,
1.从 A 银行转账到 B 银行,你准备做一个怎样的“单体”系统能让 A 银行和 B 银行都接受。
你应该没听过人行的二代支付或者大小额系统,所以你并不清楚跨行是怎么个处理流程。
2.事务性这个就更扯淡了,就一个最简单的行内取钱操作,就涉及到个人账户、支行账户、总行账户等多方面的数据,想要原子提交,你准备让用户等多久。
你根本不清楚银行的账户体系,不懂什么叫客户账和内部户,所以你也不知道存取处理流程。

所以呢,自己不懂的东西,就不要言之凿凿的来教别人啊,你这样是误导了 @lcdxiangzi 楼主啊

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

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

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

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

© 2021 V2EX