从微服务走向单体化

[xhwdy26]

CEO 觉得微服务部署极其繁琐，什么 nacos 、mq 、redis 都好复杂，远不如零几年的开发一条龙从后台到前端那么简单。

要求把十来个微服务(用户、订单、后台、网关等）合并成一个。

简化部署，只一台机器搞定。

试问，这种单体程序最后以怎样的方式崩溃。

[v1]

@gg2018 一看就知道兄弟你没经历过 PHP 黄金时期，实际 rps*3.5=并发，不然说出去自己都觉得很丢人，还怎么给老板画饼？（当年真要 10k rps ，我早财务自由了，唉）

[lucasj]

@qxmqh #100 面向简历编程。

[jeesk]

有些服务适合做微服务， 前台 to b ，c 流量 n 倍大于管理后台， 难道崩了全部一起蹦？

[yvyvyv]

单体就是所有业务集合在一个项目里吧，微服务主要是拆分业务将不同模块分配给不同项目组来完成。最后对接在一起，其实要是一个人搞微服务作用不大，什么 mq redis 网关 单体也可以搞啊。用户量大 资源占用多 甚至到瓶颈，单体也可以横向扩展搞负载均衡啊 同时也可以做到容灾。 其实我感觉是怎么舒服怎么来没必要硬上微服务。

[AlexBob]

https://spring.io/projects/spring-modulith
这个项目了解下

[iyiluo]

很多内网用的系统，撑死也就几百人在用，这点数据就没必要用微服务了

[810244966]

@keller 我在做的一个应用就是，但是部署到 3000 台机器了，流量分发下，真宕机了倒霉蛋也只有 1/3000

[AlexHsu]

其实本来就应该单体化 随着系统复杂度增加上 istio k8s 把压力给到运维 让运维有点活干
把微服务的压力都给带代码太蠢了

[Dlin]

问题 1:
冲突问题，首先解决规范问题，统一好项目使用的 ide ，代码样式 style.xml 。ide 设置，避免误格式化等。

[Dlin]

问题 1:
冲突问题，首先解决规范问题，统一好项目使用的 ide ，代码样式 style.xml 。ide 设置，避免误格式化等。
然后是规范提交问题，细化提交内容，勤提交勤拉取。
问题 2:
启动时间增加应该不会太多，推荐结合热部署（比如 jrebel 做开发）

[gowk]

大部分系统都没必要微服务化，Postgres 就可以搞定很多事情
Just use Postgres for everything:
https://news.ycombinator.com/item?id=33934139
https://github.com/Olshansk/postgres_for_everything
https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f06dbb

[mooyo]

@sagaxu #63 你要说能不能那肯定都能，但现状不是这样的。

现状就是，大多数互联网大厂的业务，连 interface 抽象都没有，直接往里面硬塞的业务代码。这就是现状，在这个现状下，微服务直接写一坨新的屎上去替换就是比单体更方便更安全更可控。

[mooyo]

@mooyo #152 而且就国内这波微服务浪潮，实际上我理解和 golang 的流行也是相辅相成的，在这个环境下用 golang 拉屎就是比之前那套单体写法更方便。

[JosephYin01]

听起来不是微服务的问题, 是你们部署方式的问题

[cstj0505]

上面一些人还停留在什么年代?
单体用不用 k8s?单体就不能 k8s,就不能无状态水平扩展?就不能用 mq?就不能按需再拆分出来.

[csfreshman]

单体和所有服务微服务是两个极端，应该是按照模块梳理合并，减少服务量，你们这个如果太复杂的化，搞成单体化似乎也没有太大毛病，因为之前过渡吹捧微服务话，很多人都是硬着头皮上的。

[outyua]

@ruxuan1306 康威定律

[ncbdwss]

开发团队人数不多。使用的用户不是非常庞大。单体项目绝对足够。99.99%的项目单体绝对搞定。

[yuxian]

不得不说，你们老板很明智，干脆去掉 java ，采用 nextjs 体系，前后端一把梭哈。成本极限压缩。哈哈

[srwxyz]

还是业务规模往下走了，如果还在上升，肯定不会有这感觉😂