微服务已死，飞书合并微服务，大裁员

小城外闲愁未了:
其实微服务和单体哪个好根本不是重点，重点是企业要裁员，合并项目可以减少人力成本。裁员是目的，微服务合并只是手段。

【回复】合并微服务是果，业务无法继续扩张才是因
【回复】回复 @紫藤穗穗 :之前互联网过度招人了，现在缩一缩挺正常
【回复】回复 @626舰长来了 :之前企业赚的多了，钱包缩一缩，挺正常的[吃瓜]
biliSectumsempra:
同意，我猜现在很多裁员和微服务合并，并不是我们真的不需要微服务，而是当初前几年疯狂扩张业务招进来很多人成立了太多的业务部门，现在给裁了可不得微服务合并吗。

【回复】人力资源部门推动技术合并
【回复】业务扩张，服务拆分，颗粒度越拆越细，业务收缩，服务合并，颗粒度越合越粗……其实挺符合微服务设计理念的
【回复】那你要反过来想 微服务真的优大于劣吗？微服务的想法都建立在设施齐全的环境下 成本高 可能造成资源过剩
紫夜喵雪:
微服务的整体思路，是用服务器成本，换取可用性和解耦，降低了开发者对全系统的了解程度的要求。 如果没有那么多新模块要开发了，如果服务器成本要降低了，就把微服务整合了。 项目在不同时期需要的架构的不一样的。

【回复】以前有钱，怎么方便怎么来，不需要关心钱的问题；现在经济衰退，怎么省钱怎么来
【回复】一棍子打死都是不讲道理。微服务有其价值，一个服务迭代升级的失败要打死一批打工人
是笑杨呀:
比起吐槽我更关心回归单体后怎么样。感觉像折腾了一圈没啥收获后回退了。那微服务根据具体业务部分扩容着怎么办，这个优势不要了？谷歌那个文章提到升级版微服务是开发人员按照单体的方式编程，微服务效果部分交由基础设施去实现。这部分也没有个具体做法，自由这篇文章的愿景，不知道谷歌什么时候可以提供实现参考

【回复】微服务和单体都可以做多实例负载均衡啊？单体的负载均衡开发、测试、部署起来更方便，不需要k8s了，省更多人力，省下的钱够买很多基础设施做单体多实例
【回复】回复 @漫步凌云 :单体多实例是传统分布式。 然而微服务需要的很多组件，分布式照样要用，而且还没有扩展性优势，部署的时候需要全量部署。。。 微服务主要是节省扩展成本，而不全是解决高并发。
【回复】回复 @相信祖国20220804 :我也有用k8s，可以确信非大厂用不到，而大公司不少业务也不是非k8s不可。可能你没有见过虚拟机编排，只要想想几大云厂阿里云、亚马逊、微软云管理这么多虚拟机，肯定就有功能强大的虚拟机管理软件，甚至它们提供的云原生容器服务的底层虚拟机也是托管自这些虚拟机管理软件
--刃舞--:
微服务合并又不是不用微服务，只是裁剪人力和资源罢了，100 个子应用和10个子应用都是微服务

【回复】其实就是合并一下粒度，以前拆的太碎的整合一下，又不是直接就回归单体了[doge]
【回复】嗯，一个微服务（单体）也是微服务。你说是就是
【回复】不起个惊悚标题都不会发视频
数学物理学家赛博拉图:
数据离开了上下文，就是有误差的信息了，我们一般用类型系统控制这种误差，而当代程序员普遍连一个进程内Java，C++的类型系统都搞不定，更不要说这种连符号都需要等价判断的情况了。不是没办法，Haskell的类型系统大概就够了，用不着定理证明器依赖类型系统那么强大严格，但你们不是才开始玩Rust么？

【回复】你没事吧，刷碗刷得cpu短路了？
【回复】所以说32号混凝土是不是影响挖掘机的扭矩？
【回复】你先把舌头捋直了，什么进程内javac++，什么符号等价判断，有语言障碍的建议拿去送修一下再来发评论捏
转眼已如烟__:
关于疯狂招人的事儿，以我浅薄的认知和工作经验来看：很多小领导/负责人遇见解决不了的问题就喜欢给上层报“缺人”，然后就导致疯狂的加人，一个小项目可能有一大群人参与，这样才显的这个项目很难。（说的不对的话轻喷[笑哭]）

【回复】忙的时候确实缺人，不加人自己加班也做不完。突然来了很多项目，又紧急不能一个个排队，那就报缺人。 忙的时候招人，闲的时候裁人，在正常不过了。 不然解决不了短期大量产出的问题。
【回复】还有就是任务量不是每月平均的，有的月可能任务需要10人，有的可能5人。
Ronunstoppable:
微服务本身就是新瓶装旧酒，归根到底是模块化，模块化做好了服务想分就分，想合就合，现在微服务确实有滥用的趋势，本质上就是架构师水平低下外加老板啥也不懂[呲牙]

【回复】感觉就是技术人员对于业务的轻视导致的。以前的技术岗位招聘，大部分只去问八股文的东西，很少会去考察技术人员的业务思维和将现实问题转化为技术问题的思维。 然后是不懂业务的的技术人员，被不懂技术的产品经理带着瞎跑。最后屎山越来越高，越来越难受。
【回复】事件驱动，无栈协程(async await），有栈协程(goroutine），http2/3(协议优化），单机都能百万并发，并发早就不在server而在数据库，数据库集群搞好就行了，再高并发都能抗住[撇嘴]
【回复】1.你在一帮清华北大毕业的老板面前讲模块化，是不是有点低端，对不起你的身份，你讲“微”服务，老板们虽然不明所以，但是会感觉好厉害的样子。 2.字节差不多是全国最重视学历的公司了，老板清华，员工人均清华，你说字节的架构师和老板水平低下，那么还有哪个学校毕业的架构和老板够看呢？
泽源饼干:
完全回单体不可能吧，那么庞大的app，单体启动起来不知道要多久

【回复】回复 @dongtailai :骂啥人，我这里没瞎扯，我这里说的是针对成熟运行多年的微服务项目，这种项目已经运行相当稳定了，合并成单体项目之后，变动也不会太多。 就算是合并成单体项目，前后端还是照样分离的，所以一个项目即便是合并成单体项目之后，照样还分为前端、后端、移动端这几个部分。
【回复】回复 @张侦毅 :扯几把蛋 一个单体服务功能太复杂代码太多 调试都是个问题
【回复】合并微服务，编译后的项目的总大小会减少不少，这样可以节省不少服务器资源，但是在源码部分区别不大，该有多少源码，就有多少源码。
Cirth9:
合并微服务又不是不用微服务，100个小碎块合成十个大点的，不还是微服务

【回复】回复 @并发架构师小桑 :你说有没有可能微服务不是用来解决高并发的，基本大多服务性能瓶颈都在数据库。 微服务主要是扩展性比较好，技术栈不受限,局部修改易于维护，但是拆分过量反而会起反作用，我估计飞书就是瞎拆搞的链路复杂度太高了起反作用了，所以才开始合并的。
【回复】回复 @橡树上的松子 :理论上对服务进行拆分成多个模块之后用通信协议进行通信，这种架构就可以算微服务架构了。 微服务拆分过量反而会导致成本大大增加。
【回复】事件驱动，无栈协程(async await），有栈协程(goroutine），http2/3(协议优化），单机都能百万并发，并发早就不在server而在数据库，数据库集群搞好就行了，再高并发都能抗住，微服务只是加机器脱裤子放屁还引来一对复杂问题[撇嘴]
ufhivkgf:
java 现在岗位增多了么，前阵子看 sprintboot使用量减少的新闻

【回复】以前经济上行，无脑扩张卷市占，资本好圈钱。现在经济不好，只得是裁人降低成本。
【回复】岗位多，工资高，狠狠赚一笔[doge]
【回复】感觉还少了，你去看看招聘网站的情形就知道了。我最近也在找工作，苦不堪言
抽象java之父:
微服务没啥优点，我早就不看好微服务，并没有实质解决高并发，只是加机器，而且带来了一系列分布式问题难解决，我看好的架构是集群+事件驱动/协程实现海量并发，这才是实打实的高并发[撇嘴]

【回复】回复 @emo者QAQ :比单体维护简单 困难是因为水平不够
【回复】回复 @hcllll :就是工作量大了不少[辣眼睛][辣眼睛][辣眼睛]，维护成本大增
读书明理的老李:
裁员才是重点，微不微服务其实关系不大、、、

细毛副警长:
什么技术架构、设计模式都是小朋友过家家，真正的核心开发模式是“面向成本”开发，怎么成本就怎么开发 这也是所谓it技术更新快的原因，实际是上层需求变更快。企业要是稳稳运行的，员工不会动不动就要学新技术的

太空-丹迪:
[微笑]有没有可能这几年硬件条件上去了，以前所谓的什么十万瓶颈都不是问题了

【回复】回复 @兔子不乖R :百万并发只能非阻塞+线程池的websocket/tcp才能达到了，http并发在20w基本封顶了，actix websocket模式，百万并发没问题，基于协程实现的事件驱动，websocket还复用连接，双重提高性能[撇嘴]
【回复】回复 @并发架构师小桑 : 1. 你概念搞混了。首先 web socket 是长链接，其次不管是 websocket 还是 http，又或者是现在流行的 rpc, 都是应用层协议，它们都是基于 TCP 的传送协议的。其实并发量和微服务并不冲突。如果你做一个权限认证服务，那不管是不是把它做成一个微服务，它的并发都有可能很高。讨论并发量更多是从分布式架构来看问题的，如何做负载均衡，如何多节点部署保证服务可用性，这些才是保证高并发的前提啊。 2. 你一开始说百万，现在又说10W，所以你们的系统单机能做到多少并发呢，P90又是多少。就算你们的并发量很高，难道不需要保证可用性吗？ 3. 把所有服务都放到一台机器，如果这个服务挂了，岂不是整个系统都挂了？ 所以说，做不做微服务和并发量无关，更多是服务如何治理。
【回复】性能只是使用微服务的一个理由之一。业务拆分、解耦、高可用等方面就不是性能不性能的问题了。说白了就是现在经济下行要裁员降本。
柠檬是只怪兽:
我感觉微软是最有眼光的，不知道大家了解blazor嘛[吃瓜]

【回复】眼光个屁，微软的产品线和结局你自己查查，跟它走喝西北风。
【回复】回复 @bili_1918902 :您多久没上网了，最近的openai母公司是谁？另外他家的云服务最近成功了没？
时光拐杖:
赚钱和微服务没啥关系，公司两个系统。一个单体，业务好，一年13亿。微服务那个，一年还没有2亿。