作者 | Mika Yeap
译者 | 刘雅梦
策划 | 田晓旭
在网上招致批评的最快方法就是撰写有关微服务的文章。每个人都有自己的观点。不管你是支持还是批判微服务。人们会找到你，并告诉你你错了。我很喜欢这样。我最近有幸就这个主题写了几篇热门文章。相应的评论都是滑稽和理智的完美结合。但它们对于识别真正的错误特别有用。
因为这能让我们面对现实：构建分布式系统可能会变得很复杂。公平地说，建造单体系统也是如此。但不同的是，我们大多数人选择了比分布式的复杂性更高的东西。任何有经验的开发人员或架构师都会告诉你，大多数人实际上不需要完全接受微服务。
我问过的所有人都建议将这两者相结合。并且只在绝对必要的情况下才需单独使用微服务。但我的团队没有这样，我当时没有这种智慧。所以我们抢先了一步。犯了书中提到的所有错误。以下是一些最令人震惊的错误示例。
1定制构建太多
在微服务领域，服务之间的通信是一个大问题。有人会说这是最大的问题。这一切都要归究于分布式事务。在电子商务应用程序的经典示例中，创建新订单的过程可能会涉及到需在多个不同的服务中进行操作，比如订单服务、客户服务等。在单体应用中，只需一个函数调用即可。但是使用微服务，情况就不那么好了。你可以引入 Sagas 来处理多服务事务。但这会让你感到脊椎发冷。实现 Sagas 并非易事。
尽管如此，我们还是不太清楚。所以我们实现了基于编排的 Sagas 来解决这个问题。优势之处在于我们定制了每个服务用来通信和执行这些 Sagas 的消息代理。使用 Redis 流和 Go 自行构建。当然，最终结果很好，建造起来也非常有趣。但我们本可以用做这个的时间，搭建一个单体应用。开始就失败了。
2复杂性不设限
这一点可以归结为经验：从技术上讲，有些地方是你不应该去的。给定一个特定的项目时间表和一个具有特定能力的团队，有些路径是你不应该探索的。我们的错误在于我们认为我们可以去任何微服务之神召唤我们的地方。
这是不正确的。不幸的是，这完全是错误的。在某种程度上，你会意识到，某些内容仅仅在 YouTube 主题演讲中听起来可行，但并不意味着在你的项目它们也是可行的。如果我们对我们愿意处理的复杂性设置了一个上限，我们就会为自己节省一些不必要的麻烦。我想你可以用另一种方式来表述这个错误，“我们给了自己太多的时间”。如果我们有一个更短的截止日期，这些麻烦将会自动消除。
话又说回来，这里有个很微妙的界限。如果复杂性限制设置的过低，你就会驾驶一架由筷子做成的飞机。但如果设置的过高，你就永远不会离开跑道。在这两种情况下，你都会完蛋。知道如何切馅饼通常来自经验。所以我建议你做出最好的猜测，然后在 Medium 上传播，以吸引更聪明的工程师的注意，他们会纠正你的错误。
3定义太宽松
最后，有一件事可以解决我们的大部分问题。归根结底，分布式架构是用来解决问题的。所以，在决定使用它之前，你需要知道这个问题是什么，你还需要了解你的解决方案，以确定它们的匹配程度。这两个我们都不了解。
因为谁会在一开始时就花上几天的时间来定义问题呢？这种纪律很少见，尤其是在需要立即构建的环境中。现在，我知道，通过更关注实现，可以节省正确定义问题所“损失”的时间。换句话说，你花更少的时间构建错误的东西。浪费的时间会少很多。因此，明智的做法是确保你正在构建的东西是正确的。
然而，我们没有。我们的弯路不仅花费了我们的时间和金钱。它们最终也是毫无意义的。我们建造并修复了我们不需要的东西。完成后，我们没有使用它们。在开发期间，我们还不如在办公室一直玩《英雄联盟》，这还能鼓舞士气。因此，很好地了解你的问题和解决方案并不是一个糟糕的想法。
话说回来，这其中的乐趣何在呢？在我看来，你也可能会浪费大量的时间去构建错误的东西，在这个过程中收集了经验来写文章，然后在网上抱怨。这对我们有用。我是说，我们还活着在讲述这个故事。
今日好文推荐
终于！RocketMQ发布5.0版本：架构大重构，代码变更比例高达60%
管人比管代码难多了，基础软件黄金时代“全自动软件工程平台”火了！
为什么除了Flutter之外，我们还需要另一个跨平台开发框架？
技术总监惨遭公司起诉索赔90万，原因是拖延开发进度？
InfoQ 写作平台欢迎所有热爱技术、热爱创作、热爱分享的内容创作者入驻！
还有更多超值活动等你来！
扫描下方二维码
填写申请，成为作者
开启你的创作之路吧~
点个在看少个 bug
