最容易被网上骂的就是写微服务架构的东西。每个人对微服务都有自己的一套看法；无论我们表扬还是批评，总会有人跳出来强调“你错了”。好吧，毕竟这是一个王者遍地的时代，被喷也是在所难免的。我最近还写了一些关于微服务的搞笑文章，读者的评论是荒谬和智慧的混合体。但必须承认的是，我们在构建微服务架构时，确实可以提炼出几个常见的错误。首先需要明确一点：构建分布式系统确实是一件相当复杂的事情。当然，单体系统的构建并不简单。但是两者的区别在于，分布式系统的复杂度有很大的空间，很多人的实现都无谓地增加了复杂度。任何有经验的开发人员或架构师都会同意，大多数人实际上并不需要全面接受微服务。所以接下来讨论的重点只是针对那些确实有必要采用微服务架构的场景。此外，我们的团队确实很早就开始尝试微服务，并且几乎犯了所有可能犯的错误。下面我说说我们自己当年所受的损失。1.自定义构建太多微服务架构中服务之间的通信往往是麻烦的根源。有人认为，之所以让人头疼，是因为交易也硬生生被系统架构“分散”了。以一个典型的电商应用为例，微服务架构下新的订单创建过程可能需要在订单、客服等多个不同的服务之间进行操作。在单体应用程序中，创建新订单只需要调用一个函数。当然你可以使用saga来处理多服务事务，但是saga本身的实现难度也不低。但是我们确实没有找到更好的办法，所以我们选择了orchestration-basedsaga来解决这个问题。这种方式的好处在于，可以让我们以自定义的方式在各个服务中使用消息代理，实现saga的通信和执行。接下来用RedisStream和Go语言搭建后，最终的输出还是比较工整的，整个实现过程充满了乐趣。但事后看来，我们一开始就不应该使用微服务架构。这种类型的应用程序是单体架构的理想场景。2.复杂度失控问题的本质在于经验：从技术上讲，有些路线根本没有必要去尝试，因为它们明显与项目进度和当前团队的技术水平相冲突。如果没有意识到这一点，或者错误地认为微服务是万能的，那么麻烦就会随之而来。请允许我强调一点：仅仅因为您在YouTube演讲中大声听到它，并不意味着这些解决方案将在我们自己的项目中顺利运行。所以，最好事先对可以容忍的复杂度设定一个明确的上限，这样可以为大家节省很多宝贵的时间。另一方面，这种问题也可能来自于“我们留的时间太多了”——如果项目deadline比较紧，可能就没有微服务架构了。这里也有谨慎的权衡——如果复杂度设置得太低，我们最终得到的是一个用筷子做成的飞机；但如果复杂度定义得太高，那么我们的飞机将永远没有机会脱离轨道。无论哪种情况，都不是我们希望看到的。所以大家最好先梳理一下项目需求，然后发到Medium求助。聪明的工程师一定会给你一些靠谱的建议。3.定义过于宽松最后，不要指望一套解决方案就能解决我们的大部分问题。归根结底，分布式架构的出现是为了解决一个特定的问题。所以在决定使用之前，先搞清楚分布式适合解决什么问题，你面对的是什么问题，两者是否匹配。但当时，我自己的团队没有做到这些事情。毕竟，谁会在一开始就花几天时间把问题定义清楚呢？这样做的团队非常罕见，以至于大多数人习惯于先做。现在，我们意识到正确定义问题可以让我们少走弯路，节省时间。俗话说，磨刀不误砍柴。首先弄清楚要解决的问题真的很重要。可惜当时我们自己做不到。我们的探索不仅浪费了时间和金钱，而且也没有产生任何有意义的成果。我们构建了很多后来根本没有用到的东西。既然这么想，倒不如趁着这段时间给大家放个假，至少还能提振士气。总之，重要的是首先定义问题，然后将其与预期的解决方案进行比较。如果一意孤行，结果会像我一样——浪费大量时间开发一堆垃圾，然后把血泪的教训总结成一篇文章供大家欣赏。好在我们没有把自己折腾死，所以大家才有机会看这篇文章。警惕啊战友们！
