三项转向微服务架构的错误

Posted 2021-04-14 云技术

在我们摆脱单一体系结构的过程中，我们在微服务迁移中遇到了三个矛盾，我们还研究了解决这些问题的方法。

我的公司CircleCI非常相信事后分析，在我们迁移到微服务架构之后，我们有了一个很好的机会来对我们做对和做错的事情进行事后分析，以及下一次我们做什么改变。如果你正在考虑开始微服务的旅程，我想分享一些建议，以创建更平滑的过渡。

当我们在2015年发生24小时停机时，我们有了摆脱单一架构的迫切性。我们希望保持谨慎：我们听到很多关于从全面转换到微服务时做出糟糕决策的故事。另一方面，体系结构的渐进式改变并没有带来我们需要的转换。早期的胜利打破了我们的体系结构，这让我们相信这是我们团队的正确方向，我们决定全力以赴。几乎同时，轮子开始从马车上脱落。工程生产力停滞不前。我们意识到我们正在把人们扔到一个陌生的环境中，就像从巨型小镇的舒适小镇到未知的微服务大城市一样。

在我们分析后，我们在微服务迁移中找到了三个矛盾来源，并且我们开发了解决这些问题的方法。

1决策

“分析艰难”，临着一个如此复杂的决定，你可以花时间考虑所有的选择，而不用在任何事情上拉动触发器。解决方案是尽早作出艰难的决策，然后将未来的决策制度仅限于例外，只有在最初的决策失败时才选择朝另一个方向发展。

在我们的案例中，对我们的工程师说：“我们是一家Clojure商店。不能决定要使用哪种语言或堆栈。我们都知道Clojure，它对我们很好。“

在决定使用gRPC，Postgres，Docker和Kubernetes时，我们觉得我们已经达成了一个共同的协议栈来为项目提供服务。事实证明，这些决定的细微差别比我们预想的要复杂得多：Clojure的哪个版本？什么库？

虽然我们认为我们已经做出了重要的决定，但我们并没有预料到我们将要面临的决策深度。那么，我们学到了什么？我们本可以花更多时间在前期制定指导，但在敏捷的世界中，这不是一个很好的时间投入。相反，团队需要一个非常明确的如何做出决策的定义，谁可以做出决定，以及如何有效地与团队其他成员分享这些决策。因为你一开始就无法预料到每一个决定，所以要确保你有明确的协议来顺利处理意外情况。

3新奇

工程师喜欢新的东西。有时候，这是因为旧的东西没有圆满地解决我们的问题，在这种情况下寻求新的解决方案是有意义的。但有时候，旧的东西可能是你的微服务项目的正确选择。转向微服务本身就是一个重大变革，因此限制其他变更是一个明智的策略。

在CircleCI，我们自2011年以来一直是MongoDB的商店。正如他们所说，这是我们所了解的魔鬼。但是当我们转向微服务时，我们认为这是一个回到PostgreSQL的好机会，我们很多人都喜欢它。事实证明，人们并不像我们所设想的那样深刻地了解Postgres，而这最终产生了更多的摩擦和新颖性，而不是更少。

为了理解哪些工具和系统因为新颖性（或习惯）而被单独使用，团队成员之间进行高级沟通。花时间研究如何推出每种工具以获得更广泛的用途（并且为了更好的理由而不是新颖性）。你不希望发现每个人都试图独立解决问题并遇到完全相同的问题，因此切换到常用工具将帮助每个人都快速移动。

3重复

根据新颖性，重复是一个问题，如果你不停止它的话，它会拖垮你的微服务雄心。在我们的案例中，我们发现三名工程师决定编写自己的库来处理gRPC通信框架。这是浪费时间。

我们学到的教训是，可以使用共享组件来解决基础设施问题。微服务的价值在于他们解锁的自主性，但随着自主权的增加，开销也会增加。关键是要找到由共享组件创建的值超过开销的区域。但是不要让个别团队做出这些取舍;使其成为某人的工作势在必行，以便该人员可以评估团队的整体收益。不能解决其他团队需求的共享组件不会最终成为共享组件。

在我们的案例中，我们创建了行业协会，这些协会是围绕专业领域建立的跨团队组织。 例如，我们的网站可靠性工程（SRE）公会每周都有一次会议，任何人都可以参加。当人们在处理同样的问题时（比如gRPC库或连接数据库），我们可以集中工作。

今天，在我们最初推出一年多以后，我们感受到了微服务的影响。我们的运行速度是以前平台利用率的五倍，旧操作问题（如缓慢建立和停机）已基本消失。我们成功了，因为我们认识到这个项目是对工程的投资，而不是为客户提供价值的产品。

当你将体系结构分解为微服务时，在这一点上获得收益是关键，因为你将做出大量的前期决策和投资。如果选择像这样零碎的过渡，请注意将面临很多返工。在迈出迈向微服务的第一步之前，请务必就此投入进行健康的交流。

↓↓ 点击"阅读原文" 【加入云技术社区】

相关阅读：

更多文章请关注