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

[IamUNICODE]

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

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

[skyrim61]

在满足功能的前提下, 架构越简单越好.

[LieEar]

之前不是一直在说微服务回归单体吗。还没接触到真正的微服务

[kk2syc]

@tyrone2333 华生，你发现了盲点！

@IamUNICODE 老传统：踢皮球，总有人要背锅

[laball]

上微服务，一定要上调用链，不然排查问题就是抓瞎。

[Geekerstar]

@tyrone2333 哈哈哈，还真是

[lyxxxh2]

@Features
我们搞单体,小部分业务需要联动,直接本地网络请求接口。

把单体重构成微服务还能理解,直接上微服务... 太看好业务了吧。

[ilvsxk]

前面有人说加上链路追踪，日志搜索平台就可以，然后你会发现：
1. 这个全链路追踪的性能消耗为啥比线上所有服务的资源消耗还要大，最后只能改成只用 traceID 做记录，那种有详细记录的链路追踪就算了吧。
2. 服务太多，排查基本全靠日志，要是出现一个问题没有被日志覆盖到位，改代码，加日志，上线，诶，好像还不行，还得加日志，来来回回整半天，而且有的问题只有等加日志后复现，不然你永远也不知道为啥会有问题。
3. 日志加多了之后，每天的日志量很大的，一天 1TB 的日志都不是问题，日志越多，日志平台的性能消耗就越大，这时候用 ELK 的成本可能比你当前线上服务器的成本还要大。
4. 服务太多，本地调试困难，别说有测试环境，真实情况下微服务那测试环境每天都是缝缝补补，谁用到的时候谁去修，修复测试环境的时间比你开发需求的时间还要多的多，想想几十上百个服务的部署，启动顺序，数据库数据，业务依赖，这测试环境的部署和维护就足够麻烦了。

你看上面这些问题，除非是大公司有钱玩的动，小公司还在天天计算如何优化服务器配置减少成本。
最后，定位一个问题两天一夜其实也说明不了啥，有些问题工单一两年都查不到原因，但是查不到也没关系，可以用别的方式想办法规避开。

[dongzhuo777]

需要上微服务的业务系统，那业务范围肯定是光到没边的。这种如果某个员工能把上下游所有业务链路吃透的，早就可以转型业务顾问了。
而且就你描述的问题有一个包没升级这种低级问题，就是本质上是版本管理和发布的问题，和微服务有毛关系，devops 没做好。
能上微服务架构的业务体量，从业务复杂度和研发人员的数量来说肯定很大，如果用单体，别的不说 出现那种改一行代码打包编译几个小时的都有可能。

[dongzhuo777]

@ilvsxk 日志的问题我不认同，你换成单体难道就好了吗，微服务换成单体。那拆分的服务单体里面肯定是一个独立的模块，否则那就是这个微服务的拆分不合理，甚至这个模块是独立的团队去维护，对于调用方来说就是一个黑盒。
假如是单体线上出问题没日志，那单体 排查起来一样抓瞎。和微服务没关系。
要是十人以内的研发团队可以搞定的业务量那微服务的拆分确实没意义。但事实上上微服务的都是几百号研发团队的情况

个人对微服务比较恶心的点是：
1.后期规模起来的服务之间的循环调用 A→B→C→D→A 。
2.API 会存在大量冗余重复的不好管理，针对老接口改动不知道调用方有多少，为了不影响，所幸新加一个 V2 的接口 重新实现一套逻辑。以此后面可能有样学样就有 v3 v4 v5 版本。
3.大量的 DTO 的内部转换，大量一模一样的 javaBean 加个字段可能要改十几个类
4.比正常单体吃内存，毕竟部署多了 重复的 bean 、框架的开销。

[ilvsxk]

@dongzhuo777 #69
主要是单体的话，靠日志在本地或者测试环境复现的难度小很多。
如果不是微服务，而是某个模块，那我可以直接 debug 一步一步调试就可以，也可以做各种 mock 方便我复现。
但是微服务的话，拿着各种服务的日志做对一堆服务做排查，还会碰到某个服务是完全不同的语言写的，这一下子时间成本就上来了。
单体就像是独立开发，微服务就像是多人合作，上下文切换和沟通成本变大了。
确实你说的没错，日志的问题换成单体也会碰到，只是单体相比起来排查起来更容易些。

[WashFreshFresh]

看人吧，之前我一个人维护 7 个服务也没有啥问题...

[IamUNICODE]

@ilvsxk 我敲，你这是真的经历过的，把我们这里遇到的问题说的明明白白

[xiaocaiji111]

说白了，没设计好，尽量单向调用。不然链路像毛线。但是大部分开发不会这么想，而是能掉通就行。后面维护简直吐血。

[atpex]

说个题外话，我有点搞不明白为什么你这么一个很正常的问题有几个回答看起来像“高潮”了一样，有人能给我解惑一下嘛。

[IamUNICODE]

@atpex 这。。哪几个问题？是否有可能是你自己脑补过度？

[IamUNICODE]

@atpex 哦，你说回答啊，有可能是现实生活中被怼得火大，线上也火大了吧，或者坚信自己选的路线就是最好的——这就是信仰的力量~

[IamUNICODE]

@dongzhuo777 你说的问题这里也有，一起过来的前团队同事说这边一个前端项目接口要 300 多个，参数重复接口可以 10 个接口对一个功能页，具体没看是怎么回事，可能是需求，也可能是推了重写的，而且这只是管理端，这项目的重点是在 app 。。。

[sujin190]

@dongzhuo777 #69 暂停你这个说法，不是微服务不行，是实际过程中各种过度设计的，不应该拆的要么不知道怎么搞项目架构设计要么偷懒，各种该拆不该拆微服务的都瞎拆，还有各种循环依赖循环调用，各种兼容性不管疯狂开新版本接口，各种日志不按规则写瞎写乱写的，链路追踪什么的瞎弄不统一，我司就是这样的，好好的给他们弄一波，过不了三个月又乱七八糟了，不是微服务不行，就这样的单体服务一样乱七八糟好不到哪去

[libook]

@IamUNICODE #11 没有一个固定数目，每个公司的情况都不一样。

微服务的划分是参考业务复杂度和人员组织架构来考虑的，目的就是降低项目的维护复杂度、提升项目管理的灵活性、灵活分配各服务的资源配置、服务间做故障隔离。如果你们使用微服务思想却又没有获得相应的好处，肯定就是有问题。

比如看看是不是有一些微服务可以合并，是不是有一些微服务的人员团队职责不清楚，是不是一些微服务要交接给更适合的人员或团队可以在生产流程上更高效。甚至可以看看是不是人员组织架构划分与实际业务开展不相符。另外大的后端团队是否没有定期梳理微服务和开发协作中的问题，是否没有进行服务治理，是否对于一些公共领域的技术没有形成公司标准。

[libook]

任何一项技术、思想都只是实现需求的工具，都有其适合的场景和不适合的场景，应用之前要评估清楚是否能能够使生产获得收益、如何使收益最大化，没想清楚就硬上，多么高大上的技术最终都会变得“不好用”。