kaiyun.com 构建微管事时的三大常见乌有

念念在网上挨骂，最浅易的身手等于写点对于微管事架构的东西。每个东谈主对微管事皆有我方的一套观念;不管咱们是赞叹也曾月旦，总会有东谈主跳出来强调“你错了”。行吧，这毕竟是个随处懂王的时期，挨喷实属不免。我最近也写了几篇对于微管事的吵杂著述，读者们的沟通可谓鱼龙搀杂、荒诞与贤明和会。但必须承认，咱们照实能从中索要出构建微管事架构时的几种常见乌有。当先需要明确少许：构建散布式系统照实终点复杂。固然，单情景系统的构建也不浅易。但二者的折柳在于，散布式系统的复杂度有很大的空间，而许多东谈主的实施决议在毫无必要的情况下拉升了复杂水平。任何有资格的开导者或者架构师皆以为，大多数东谈主施行并不需要全盘遴荐微管事。是以接下来要询查的重心，就只针对那些照实有必要遴荐微管事架构的场景。

[[416889]]

另外，咱们的团队在尝试微管事方面照实起步较早，况兼实在把能犯的乌有皆犯了个遍。底下我就来聊聊咱们我方畴前吃过的那些亏。

1. 定制化构建太多

微管事架构中各管事间的通讯频频恰是奋力的起原。有东谈主以为之是以让东谈主头痛，是因为事务也被系统架构给硬生生“散布”掉了。以典型的电子商务诓骗为例，微管事架构下的新订单创建经由可能需要在多项不同管事之间进行操作，举例订单与客户管事。而在单情景诓骗中，创建新订单就只需要调用一个函数。环球固然不错用saga来处理多管事事务，但saga自己的完结难度也雷同不低。

但咱们照实没找到更好的目标，于是咱们取舍基于编排的saga处理这个难得。这种身手的上风，是让咱们以定制化神气在各管事中使用音信代理完结saga的通讯与实践。接下来，使用Redis流与Go言语构建之后，最终产出的效果终点整洁、总共这个词完结过程也充满真谛。但过其后看，咱们当初就不该用微管事架构，这类诓骗十足等于单情景架构的理念念场景。

2. 复杂性失控

这个问题的本质在于资格：从本领上讲，有些蹊径根底就没必要尝试，因为显然跟名堂时刻表和现时团队的本领水平相恣虐。如若贯通不到这少许，或者说误以为微管事是全能的，那奋力紧随着就来了。

请允许我强调少许：单单在YouTube讲座里听得吵杂，并不代表那些处理决议就能在咱们我方的名堂中顺利起效。是以最佳能事前给好像承受的复杂度确立明确的上限，这样能给环球省下无数可贵时刻。换个角度说，这类问题也可动力自“咱们留的时刻太多了”——如若项方针扬弃日历更紧，没准就不会瞎折腾什么微管事架构了。

这里雷同需要讲求量度——如若把复杂度确立得太低，那咱们最终勉强出来的等于一架由筷子构成的飞机;但如若复杂度被界说得过高，那咱们的飞机始终也没契机离开跑谈。不管哪种情况，皆不是咱们但愿见到的。是以环球最佳能先把名堂条件整理明确，然后发布在Medium上进行乞助，聪惠的工程师们细目会给你一些靠谱的提议。

3. 界说过于松散

临了，别指望一套决议就能处理咱们的大部分问题。归根结底，散布式架构的出现等于为了处理一个特定问题。是以在决定使用之前，先弄领会散布式合乎处理什么问题、您我方濒临的是什么问题，二者之间到底匹不匹配。但其时候，我我方的团队这几点皆没作念到。毕竟，谁会在起步阶段就花几天时刻明确界说问题?能这样干的团队太稀有了，大多数东谈主皆民俗于先干再说。当今，咱们贯通到正确界说问题能让我方少走弯路、反而省俭了时刻。正所谓磨刀不误砍柴工，先把要处理的问题搞领会确实很是弥留。

很缺憾，其时候咱们我方没能作念到。咱们的探索不仅白白浮滥了时刻和财富，况兼没能赢得任何故意思意思的产出。咱们构建了不少其后根底用不上的东西，当今念念念念倒不如拿这段时刻给环球放个假，至少还能提振一下士气。总之，先明确问题、再跟预期中的处理决议进行比对，这很弥留。

如若一意孤行，完结就会像我这样——浮滥无数时刻开导了一堆垃圾kaiyun.com，再把其中的陨泣教训回来成著述发在这里供环球一乐。好在咱们没把我方折腾死，是以诸君才有契机读到这篇著述。要警惕啊，同道们!