从微服务走向单体化

[xhwdy26]

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

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

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

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

[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/

[GBdG6clg2Jy17ua5]

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

[yooomu]

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

[GBdG6clg2Jy17ua5]

单体程序不代表会崩溃。
单体和单机是两个概念。单体也可以通过 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 分钟就可以考虑拆成微服务了。不然还是单体方便