思在网上挨骂，最通俗的法子便是写点对于微劳动架构的东西。每个东谈主对微劳动齐有我方的一套见地;不管咱们是陈赞仍是品评，总会有东谈主跳出来强调“你错了”。行吧，这毕竟是个随地懂王的时间，挨喷实属未免。我最近也写了几篇对于微劳动的吵杂著作，读者们的驳斥可谓鱼龙混合、乖张与贤明会通。但必须承认，咱们如实能从中索取出构建微劳动架构时的几种常见乌有。最初需要明确小数：构建散布式系统如实至极复杂。虽然，单时局系统的构建也不通俗。但二者的分离在于，散布式系统的复杂度有很大的空间，而许多东谈主的实施有策画在毫无必要的情况下拉升了复杂水平。任何有履历的开发者或者架构师齐以为，大多数东谈主践诺并不需要全盘摄取微劳动。是以接下来要参谋的要点，就只针对那些如实有必要礼聘微劳动架构的场景。

[[416889]]

另外，咱们的团队在尝试微劳动方面如实起步较早，况兼险些把能犯的乌有齐犯了个遍。底下我就来聊聊咱们我方曩昔吃过的那些亏。

微劳动架构中各劳动间的通讯继续恰是发愤的起头。有东谈主以为之是以让东谈主头痛，是因为事务也被系统架构给硬生生“散布”掉了。以典型的电子商务期骗为例，微劳动架构下的新订单创建经由可能需要在多项不同劳动之间进行操作，举例订单与客户劳动。而在单时局期骗中，创建新订单就只需要调用一个函数。各人虽然不错用saga来处理多劳动事务，但saga自己的竣事难度也通常不低。

但咱们如实没找到更好的主张，于是咱们弃取基于编排的saga惩办这个难题。这种法子的上风，是让咱们以定制化花样在各劳动中使用音问代理竣事saga的通讯与扩充。接下来，使用Redis流与Go谈话构建之后，最终产出的效用至极整洁、总共这个词竣事过程也充满有趣。但过自后看，咱们当初就不该用微劳动架构，这类期骗十足便是单时局架构的理思场景。

这个问题的本质在于履历：从期间上讲，有些阶梯根柢就没必要尝试，因为赫然跟技俩时刻表和面前团队的期间水平相浮松。要是默契不到这小数，或者说误以为微劳动是全能的，那发愤紧随着就来了。

请允许我强调小数：单单在YouTube讲座里听得吵杂，并不代表那些惩办有策画就能在咱们我方的技俩中获胜起效。是以最佳能事先给大致承受的复杂度开辟明确的上限，这样能给各人省下多数珍视时刻。换个角度说，这类问题也可动力自“咱们留的时刻太多了”——要是项指标铁心日历更紧，没准就不会瞎折腾什么微劳动架构了。

这里通常需要持重衡量——要是把复杂度开辟得太低，那咱们最终勉强出来的便是一架由筷子构成的飞机;但要是复杂度被界说得过高，那咱们的飞机恒久也没契机离开跑谈。不管哪种情况，齐不是咱们但愿见到的。是以各人最佳能先把技俩条目整理明确，然后发布在Medium上进行求援，贤人的工程师们确定会给你一些靠谱的冷漠。

终末，别指望一套有策画就能惩办咱们的大部分问题。归根结底，散布式架构的出现便是为了惩办一个特定问题。是以在决定使用之前，先弄明晰散布式相宜惩办什么问题、您我方靠近的是什么问题，二者之间到底匹不匹配。但当时候，我我方的团队这几点齐没作念到。毕竟，谁会在起步阶段就花几天时刻明确界说问题?能这样干的团队太畸形了，大多数东谈主齐民俗于先干再说。当今，咱们默契到正确界说问题能让我方少走弯路、反而简陋了时刻。正所谓磨刀不误砍柴工，先把要惩办的问题搞明晰确凿相等进军。

很缺憾，当时候咱们我方没能作念到。咱们的探索不仅白白花费了时刻和钞票，况兼没能取得任缘何意旨的产出。咱们构建了不少自后根柢用不上的东西，当今思思倒不如拿这段时刻给各人放个假，至少还能提振一下士气。总之，先明确问题、再跟预期中的惩办有策画进行比对，这很进军。

要是一意孤行，收尾就会像我这样——花费多数时刻开发了一堆垃圾，再把其中的流泪履历顾忌成著作发在这里供各人一乐。好在咱们没把我方折腾死，是以诸位才有契机读到这篇著作。要警惕啊，同道们!