珍爱生命, 程序员不要再用微服务了
哑火的楞次:
我们是服务分离，人不分离。做的钢铁加工工厂的MES系统，业务之间耦合性很高，还非得让拆服务，说是可以在后面作为组件复用，实际能复用过的业务组件没见过几个。不过一直纳闷，我们这种系统上线之后，使用的人不可能超过两百人，真正用的人有个一百人就不错了[doge]
【回复】回复 @猴哥哈哈 :用了微服务，对客户和外面就可以吹牛逼了[doge]，说我司给你们这个项目用了什么高端的技术，怎么怎么样，产生一点溢价，而且别的竞争对手用了，你不用，客户甚至可能会怀疑是不是你技术不行，所以有时候也不完全是看实际业务来。都是客户和领导们的要求而已。
【回复】回复 @放个屁送给你I :我说了不算啊[doge]
caejws25:
编程界只有一句话是真理：计算机工程问题没有所谓的银弹
引入新的方案会带来新的问题
因为
根本原因：大型系统的复杂性只会被转移，不会被消灭！
举个例子，用了SpringBoot，一行代码起应用，难道javaweb的复杂性也降低到一句代码了吗？
狗屁的嘞
SpringBoot只是把各种复杂性层层包裹包成个粽子交给你，去看看源码和文档的量，引入SpringBoot甚至增加了复杂性
大型系统的复杂性是因为它大，不是因为技术不够好
【回复】回复 @jh7086 :拉倒吧，包装只能解决最傻瓜的需求，一旦遇到复杂业务定制化，又得研究包装复杂性的源码。或者出了个莫名其妙的问题，又得从源码一层层看
【回复】复杂性转移就很有用啊，把复杂性转移给别人，转移给机器，难道没用吗？
蟹黄旗:
挺好的，越来越多人开始反思技术了，而不是随波逐流，为了技术而用技术
【回复】微服务有个原子力，不可拆分的，可惜没人看。还有微服务阿里我个人认为他们走了概念错误的路线。。他们大部分很好，但做了很多不该做的
萌物推荐:
要搞微服务得有配套基建，配套的sre，而且要做就得做全套，你服务都拆成一套一套的，连数据库redis还是用固定ip，那实际上扩展性也框死了[doge]
【回复】很多团队都是为了微服务而微服务，因为觉得这个技术高大上。搞个微服务的框架比如go-zero，在单机上跑，SRE的东西一窍不通。
沙勒垃圾之王:
不要拆的太散，从微服务变成小服务就行了[doge]小服务是那种把业务拆成模块，然后模块组装成服务的方式，你可以5个模块起一个服务，也可以20个模块打包一个服务，高流量的模块独立拆解，依靠弹性扩容多副本提升吞吐量，使用少的小模块就合到一起减少资源占用，本地开发那就直接勾你要的起来
奔跑的大肉橘子:
完全赞同！微服务只适合复杂场景且有足够的团队支撑才能用。几个人的项目就别用了。完全是折腾自己人！
瘾瘾怍痛:
现在到处都是微服务，一看用户没几个[笑哭]
hibean2018:
拆分不合理，什么都白搭。典型的，如果一个改动，导致需要在很多地方修改适配，拆分就很有问题。
提笔心思:
实事求是的选择服务架构是正确的思路，但是现在可能大多数公司是追赶潮流，或者是领导层做技术壁垒。
【回复】我在上个公司被5个微服务折磨，然后就合并成一个了，跳槽到新公司后领导要求设计微服务架构[辣眼睛]没办法，又搞了微服务，前期还好，后面就开始耦合了，难受
活着为啥:
很多项目没必要微服务，往往就被高大上的上了微服务。面向KPI编程。
0x3f3f_:
我在一家国企，两年前公司买了一个监控系统，然后这个监控系统是一家小公司做的，136个服务，我真的要吐了，感觉设计这个的人，培训视频看多了，还用了一大堆中间件，纯纯过度设计，这个系统里面的每一个菜单都是好几个服务，还经常出问题，出问题厂家就让重启，而且重启的顺序连他们的实施人员都不确定，基本看运气，文档也没有[doge]，况且我们这里根本没有基建，全靠人肉运维，有时候重启一下午还是解决不了问题，不过好在已经两年了还没验收[doge] 真想把这玩意儿换掉
【回复】回复 @帅才阿德尔曼 :是啊，纯堆砌技术，为了技术而技术。这对小公司运维成本来说是灾难性的[doge]
【回复】这不是微服务的锅啊，这是微服务没学到精
Thomas_Paine:
技术是根据需求用来解决问题诞生的 没这么大体量天天学大厂拆鸡毛阿 有devops么？有全链问题追踪么？有监控么？有人手么？啥也没有天天就会模仿 一地鸡毛阿
底层_码农:
不同公司不同场景，不要只看自己那一点东西[doge]
【回复】只是说大部分项目用不到[doge]
小殇今天加碗饭:
我前东家更加激进，已经考虑放弃前后端分离了[doge]不明白怎么想的[doge]
【回复】回复 @猴哥哈哈 :服务端渲染前端页面，数据靠模板引擎提供，这就属于前后端不分离
【回复】回复 @猴哥哈哈 :jsp thymeaf这种吧
【回复】小系统也没必要一定前后端分离，java和.net都有mvc设计模式，加载view页面，html js都在一份代码里面，小系统一两个全栈人就搞定了
jerry_mei:
其实微服务现在被滥用的太厉害了，而且很多人对微服务的整个生态都不是很熟悉，线上遇到问题调试都不知道怎么调试，还有怎么实现不停机发布，技术搞得越来越复杂，但是团队的体量根本就不需要上微服务。一个很小的应用，拆一大堆的微服务，导致软件设计本身的问题都没人去思考了，比如怎么在单体中设计一个很好的软件架构，怎么写高质量的代码等等。genericity:
微服务和docker的价值都是部门和部门解耦，解决人的问题，而不是解决技术问题。前者其实更加重要。
【回复】相比用技术手段解决技术问题和用行政手段解决人的问题，往往用技术手段解决人的问题才是最受欢迎的。
