从微服务走向单体化

抛开具体场景，谈架构，就是刷流氓

@me1onsoda 微服务确实浪费计算机资源，但是可以分散团队各自独立开发微服务。当然后续也有各自独立开发不好集中管理的问题。

我是企业项目没搞过互联网。该看并发量评估，单体可以集群啊。

技术选型取决于你们的业务

不要最后楼主说他们公司用户量在十万以内，并发 100 以下

@cobbage #23 企业项目不会出现突发高并发，单体可以集群(多服务器负载均衡)，应付企业项目绰绰有余。

互联网项目不一样，一个朋友的商城平时最多就几百人同时在线，有一次老板做推广，花了几十万请大网红做直播，然后 5 万多人同时涌入系统直接宕机，几十万软妹币打水漂了。

高并发的架构是不一样的，微服务是独立的，通过消息队列异步通讯，会根据消息队列情况自动伸缩微服务，消息队列过长超阈值直接抛弃掉，保证系统不崩溃。单体用集群就有点力不从心了。

世界微服务的爆发，说实话，最经典、最具代表性的例子就是淘宝的“五彩石”项目。在五彩石之前，有多个团队共享一个 Tomcat 环境进行发布，硬是支撑起了一年 1000 亿 GMV 的业务量。所以，实话实说，CEO 这样做的原因，估计是是商业行为而不是技术思考，也就是单体应用架构并没有限制了你们的发展，而是对公司未来的不确定性，而产生了强烈的降本需求

@yinmin 5# 你这看法跟现实不符，单体不是单机，早在 Nginx 开源之前的上个世纪末，F5 的 Big IP 就支持负载均衡了，当时就有一些公司用上单体集群部署。在 Redis 开源之前，单体服务早就用上 memcached 了，当年做 Web 的那波人，人均读过 memcached 源码和 C10K 论文。

单体其实也用消息队列，ActiveMQ 是二十年前的东西了，之后还有 qpid ，都是微服务兴起之前就有的。十多年前，还有很多现在很少人提及的常用组件，比如 Beanstalkd ，Tokyo Tyrant 等等。

在微服务兴起之前，把大单体部署很多份，然后从网关做负载均衡是很普遍的事情，性能扩展性是不如微服务，但是不至于性能跟单机划等号。

@sagaxu #28 我同意你的看法。只是技术发展到现在，如果需要用到消息队列，优选微服务；如果单体用消息队列，开发复杂性、部署复杂性、伸缩性都不如微服务。

@yinmin 这个事情怎么看的成本问题，流量不是经常性的。我刚工作时候遇到过类似的事情，提前准备应对了，当时好像是有部分网络没切过去。

@yinmin 29# 单体的伸缩性肯定不如微服务，微服务可以很方便的实现根据负载动态扩容，单体就比较费力，最多用脚本临时租 VM 自动部署。但微服务设施是有附加成本的，无论是自建还是租 IaaS 都价格不菲，面对偶尔扩容这种事情，老板更希望员工加加班哪怕手动完成。

微服务最大的好处是提高了服务的可维护性，划分合理的话可以直接把过于老旧的服务 drop 掉对照接口重写一个。

讲个笑话，
----
快 10 年前，在卫浴厂子写的 CRM ，一梭子原生 PHP 直接放在办公室的 dell 工作站上（印象里是 4 核 8G ），全国几百家代理商、服务点，每天集中并发至少上万，从来没崩过（也可能不知道，毕竟 F5 就能重试，还能甩锅网络问题）。
----
前年副总找人搞的微服务，接入抖音和微信，一天崩 30 次，老同事又联系我，说副总让他从仓库把那台 dell 又拿出来了，但是不知道怎么把新数据导入，哈哈哈，真自豪

你们这套微服务全部部署到一台机器上，能有多少种崩溃的姿势，那单体程序能命中其中一部分，不会超过的，放心。

单体应用很好，就是单台机器配不上它，只能拆掉跑。至于高可用，这和单不单体没太大关系。单体应用也能互连成集群。

上面很多人提到单体不能用 mq 不懂瞎说？

我们就是百万用户的单体应用。单体跟异步和队列又不冲突。不考虑团队后端开发才几个人，把后端拆得比员工数还多，天天净在那切换项目了。

早些年没有微服务，同一个服务部署多个实例，简单的做 scaling out ，也能过的不错。比如某邮箱的 webmail （ java 写的，里面集成了很多功能，按现在观点看，都可以拆成 micro service ），就是几百个物理实例，靠 dns 做的 scailing out ，照样撑起数千万用户并发。

微服务在目前大部分场景里面，属于政治 kpi 吧，其实技术层面的需求并不大

我觉得单体应用挺好的，一直比较反感微服务。

单体挺好的，单机顶不住吧