从微服务走向单体化

[xhwdy26]

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

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

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

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

[javalaw2010]

我觉得一家公司如果在技术架构上使用单体还是使用微服务有争议，那大概率就不必使用微服务。

[guotie]

毫无问题

单体为啥不能扩展？？？？

[zen1]

先搞懂什么是单体，什么是微服务吧。微服务不是银弹，单体也不是什么 low 货！

[xuelu520]

看着我 source tree 里面的 20 多个微服务项目，开发一个需求涉及 N 个服务，太鸡儿麻烦了
我司部门什么东西搞个微服务，有点为了微而微的感觉了。

[dylanqqt]

@mbeoliero123 单体是指把所有服务揉进一个项目吧，又不是单机不能搞负载均衡。你微服务不搞多台机子 流量大的时候也扛不住啊。

[Gll910802]

@lqw3030 的确，我们目前就这么处理的。想 all in one ，就单独启动一个 jvm 引入所有包的那个工程。想微服务，就各自模块单独工程单独 jvm 启动

[ciki]

@yinmin #5 单体和用不用消息队列没关系，消息队列只是个中间件

[ciki]

@yinmin #29 看你上面疯狂回复一堆，我建议你重新学习下基本概念吧

[tongqe]

要看自己的系统是否是复杂系统，复杂系统中的每个元素的行为和关系是不一致的，比如几个关键指标，高可用，高吞吐，高扩展花成一个三维坐标轴，比如银行的交易服务，对高可用，高吞吐要求极高，而一些统计模块的实时性要求没那么高。这种元素之间的差异性是天然存在，无法避免的，自然要拆分。如果再带入组织架构和人类协作的方式上，拆分微服务是当下比较合适的方案。至于楼上一些帖子说，spring 和 Java 作为基础设施占用内存的问题，其实是优先级非常低的问题

[runlongyao2]

docker 把服务部署到一台机器，这样要改的少点

[runlongyao2]

@yinmin 哪儿那么多百万级的业务...如果有，迁出来这一个单独部署和维护就好

[dylanqqt]

@hdfg159 # 90 这种情况微服务和单体没任何区别，我们的微服务的数据库、proto 文件，项目地址都拆分开的，负责用户服务的就拉用户服务的代码。

[runlongyao2]

@xhwdy26
把原本部署方案改成用 docker 容器部署，每个项目都是一个镜像就行，这些镜像都部署到一台机器上，
源码层面不需要动

[dylanqqt]

@yinmin 单体和用不用消息队列有啥关系？难道单体的都没有处理过购买未付款，然后等 20 分钟自动取消订单然后归还库存的业务吗？

[fcten]

如果这些功能只要 3 ～ 5 人一个团队就能维护，单体服务并没有什么问题

[runlongyao2]

@keller 老兄明白人

[xabclink]

单体系统为了解决自身的各种内部问题，分化为多个微服务系统，当各个问题解决解决后，又合并为一个新的单体系统，螺旋型进化，往复这个循环

[lvlongxiang199]

shopify 也用单体. 贵司的业务比 shopify 更复杂 ? 为啥他们的单体没崩 ?
https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity
https://shopify.engineering/shopify-monolith

[harry90]

业务量如何 增长如何 多大规模 未来预期如何 什么样的团队 任何架构选择都可以考虑实际情况

[runlongyao2]

@ryalu 微服务最大问题就是，容易导致成本失控，这种失控不像项目失败一样，它是隐形的。

[runlongyao2]

@cj323 应用每增量了，微服务的成本问题就显现出来了

[dxddd]

组织即架构。
如果公司技术团队几个人，那么单体服务是比较合适的；如果达到 10 人，那么建议拆成两三个服务。
基本上每三个人维护一个服务是比较合适的。

[pangzipp]

不要迷信微服务。
康威定律： 软件系统的设计往往会反映出其所处组织的沟通结构。

[CareiOS]

用 golang 吧

[bk201]

看你业务，组织架构是怎么样的吧。一般小公司确实不需要微服务，微服务和崩溃没必然联系，单体也是可以多机部署的

[yiyiniu]

@xhwdy26 楼主，CEO 觉得微服务部署繁琐，是因为没找到好的管理服务的工具。看下这个，完全免费，管理微服务非常方便简单： https://www.toutiao.com/article/7314207015789593122/ 开发部署环境时，再也不用安装 JDK 、Nginx 、Redis 、MySQL 等服务了
https://www.toutiao.com/article/7314842204491645440/

[angryfish]

用单体还是用微服务是看团队人数的多少决定的。
1.你们几千个人了，肯定是按职能，各个团队开发自己的服务。微服务还是挺好用的。
2.如果你们只有几个人，那还是单体吧。微服务没必要。

[yooomu]

微服务是一种拆分的思想。当业务和项目规模扩大之后，为了在某些高压力的模块上能够做到水平扩展，自然会将这个模块拆成无状态的子服务，随之就会引入 mq 等中间件用来同步状态和通信。为了能够降低服务间调用和配置管理的负担，就会引入了配置中心和注册中心。微服务化是一种循序渐进的过程，上来就全盘微服务，成本太高了。楼上说的单体项目集群部署，不也是微服务的思想吗。所以项目刚开发的时候应该做好模块分割，模块间通信尽量做成事件机制，为以后可能的微服务改造打好基础

[angryfish]

单体程序不代表会崩溃。
单体和单机是两个概念。单体也可以通过 nginx 之类的负载均衡，部署几百台机器。某一些机器挂掉，服务是不会挂的。

[nananqujava]

@ciki #108 是的 我也觉得这个人 @yinmin 疯狂回复一堆, 但基本概念都没搞懂, 哪怕是实操过一次都不会这么发言

[Yukineko]

规模大了才需要微服务，不要为了微服务而微服务

[JoeDH]

单体，然后堆机器

[gg2018]

@kk2syc #33 兄台，4 核 8G 的机器，php 再怎么优化，也达不到 并发上万啊，况且还是业务性质带 db 的服务器，估计是日浏览量上万 pv 吧？

[8355]

如果业务总量上限一直保持在可控不增长的阶段，其实单机更好更省钱，单机是部署，单并不是单体应用，这样构建一次太慢了。

单体应用到最后就是 64 扩 128 128 扩 256 会有点肉疼，而且只能全部停机扩，哪怕其他非关联业务也得停机。
他不懂这个所以感觉单体好，你等到他花钱的时候他就知道了。

[CoderLife]

之前接到一个维护项目:
公司内部使用的, 10 来个人用的 erp,
用 java 开发的, nacos, springcloud......上上下下一共 7,8 个服务,
结果所有服务都部属到了一台服务器上,
-------
看到头都炸了,
-------
已用 nodejs, 重构成单服务了

[iv8d]

没有需求我们就制造需求，中小服务单机完全够用，那你想过大项目需要横向扩展吗

[ala2008]

我们公司另一个部门因为服务器资源不够，改为单体了，也不用 docker 了，的确省资源😂

[fffq]

单体最大的问题是单点故障，能接受就用

[ichou]

Q: 如何合并成单体，几个人同时在一个项目上开发的冲突怎么解决？
A: 各干各的就 git flow ，频繁冲突就 Trunk-Based Development

Q: 如果合并成单体，启动时间会增加，开发调试不方便，怎么面对这个问题？
A: 单体也可以模块化，除了 core 之外其它模块都是可插拔的，启动你需要的模块就好了

Q: 如果合并成单体，某个模块要拉分支，应该怎么处理这个问题？
A: 不应该任何开发都拉分支么？直接在 dev or main 上开发？
如果你指的是定制化的非通用需求，那就拉分支让它永远待在分支上好了，不是的话可以考虑 feature toggle

[huijiewei]

一个单体如果编译时间超过 15 分钟就可以考虑拆成微服务了。不然还是单体方便

[kk2syc]

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

[lucasj]

@qxmqh #100 面向简历编程。

[jeesk]

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

[yvyvyv]

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

[billbob]

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%的项目单体绝对搞定。