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]

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

[fkdtz]

查问题困难问题出在没有统一规范吧，如果各服务有统一的输入输出标准和监控项，加上链路追踪，起码可以快速定位到是哪一个服务的哪一个接口出问题

[sagaxu]

2015 年开始搞微服务，全套自研，大概有一两百个独立服务，然后哦业务数据还不错，冲击上市。2019 年开始搞中台，然后迅速下坡路，2024 年还剩不到 10%的员工。

以上只是时间上有耦合，无因果关系。

[GooMS]

可以有效解决大家没事做的问题

[momo2789]

人菜草台班子跟微服务没关系啊

[miscnote]

微服务不止是搞搞研发，通常 sre 也要跟上。所以大公司喜欢弄这个，小型公司就没必要为了这个名词而去跟风了。

[idblife]

@IamUNICODE 50 个不算多，我们有一千个左右

[opengps]

你要说中台还行，属于业务层面；微服务纯技术架构，背不了这锅

[skyworker]

@bronyakaka 其实最重要的一点是, 没有微服务经验, 下一份简历不好写

[murmur]

我们是搞了微服务没有做容器化，还是用商业版的虚拟机

[IamUNICODE]

@idblife 6

[IamUNICODE]

@sagaxu 2019 年迅速走下坡路是因为经济形势吧

[yunpeng2015]

微服务会带来运维等方面的困难，如果设计的不好，没有很好监控 追踪管理，那么问题会更严重

[hangszhang]

组织架构决定系统架构，微服务又不是让一个人维护所有的子系统

[wlm201219]

接触过两个公司
一个从其它语言转过来的，项目组总共就十来个人，上来就要上微服务，结果半年的工期拖成了一年，老板贴钱给员工发工资，最后幸好上线了，也是不幸中的万幸

另一个更搞笑，总共二十来个人，硬是拆出了 50 多个微服务，平均两张表一个微服务，无法理解。后续就没关注了，大概已经没了吧。

[lvsshuttao]

就算没有链路追踪，请求其它接口返回的数据也会打一下日志的吧😅

[sagaxu]

@IamUNICODE DAU 早在 2017 就到顶了，DAU 开始下坡路的时候，如果不能挽救，那就只剩赚钱套现一个思路了，一切向钱看的时候，死的更快。很多 App 都这样，广告位越来越多，黑五类广告来者不拒的时候，结局就注定了。

[gitrebase]

@IamUNICODE #11 你们一个组的微服务有 10 个吗我靠

[ClericPy]

十年前的微服务，和十年后今天的云原生一样，好好学几个月再上，又快又稳定

一点都不学闭着眼百度搜个 CSDN 就上，写出来的跟屎一样然后加薪跑路，这锅甩的一点都不优雅

两句话深以为然：软件工程没有银弹；人和人的差距比人和狗的差距都大。水平不够的反而感觉写点小脚本上 serverless 更不耽误下班时间

[diagnostics]

你要是说无脑拆微服务，那确实有问题。

哪个大型项目不拆分服务？举例：B 站历史记录和评论系统分别崩溃过一次，但是其他播放等功能完全不受影响。（你单体试试？）美团的优惠券券查询页面崩溃过一次，但是下单、浏览，甚至使用优惠券都不受影响（你微服务试试？）

阿里云去年崩溃过一次，整个淘宝几乎不能访问了。

排查问题，写出你们的排查路径，最后发给大伙看看有没有可优化点，然后你也再复盘，而不是一味得怪这怪那。

菜就多练。我们排查问题，虽然部署了 skywalking ，但是没权限，但是我们日志里也会记录一下 traceID ，用集中式日志检索平台一搜索（ splunk ），看哪个系统没打这个记录（我们这一个请求最多跨 5 、6 个），再去这个系统去看具体的日志。

[IamUNICODE]

@diagnostics 按照功能拆不难理解，之前我们也是这样拆的，但是这么分散，还是很难理解的。
你说的这些这边都有，但是最后发现是某个包没升级造成字段缺失，这个排查有什么优化方案么——我是不怎么懂哈，毕竟我没有做过这种微服务，所以你是觉得这边人很菜吗？

[pegasusz]

@yuanmomo 说得很中肯

[Features]

我也想问一下，有人用 PHP 的 hyperf 搞微服务吗？
前几年进一家公司，技术主管非要跟风搞这个
一大堆坑，传统的 PHP 库没几个能正常用的，搞了几天我跑路了

我私下问主管，都用 hyperf 为啥不用 springboot
主管说的很直白，反正都是打工，给自己增加一点资历

[me1onsoda]

微服务搞起来得整配套措施，链路追踪是标配。你那小伙子也是之前负责项目的一部分，搞不清楚很正常，一个人能把整个搞清楚的项目一般不用上微服务，不会太复杂。

[bronyakaka]

@diagnostics 单体又不是只部署一个实例，前面有负载均衡 机器挂了也有别的服务接收流量，微服务本质上没有解决任何技术问题，只是方便大公司人去开发，别上来说人菜就多练，你也好不到哪去

[diagnostics]

@bronyakaka #43 你理解的服务挂就只是一个节点挂掉？我没根据一个一个点，说别人菜就多练？

> 排查问题，写出你们的排查路径，最后发给大伙看看有没有可优化点，然后你也再复盘，而不是一味得怪这怪那

我不想说脏话，这句话你看不到吗？

[diagnostics]

@bronyakaka #43 哦，原来是上个 webp 转 jpg 的人，并发编程都不懂的人，Blocked 了。

[diagnostics]

@IamUNICODE #39 定位工具都有，那排查问题还要 2 天，不就是经验问题吗？多在 dev 环境练，没问题吧？

另外，遇到问题，能反思的点很多，上来对架构做出质疑的，你别在 V2 发帖子，怼你领导，怼你 CTO 啊，你又没胆子，有胆识说服老板让你当 CTO/架构师，改为单例。

上面的话说的不好听了点，但良言难劝该死鬼，你这不是技术能力问题，而是态度问题了。

冯诺依曼架构在现代计算机上还有性能问题呢，人家也是混合哈佛架构去优化了才是我们现代处理器的模型，难道你要设计师推倒重来？回到我的论证：你觉得在这个 path 下微服务架构不好用：

1. 优化流程，减少微服务的拆分（不是无脑拆，而是有必要的拆分），至于有个哥们回复我负载均衡网关+单体，我都不想搭理他（这难道没拆服务？说白了他就是学艺不精，别人上个帖子也是写了并发的软件，并发都没吃透，培训班水平）
2. 构建组织的优化：你的问题其实是这个，library 没升级和微服务压根不搭边好吧
3. 升级流程的优化：上线没人审核评审变动，需求开发前没评估升级风险

这些点都可以是问题的优化，对于你的问题，压根不在微服务，你这是 Structuring Projects 的问题，但你觉得为什么部分包要单独抽出来外部引用？就是为了一个 schema 升级时，上下游都可以同步开发，不依赖这个 schema ，如果一旦 schema 升级，是需要上下游找到对应的人的。（你可以参考今天的帖子： https://v2ex.com/t/1057143 ）

另外升级检查，也可以写个 maven 插件来搞定（假设你是 java 项目）

八杆子打不到微服务架构上。。。。

[xuld]

这个问题本身存在一些观念上的误区。

任何一个问题的出现都是多方面引发的，绝不能简单地认为就因为一个点导致的。

这也是争论的来源，每个人说的观点从某一角度看都是正确的，但放在一起就是会出问题。

现在的问题是：出现了维护困难，一个熟悉代码的人都需要很久才可以定位问题。

所以你的期望的解决问题的方案是什么呢？

A：就是微服务导致的，微服务是个垃圾？
那请问全球所有做微服务的项目都维护困难了吗？
为啥有人没问题，而你的出问题了。

B：如果不用微服务，问题就解决了？
那请问全球所有没用使用微服务的项目都维护简单了吗？
显然不是。

那回过头来说，到底要不要用微服务？

这问题本身是一个非常傻的问题，就像我问你出门会不会开车一样，你一定会回答“看情况”一样。

微服务是一种工具，而人才是关键。

如果你认为这东西用的溜，符合你思维逻辑，而你又需要对项目负责，你可以用。
如果你认为这东西用的太累，不用的更快，那就不用。

没有绝对的这东西“好”或“不好”

[bronyakaka]

@diagnostics 并发编程都不懂的人？你这么懂并发咱们可以讨论下，口气不用这么嚣张

[IamUNICODE]

@xuld 看下来就你一个人能心平气和讨论利弊，谢谢了大佬🤣

[GeekGao]

不要试图从结果否定一个理念哈，有的时候可能只是你们搞叉劈了。
项目管理混乱，显然不是技术架构的锅。

[GeekGao]

就我们的感悟而言，微服务确实加速了线上迭代效率，任务部署更容易、开发人员的心智也会得到一定的解脱。

[cinlen]

可以肯定的是和微服务本身没啥关系。

我觉得你可以问问那个小伙子是怎么定位问题的，然后研究研究怎么让下一次 "定位问题” 变得简单。

[Linxing]

微服务是搞了 对应的 infra 没跟上吧？

[kk2syc]

@IamUNICODE 你对团队和谐的理解有错误。不是说不吵架就叫和谐。表面上每个人和和气气，背地里互相使坏就和谐了吗？真正的和谐是公平的环境，合理的制度，没有小心思的同事，不搞斗争的领导，公事公办的老板

[Vegetable]

不少人上来就是菜就多练，挺搞笑的。
微服务其本身的会引入什么问题已经被讨论烂了，op 说这些也都没有离开这个范畴。
这些都是客观存在的问题，上马微服务就是要谨慎，要权衡，不是什么万金油方案，无论人的水平如何。

[IamUNICODE]

@kk2syc 啊这，有前者不代表后者会少吧，尤其是人多的地方，基本上没办法避免了——尤其是定位问题困难的时候，笑死

[tyrone2333]

你头像好像朱元璋😂

[skuuhui]

东施效颦

[tairan2006]

50 多个微服务，你们团队有多少人啊……

一般小团队，微服务拆分要很谨慎，太多了就没法维护

[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]

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

[boboaiya3]

凤凰架构

[azhong123]

@idblife 老板只需要考虑裁员,CTO 要考虑的就多了

[runninghipp]

非常不好

[Richared]

我已经参与过两次微服务改单体了。做的算法模型平台，压力根本不在业务测，都在 hadoop ，spark ，flink 上。现在没钱招那么多人，也不招工资高的，根本维护不了。

[wqhui]

定位问题耗时长
一、bug 原因确实复杂，需要特定条件才能触发，可能涉及硬件或者非自己系统代码问题
二、监控、日志没做到位，关键日志丢失或者不好找，比如没做微服务日志收集管理
三、研发人员太菜没经验

[Navee]

很不错的
行情好的时候拆微服务 kpi
行情不好了合并微服务又是 kpi

[jeesk]

@Navee 当年上云， 成本减少 50%。 这几年下云， 成本有减少 50%。 双赢。

[shadowyue]

😅还微服务呢，看我之前发的那个跨域问题的帖子，有多少个收藏，吵架了多少个跟帖，你就知道大家水平都是草包。
怎么简单怎么来才是最好的。真的遇到瓶颈了再去想办法。

[ilvsxk]

@shadowyue #88
这就有点过了吧，怎么大家都是草包了？
你那个帖子说明你对跨域停留在简单理解上，并没有太多实际业务中的跨域边界问题实践经验。

[shadowyue]

@ilvsxk 世界上百分之 99 的人都是草包，我也是草包，草台班子才是世界的常态。

[lasuar]

小公司搞不定微服务，80%的问题都是水平问题。

[1252603486]

控制项目复杂度是最难的，一个项目复杂度上去之后，什么框架都没用，直到最后彻底无法维护，公司决定重写一个，毕竟公司可不关心项目是不是一坨屎，只要能赚钱就可以了。

[dongzhuo777]

@sujin190 我司这也这样乱过一阵子，后面复盘出现的很大一部分原因是 组织架构的调整，微服务的架构设计如果只是根据业务来划分，没有按照公司实际的物理组织架构去划分 后期一定会出现这种灾难的。

[adgad2]

微服务是这样的，项目复杂度至少比单机高一个级别

[dongzhuo777]

@adgad2 但是需要上微服务的项目复杂度本身就很高，有些项目系统都有几十个 要做集成不用微服务用单体 压根打包都做不到

[sujin190]

@dongzhuo777 #93 我司这个是既不按业务边界划分也不按组织架构划分，通过各种接口各种 mq 消息相互调，接口消息感觉就是想改就改，前向后向兼容几乎不咋考虑，也就是流量实在太低，各种人工改数据修正搞得定，客户不会分分钟打爆客服电话，否则感觉就是分分钟崩溃的节奏，都无语死了。。

[adgad2]

@dongzhuo777 不知道，之前我们做社交的上了微服务，复杂程度高了不少，挺考验技术的，本地开发也麻烦，docker 都要起好几个

[noyidoit]

@Richared 请问当年改成单体的过程中有没有遇到什么坑？可以简单讲讲吗

[pushback]

包升级跟微服务没太大关系，有些 leader 喜欢乱拆，多拆，才是最大的问题。

[JiRouWaZi]

微服务难道不爽吗？你们只是缺一个优秀的 devops ，如果整套工作流都走通了，爽爆