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

[IamUNICODE]

新加入一个团队，应该是两年前开始搞微服务架构，组件大概有近 50 个，两个月我只看和改了其中五六个，数据流向交互完全不明白，大概是 grpc+emqx 通信，数据库有云端主库和每个用户自己的文件数据库，部署是妙云一把抓，我以为我只是项目不熟，结果上周有个小伙子，是全程跟了项目，应该对项目一草一木都熟悉吧，结果定位一个问题用了两天一夜，老实说之前参加过的最乱最复杂的项目都没有这么久才能定位问题，这是微服务通病还是只是这里没设计好？

这种搞法有点看不懂啊，现在看起来唯一的好处是整个项目对研发的依赖相当高，什么都要研发参与才进行的下去，所以之前搞微服务的你们还好吗？

[idblife]

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

[lambdaq]

微服务撕逼利器啊。

[IamUNICODE]

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

[IamUNICODE]

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

[slzcz]

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

[IamUNICODE]

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

[IamUNICODE]

@IamUNICODE 具体情况不清楚

[yuanmomo]

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

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

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

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

[libook]

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

[IamUNICODE]

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

[IamUNICODE]

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

[EminemW]

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

[securityCoding]

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

[zoharSoul]

好好的啊

[zoharSoul]

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

[leonidas]

大厂就是喜欢搞这种

[gazi]

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

[bronyakaka]

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

[seeker]

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

[bzj]

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