2024 年了，之前搞微服务的公司你们还好么

这样挺好啊，老板轻易不敢减员增效

微服务撕逼利器啊。

@idblife 好么，我觉得我都想跑路了，检测问题不是一般难，而且没有人帮助完全搞不懂在干什么，连测试都是这样，本来是隔壁团队解散到这里的，现在后悔没走人。。

@lambdaq 见识到了，昨天硬件和测试还吵得面红耳赤，感觉对团队和谐很不利啊

上微服务没上链路追踪相关的监控麽

@slzcz 应该是有的，但是看起来也很不好定位，具体情况不正常，最后发现是一个组件升级有问题

@IamUNICODE 具体情况不清楚

这个跟微服务有啥关系？难道不是使用方式的不对吗？这锅怎么就轮到微服务了？

再者，定位 bug 花费的时间，不是跟 bug 的具体原因有关系么？跟用不用微服务有啥关系？就算不用微服务，很小型的项目，也可以遇到很恶心的 bug ，花很长很长时间去调查，并不代表没有的。

其次，谁跟你说从一开始参与了项目的人，就一定对项目很熟悉？团队里面绝大部分人是不关系别人做的事情，都只关心自己的一亩三分地的。

成熟的微服务：首先就是链路追踪；其次，代码规范；服务的入口和出口，是否有关键日志，elk 上了没（或者日志搜索脚本，在阿里的时候别人写的，我们直接用的），监控做没做好，异常监控这些，都做好了么？

定位过程不通顺 说明要么是人员流动交接没做好，要么是文档沉淀没做好，要么是微服务划分有问题。

@yuanmomo 据我所知他们都做了，还是会出现各种问题，那么微服务的好处在哪里呢？除了对研发人员依赖很强，有做不完的 kpi ，技术上的好处在哪？好处在于各人写各人的互不干扰吗？🤣

@libook 这个。。正常来说微服务组件有多少个？ 50 个正常吗？之前也有组件联动的情况，但是不到十个，按功能划分的，组件之间大部分情况也是通过数据库做中转，我感觉如果是这种几十个组件互相直接联动的情况，对开发运维测试协作的要求相当高了，如果不是为了堆 kpi ，这种架构有意义么。

这难道不是服务拆分不合理的问题吗，甩不到微服务的锅

链路追踪没做好吧，通常一个 traceid 查一下就知道哪里异常

好好的啊

@IamUNICODE #10 ? 什么开发对研发人员依赖不高?
搞不懂你啥意思

大厂就是喜欢搞这种

可以上 apm 监控，skywalking ，pinpoint 之类

用单体这些问题都没有，高性能、易调试、好理解、资源占用小
唯一的缺点就是没有 kpi

技术全跟风挺多的。不管适合不适合，流行的就好。

服务治理、监控、容错、链路追踪都没有叫什么微服务？