想在网上挨骂，最简单的方法就是写点关于微服务架构的东西。每个人对微服务都有自己的一套见解;无论我们是赞扬还是批评，总会有人跳出来强调“你错了”。行吧，这毕竟是个遍地懂王的时代，挨喷实属难免。我最近也写了几篇关于微服务的热闹文章，读者们的评论可谓鱼龙混杂、荒诞与睿智交融。但必须承认创赢策略，我们确实能从中提炼出构建微服务架构时的几种常见错误。首先需要明确一点：构建分布式系统确实相当复杂。当然，单体式系统的构建也不简单。但二者的区别在于，分布式系统的复杂度有很大的空间，而很多人的实施方案在毫无必要的情况下拉升了复杂水平。任何有经验的开发者或者架构师都认为，大多数人实际并不需要全盘接纳微服务。所以接下来要讨论的重点，就只针对那些确实有必要采用微服务架构的场景。
[[416889]]
另外，我们的团队在尝试微服务方面确实起步较早，而且几乎把能犯的错误都犯了个遍。下面我就来聊聊我们自己当年吃过的那些亏。
1. 定制化构建太多微服务架构中各服务间的通信往往正是麻烦的来源。有人认为之所以让人头痛，是因为事务也被系统架构给硬生生“分布”掉了。以典型的电子商务应用为例，微服务架构下的新订单创建流程可能需要在多项不同服务之间进行操作，例如订单与客户服务。而在单体式应用中，创建新订单就只需要调用一个函数。大家当然可以用saga来处理多服务事务创赢策略，但saga本身的实现难度也同样不低。
但我们确实没找到更好的办法，于是我们选择基于编排的saga解决这个难题。这种方法的优势，是让我们以定制化方式在各服务中使用消息代理实现saga的通信与执行。接下来，使用Redis流与Go语言构建之后，最终产出的成果相当整洁、整个实现过程也充满趣味。但事后来看，我们当初就不该用微服务架构，这类应用完全就是单体式架构的理想场景。
2. 复杂性失控这个问题的实质在于经验：从技术上讲，有些路线压根就没必要尝试，因为明显跟项目时间表和当前团队的技术水平相冲突。如果意识不到这一点，或者说误以为微服务是万能的，那麻烦紧跟着就来了。
请允许我强调一点：单单在YouTube讲座里听得热闹，并不代表那些解决方案就能在我们自己的项目中顺利起效。所以最好能预先给能够承受的复杂度设置明确的上限，这样能给大家省下大量宝贵时间。换个角度说，这类问题也可能源自“我们留的时间太多了”——如果项目的截止日期更紧，没准就不会瞎折腾什么微服务架构了。
这里同样需要认真权衡——如果把复杂度设置得太低，那我们最终拼凑出来的就是一架由筷子组成的飞机;但如果复杂度被定义得过高，那我们的飞机永远也没机会离开跑道。无论哪种情况，都不是我们希望见到的。所以大家最好能先把项目要求整理明确，然后发布在Medium上进行求助，聪明的工程师们肯定会给你一些靠谱的建议。
3. 定义过于松散最后，别指望一套方案就能解决我们的大部分问题。归根结底，分布式架构的出现就是为了解决一个特定问题。所以在决定使用之前，先弄清楚分布式适合解决什么问题、您自己面对的是什么问题，二者之间到底匹不匹配。但那时候，我自己的团队这几点都没做到。毕竟，谁会在起步阶段就花几天时间明确定义问题?能这么干的团队太少见了，大多数人都习惯于先干再说。现在，我们意识到正确定义问题能让自己少走弯路、反而节约了时间。正所谓磨刀不误砍柴工，先把要解决的问题搞清楚真的非常重要。
很遗憾，那时候我们自己没能做到。我们的探索不仅白白浪费了时间和金钱，而且没能得到任何有意义的产出。我们构建了不少后来压根用不上的东西，现在想想倒不如拿这段时间给大家放个假，至少还能提振一下士气。总之，先明确问题、再跟预期中的解决方案进行比对，这很重要。
如果一意孤行创赢策略，结果就会像我这样——浪费大量时间开发了一堆垃圾，再把其中的血泪教训总结成文章发在这里供大家一乐。好在我们没把自己折腾死，所以各位才有机会读到这篇文章。要警惕啊，同志们!
振兴配资提示：文章来自网络，不代表本站观点。
