工厂用，感觉没必要用微服务。又不是高可靠性系统，业务也不复杂，用户量也不多

不配套

资料上csdn,简书上一搜一大堆，我一句话概括微服务优点就是分散能力, 服务解耦，缺点就是后期维护成本贼高。 一般传统行业的业务都相对比较简单，也没有那么严苛的应用场景，也不具备某些先觉条件（比如稀烂的数据库和业务设计)，用微服务纯属没事找事

怀疑你跟我同一个公司的，领导一知半解 ，老想着上微服务！
我理解的微服务，包括服务注册 服务调用 网关 服务降级 服务总线等功能，只适用于大型互联网企业，强行上微服务都是没事找事

工厂用，感觉没必要用微服务。又不是高可靠性系统，业务也不复杂，用户量也不多，能跑起来就行了，价格高了你也舍不得

付点劳务费， 我天天可以跟你直播讲

高射炮打蚊子，素我直言，80%的公司的业务都不需要微服务

业务需求变更频繁，处理数据繁多。

@chrishine 能解决这些原理是什么，能简单说说吗。

微服务，你把每一步搞个服务不就是的了.就好比办事窗口，一个窗口专门办一件事，这里一个窗口就搞一个服务.一个服务甚至只有一个接口，多并发干一步事

@czz_ls 那和我们现有东西有啥区别，单存就是方便整合吗

@czz_ls 提高性能呀，大量人访问，他只做他一件事应付就很容易呀，部署也可以在不同设备上呀，数据中心是共享的，一个业务崩了不会影响其他的业务

微服务必须跟自己公司现有的组织架构，业务规模来结合判断是否适用。
小团队，小数量业务模块根本就不适用，劣势远大于优势。

微服务产生的原因就是，单体应用随着业务需求膨胀，业务模块越来越多，响应需求的研发人员数量也跟着膨胀增加，版本发布的频度同时居高不下。单体应用应付这种情况太吃力。不得已把单体应用拆解解耦成多个独立的业务模块，每个小team负责维护一个模块，模块之间依赖关系由原来的本地调用，改成远程接口调用。

好处是，每个模块的版本可以独立测试、部署、上线，每个team只关心自己的一亩三分地，不需要关心了解庞大的整体项目情况，研发团队职责也非常清晰好管理。坏处是，单体应用原来用单机或主从结构就能应付，现在多主机/进程部署，运维监控管理难度线性上升；team之间，因业务模块接口开发沟通成本也变得巨大，接口升级的管理及其复杂和耗费成本

要我说，用户量庞大的互联网应用比较合适用微服务。像2B的企业应用，绝大多数都不适用微服务。据我观察，行业内真的90%的微服务场景都是瞎用，场景不合适强行硬上，生怕没蹭到这波热度自己技术就落后了

没有必要为了微服务而强上微服务，听说好多公司在去微服务化。

上了方便学习，后续换工作方便。日常平时工作量大点，运维复杂点。

微服务没有良好的DevOPS理念就是找罪受。

完全没有必要，微服务适合互联网项目，伴随广而复杂的运算，存储及网络开销，用户规模庞大，服务器规模庞大，开发人员数量庞大。

你们根本不需要，spring cloud也用不上，真想做服务拆分，dubbo + nacos 足矣

没必要，规模小了搞微服务就是自讨苦吃。架构设计不良，各种坑出翔。

工厂的话 光一个ERP感觉就搞定了

看需不需要微服务，可以根据码农人数粗略判断，比如你这个系统服务器端同时需要50个人以上来维护，说明系统已经比较庞大，那可以考虑微服务。30人以下的用微服务都是负优化。10至50人的可以考虑宏服务。最后，不要为了上微服务而微服务，当你不知道为什么的时候，千万不要用微服务

@andyhust 目前是有超过30人维护的。而且比较吃力。新人入门也比较难。业务变化大，人员变化大，很多数据流都不清晰。一个人很难掌握全部代码了。程序问题较多，需要人值班，很折磨人。
比如说，有个地方数据缺失，很难排查原因。重跑一遍程序，数据又能补上。

@letiankaimen 你说的这些问题，微服务一个不拉，全部都有。人员变化大，微服务照样不好维护。至于微服务值班不值班，你看大互联网公司哪个不是24小时on call，这不就是另类值班么。 有那个精力上微服务，还不如找个比较稳定的团队，把当前代码重构一下，不是更美滋滋。

反正微服务这东西，肯定不可能让人轻松的，他设计出来也不是为了干这事的。 哈哈，都是程序员，有一说一，一个系统只要能跑，那他就是成功的好系统，请相信命运，而不要相信用人员变化很大的团队能搭出来另一个能有现在这个性能的系统。

@letiankaimen 这种情况不能把希望寄托在微服务，连单体架构的数据一致性都做不到，微服务架构下那就基本废了。