简历驱动开发？微服务中的几种失败路径

本文要点：

• 微服务是一种手段而非目标
• 分布式并不能确保解耦性
• 契约测试在所有微服务架构中都是重要组成部分
• 前端、后端和集成层，以及业务逻辑中都需要做分解
• 如果企业没有能力快速、独立地发布微服务，就会丧失微服务的许多收益

在去年 11 月的 QCon Plus 上，我 介绍 了微服务可能走入歧途的一些路径。我是 IBM 的一名 顾问 ，我的一部分工作是帮助业务迈向云原生。本文提到的这些问题都是从我的经验总结出来的--不幸的是，它们在实践中是非常常见的。

我看到的第一个问题是，有时我们甚至不知道问题出在哪里。我们认为自己应该去做微服务，但却并没有真正花足够的时间去搞清楚为什么我们要这样做。

我们要解决的是什么问题？现在我们遇到了哪些痛点？我们做了微服务之后，哪些事情会迎来改善？人们总是倾向于尝试新事物，尤其是对我们这些技术人员来说更是如此。我们想一步跳到解决方案上，想要把玩闪亮的新玩意儿。可悲的是，虽说弄清楚我们要解决的问题是非常重要的，但这远没有尝试新的解决方案来得有趣。

容器加速了我们渴望尝试新方案的倾向，因为它是一种魔法般的技术，堪称伟大的解决方案。它们是如此轻巧、如此便携，让许多事情都能变得更好。于是到最后我们打定主意：“因为我已经有了这么多容器，如果只在一个容器中运行我的应用程序，那将是对容器能力的严重浪费。我应该在尽可能多的容器中运行它！”不幸的是，“没有足够的容器”并不是一个有意义的问题表述。

简历驱动的开发

我看到的另一个问题是 简历驱动的开发 。我们瞧了瞧自己的简历，里面应该写着“微服务”的地方空白一片。这看起来可不够水平，所以我们会说，“我可以通过重构公司的技术栈来解决这个问题”。你可能在想，“不，这也太夸张了，Holly。肯定没有人真的会为了他们的简历来做架构决策吧？”事实证明......他们会的。

红帽公司最近做了一项调查，研究了基于容器的开发工作的主要驱动 因素 ，结果发现职业发展是头号驱动力。所谓职业发展，就是简历驱动开发的高情商说法而已。

在简历上缺少微服务的开发经验可是了不得的大事，因为目前微服务简直就是新的标准规范。就算我们没有加入疫情以来的离职大潮，此刻也没有再寻找新的工作，我们也不希望自己成为异类。当我们环顾四周，发现似乎其他人都在做微服务，那么我们当然会想：如果他们都在做微服务，我却不做会不会有什么问题？我把这种心理称为“微服务羡慕”。

微服务不是目标

“微服务羡慕”是一个问题，因为微服务并不是我们应该羡慕的那种东西。我们的一个顾问有一个诀窍，如果一个客户一直在谈论 Netflix 并想要转向微服务，他就知道这桩合作有问题了。几乎可以肯定的是，他们转向微服务并没有正确的理由。如果对话更深入一些，涵盖了耦合和内聚等内容，那么他就知道合作的方向没什么问题。

微服务转型的出发点不应该是微服务本身。微服务是实现业务敏捷