微服务真的很好用吗？

以前微博崩了，大都打不开，现在微博崩了，还能评论下。

是的，大部分就是跟风，单系统没有解决的问题，微服务也不会解决。

我认为微服务本质上是和人员组织有关的，单系统不适合几百人共同开发，所以才要切分，瞎分不知道有啥意义。

微服务我可以分别上线，分别优化，流量分离，单个服务非常聚焦，服务不要了直接丢弃。

我觉得和业务形态也有关系，有些业务很适合解耦。即使拆分得很细维护成本也不高。有些则不同，本来耦合就打，拆开反而增加很多链式调用，这样得到的收益可能就不大了

软件工程没有银弹，虽然我在用微服务架构，但不鼓励无脑从众，微服务思想只是个工具，在合适的地方好用，在不合适的地方不好用。

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

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

微服务规模到了一定程度就会遇到新的问题，比如一致性、响应时间、容灾，所以做设计的时候要充分考虑清楚得失，看究竟是否划算采用微服务思想。

@artandlol 微博这种体量，我认为微服务时有意义的，但是除去这些大厂的产品，剩下的绝大多数产品的数量级都要小很多，大家再来套用微服务，成本和收益是否划得来，我觉得是要打问号的。

@daveze 单个服务聚焦的同时，服务间的调用必然会增多。

@ all
其实说白了，这是一个度的问题，每个人对这个度的把握都是不一样的，说到底还是人的问题。。。

大部分跟风，它只是架构而已，用不用看人

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

至于整个大环境动不动就谈微服务之类的，都是跟风，你不也最近跟风开始学了吗

小流量小架构，没必要，微服务会引入很多额外的复杂的问题。
等真的规模上来了，微服务才有意义。

Java 有一个很有意思的名词，企业级应用，以前的 Java EE，现在的 Jakarta EE。如果只是打算做个网站或者业务只有 CRUD，那么用微服务确实自讨苦吃。基本上，主程人数在 10 人以下，或者技术团队 50 人以下，微服务学习一下就行了，别真用。

[Imgur]( )
[Imgur]( )
[Imgur]( )

可以了解一下康威定律，大概意思就是系统设计的结构必定复制设计该系统的组织的沟通结构。

想明白必要性，在决定用不用。
我想说的是，面对用户量疯长。能简单的增加服务器数量来增加负载能力，那么微服务这种结构非常适用。
如果小企业，一个项目到 die 的一天还几百几千用户，那么使用微服务就没意义了


取决于系统够不够大

可能大项目里的微服务中一个服务就提供上千个 API，而大多数系统可能一起也就提供百八十个 API，所以微到什么样子需要和服务一起讨论，微和不微不同情况下需要量化才知道好不好，没有统一的标准。

互联网应用可以考虑微服务，企业应用就算了吧，到处复制、到处部署是个问题，虽然 docker 可以解决一些， 但是也麻烦。

@artandlol 微博多少人的技术团队?市值多少亿?

把代码变更和质量成本转嫁到运维和代码，以及规范的成本上。 大厂先天喜欢微服务的原因很简单，人家架构和运维还有基础设施牛逼。 业务代码挫一点也不会咋样。

微服务好不好玩取决于你们的运维能力，小团队就别折腾了，给自己添麻烦

搞微服务 还不如把现有纠缠在一起的逻辑搞搞好 本身从上到下逻辑就有问题 拆开来难道就没问题了？ 自欺欺人而已

看了大家的讨论，确认我们属于跟风无疑。无奈领导需要搞花头给大领导看，干活的只能闭着眼上去当炮灰了，O(∩_∩)O~

@zzzzzzZ 想问一下，为什么 P2P 必须用微服务？是特定时段高并发吗？

我们公司微服务就是个笑话，完全跟风，给客户看。

@lcdxiangzi
对，核心就是特定时间段的秒杀系统
P2P 盘子没起来之前怎么办，办活动呗，X 月 X 号整点开放几个利率 20%的项目，每人限购 X 万这种，一场就吸资几百几千万
其它的也差不多。前两年乌烟瘴气的 P2P 公司，可能公司就几个人，空手套白狼，开几个项目活动就能吸资千万往上

@lcdxiangzi 这应该跟 P2P 无关，金融行业都一样。金融行业对高可靠性和低延迟性的要求都很高，就像前几天 PDD 那种情况，在金融行业要是出现了，不跑路就得进去。金融行业的应用，常规 CRUD 架构再怎么改都是撑不起来的，读写分离、事件源这种架构都要上，它们天生就是分布式架构，所以搞成微服务一点难度都没有。

几个人当然没必要啊 好端端的一个单体就能干完的事情 非得要拆 N 个出来 又学不来大厂的那一整套服务注册治理监控的机制 结果就抓瞎了

感觉没有大厂的资源技术，想搞好很难

我到现在都搞不清微服务和 soa 的区别。。感觉都是分成多个项目部署啊。。。。。

没有大厂实力驾驭不了的，小公司不精于自己的业务偏偏要和大厂比高低，可笑的很

都是噱头~~一个 TMD 针别大的项目都要跟风玩微服务，只能强行拆，拆完性能还没以前的好~

@luozic 烂代码转嫁给运维？你觉得架构上怼硬件能解决问题吗？

13 楼和 16 楼的图承包了我一天的笑点 哈哈哈

 nice

大公司的发展 往后 istio 搭配 springcloud 之类， 小的不推荐用 但个人可以学

微服务其实更方便部署吧，先不说 k8s，大多数情况下 docker-compose 用一个配置文件就能解决部署的问题了，还不需要运维去手动安装系统的各种依赖，对运维真的解放很多呢

我感觉看情况了，都是小水管平时没啥事的就不一定用微服务了，当然，要是本身就很熟悉这门技术，又有需求当然好啦。

@passerbytiny #28 金融行业天生适合微服务吗？按照我对金融业务场景的理解，事务性管理以及业务逻辑严格把控的需求。和微服务不算是很搭吧？
单说事务性管理，在微服务中就要搞出一堆控件来实现各种补偿机制吧？
从 CAP 角度来看，我反而觉得金融机构会主动放弃 P，单体系统不是更完美吗？（不考虑项目硬件成本的前提下）

不知道是不是我没有理解清楚？还是？

@yamedie #36 我觉得这种调调最要命了，如果单纯从项目发展的角度看，不考虑其他的外围因素。

@dremy #39 我不是很认同呢，微服务确实配有很多好用的工具，比如 K8S 或者 docker，但是真的复杂业务场景，业务逻辑流程都会变长，在微服务里面，一次优化或者迭代可能就涉及到多个服务模块，在测试或者部署时，模块内部的工作量确实降低了，但是服务间的调用关系和部署顺序，我认为变得复杂的多了。如果考虑到这些技术的出现时间。

窃以为，这些工具可能就是为了填坑才引进的呢。。。

看到十三楼的，就想到把 shit 山拆成一份份的小 shit...

@lcdxiangzi #33 给你说个最简单的例子，从 A 银行转账到 B 银行，你准备做一个怎样的“单体”系统能让 A 银行和 B 银行都接受。
事务性这个就更扯淡了，就一个最简单的行内取钱操作，就涉及到个人账户、支行账户、总行账户等多方面的数据，想要原子提交，你准备让用户等多久。

十个可用性 99%的服务 加起来 就是一个 90% 可用性的服务了

还不算 传输的 overhead

@passerbytiny #45 上面这些业务场景我都理解，但是我了解到的大行，确实是原子操作。为什么五大行到现在离不开 IBM 的大机，就是他们为了保住 C 和 A，而不得已，必须放弃 P 了。
至少我是这样理解的。

@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 性质。

@passerbytiny 这个是我混淆概念了，想表达类似的意思，所以拿过来用了。

微服务就是扯淡的，就跟区块链一样，是个公司都想插一脚，显得高大上，实际上没有几个用得上。有这个时间还不如把自己的项目优化好

我觉得分布式系统本身就是为了解决高流量下的高并发问题的 小公司确实不适合上微服务 第一项目没到那个体量，第二 上了微服务之后有很多的问题需要解决，比如分布式事务什么的。有解决这些问题的时间，用单机架构可能已经写好上了第一版了，而且流量小的时候也不会崩，项目到了一定体量再考虑重构也不是不行。 不过用 springcloud 对开发来说可以提升技术，没什么不好的。

https://dzone.com/articles/microservices-please-dont
这篇文章，大家感兴趣可以看看

@guolaopi 我个人的理解，大家谈 SOA 好像更多的是一种架构思路，微服务好像更偏向具体的技术实现。
我也觉得这两个东西没有太大差别，/DOGE

@lcdxiangzi 所以就是和十年前的分布式现在叫云了一个意思吗？

凡事不是非黑即白的。 一定要说“微服务垃圾”才是正确？ 单体系统有单体系统的优势，微服务自然也有也有优劣，技术选型需要对症下药。 我们有时候就是太迷恋新技术新架构，从来不考虑优劣确实是个问题。

单机部署多个服务的网络消耗代价也很大吧

之前的公司两个人开发项目用什么微服务架构，徒增各种各样的麻烦，搞的总是不能按时交付项目，在我看来这种就是盲目跟风的结果

@lihongjie0209 我就知道会有这图 哈哈哈

想到了 宏内核（ monolithic kernel ） 和 微内核（ microkernel ）
Linux 系统就是宏内核 ， 而 Google 正在开发的 Fuchsia 系统则是微内核的

@passerbytiny 哥们，看了你的回复，觉得你应该从来没有做过银行项目啊，你举的例子都是你自己想象出来的场景呢，
1.从 A 银行转账到 B 银行，你准备做一个怎样的“单体”系统能让 A 银行和 B 银行都接受。
你应该没听过人行的二代支付或者大小额系统，所以你并不清楚跨行是怎么个处理流程。
2.事务性这个就更扯淡了，就一个最简单的行内取钱操作，就涉及到个人账户、支行账户、总行账户等多方面的数据，想要原子提交，你准备让用户等多久。
你根本不清楚银行的账户体系，不懂什么叫客户账和内部户，所以你也不知道存取处理流程。

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

@cobol #51 一、挖坟；二、A、B 在对话，你插入说话，并且仅针对 B 向 A 的最后一句话；三、话说一半你根本不清楚……然后没了。你说这 block 该不该送上？

@passerbytiny 我是觉得你给人家解释的东西太离谱，所以才会说一句，如果靠一点谱，我都懒得插话，另外，你的理解有问题，我并没有说一半话，我说你不清楚是结论，我这结论对吗？
而对于我说你不清楚的问题，人行的二代支付或者大小额系统，银行的账户体系这些，你自己去 baidu 一下都不会？
从你的这个回帖也看出来你是怎样的为人，我是针对银行系统这个问题，你直接挑 3 个不相干的问题来攻击我回帖的行为，我能理解你为什么这么做，因为我对你的判断是对的，而且加上回帖的语气导致你很不爽。
而我回帖的语气完全是模仿你对 @lcdxiangzi 回帖的语气，哥们，什么叫己所不欲勿施于人啊。

@cobol 看兄台你的昵称，就是个银行系老人。
上面那位兄弟的回复我看懂了，有些地方是需要讨论的，不过我当时开这个帖子主要是想针对微服务讨论，所以没有跟进。
个人理解金融系统是一个非常特殊业务场景，既要稳定，又要超前。
稳定是压倒一切的，这个是金融的本质属性决定的。
说金融系统超前，可能很多人会有意见，因为金融系统是出了名的，不敢上新技术，到现在为止很有很多银行系统守着 struts 不肯放弃。到现在为止，cobol 还活在很多大银行的系统里面。但是，如果抛开技术细节，当我们聚焦系统架构，我感觉银行系统的架构在很多年之前就已经实现 SOA 了，就像上面有人提到的，SOA 和微服务有什么区别和联系？其实是值得思考的。