原文：The Death of Microservice Madness in 2018
作者：dwmkerr
翻译：Vincent

过去几年微服务已经赚足了眼球，到处都在讨论它。何为“微服务的疯狂”，举个例子：

Netflix公司在DevOps上做的非常好。Netfix也在开展微服务。所以有这样一个结论：如果我也做微服务，我也将非常擅长DevOps。

实际上已经出现过很多的案例证明有的团队完全是为了微服务而做的微服务，他们完全不顾及成本和收益，也不考虑微服务是否真的能够解决当前所面临的问题，只顾一味的投入巨大的努力来实现微服务模式。

在这篇文章中我将详细的描述什么是微服务，为什么微服务模式能如此吸引人，以及它所带来的一些关键问题。

如果你正在考虑微服务是否适合你，是否能帮你解决当前面临的问题？那继续往下看，我会用一系列简单的问题来帮你走出你的困惑。这一系列“问题”在文章的最后。

微服务到底是什么，为什么会如此受欢迎？

让我们先从基础开始讲起。下述是一个假想的视频共享平台实现的框架图，左边那个庞大的单元体是单体架构的实现形式，右边是微服务的实现形式：

这两个系统的区别在于前者是一个庞大的单位体。第二种是由一些微小而具体的服务组成的。每个服务都扮演着一个特定的角色。

当从系统细节层面来绘制图表时，那么就可以很容易看到微服务的优点了。微服务有很多潜在的好处：

独立开发:小型独立的组件可以由小型独立的团队去开发。团队可以在不干扰“Transcode”服务的情况下，对“Upload”服务进行修改，甚至都不需要了解“Transcode”服务。这样学习组件的时间就大大减少了，开发新功能也变得更加容易了。

独立部署:每个单独的组件都可以独立部署。这种特性就使得新开发的功能可以更快的上线，风险也更低，而且还可以在不需要部署其他组件的情况下对“Streaming”组件进行修复。

独立可伸缩性:每个组件都可以独立地伸缩。在需求多并发同时需要发布新的版本时，可以放大“Download”组件，以处理增加的负载，而不必扩大每个组件，这使得弹性缩放更加可行并降低了成本。

可重用性:是组件负责实现某一个小的、特定的功能。这意味着这些组件可以在其他系统、服务或产品中更容易兼容，使用也更方便。“Transcode”组件可以被其他业务部门使用，甚至可以变成一个新的业务，或者为其他组提供Transcode服务。

如果系统可以划分到这种粒度，那么微服务的好处是显而易见的。如果是这样，为什么这种模式最近才流行?为什么非要等到我的人生都快走到了尽头它才出现？

如果真的有这么好，为什么之前没有这样做呢

这个问题有两个答案。一是它强依赖我们最好的技术能力，另一个是最近的技术进步，促使我们能够把它带到一个新的高度。

当我开始写软文来回答这个问题的时候，发现这将会是一个很长的描述，所以从实际的角度出发，我将把它拆成两篇文章，稍后再发表。第1篇文章，我将跳过一些内容，比如：从单个程序到多个程序的过程，忽略ESB和面向服务的体系结构，组件设计和有限的上下文等等。

感兴趣的朋友可以稍后关于journey的信息。尽管，在很多方面我们已经这样做了一段时间，但是随着最近容器技术（特别是Docker）和编排技术（如Kubernetes、Mesos、Consul等等）的普及，从技术的角度来看，微服务模式变得更加可行。

因此，如果我们想要实施微服务的话，我们最好仔细慎重考虑是否真的需要。我们已经看到了高大上的“理论效益”，但值得一提的是，未知的挑战又是什么？

那么微服务存在哪些问题呢？

如果微服务这么棒，难道它就一点问题都没有吗？以下是我所知道的一些比较严重的问题。

增加了开发者的复杂性

对于开发者来说，事情会变得更加困难。开发人员如果想结束某一阶段的开发工作时，但是该阶段的开发成果关联到很多项服务，那么他就必须得在本地环境对接各种服务才能运行。跟单独运行一个系统相比，这种做法通常要复杂得多。

这个问题可以通过工具得到一些缓解，但是随着系统里面服务的数量增加，开发人员在整个系统运行时将面临更多的挑战。

增加了使用者的复杂性

对于不开发服务但维护服务的团队来说，潜在的复杂性是一个巨大的挑战。他们不是管理几个正在运行的服务，而是管理数十，数百或数千个正在运行的服务。服务越多，沟通越多，潜在的失败风险就越多。

增加了开发的复杂性

阅读以上两点，可能会发现运维和开发是分开处理的，尤其是考虑到DevOps作为一种实践的普及（我是DevOps的真爱粉）。DevOps难道不能缓解这一痛点？

目前面临的挑战是，许多组织仍然依靠独立的开发和运营团队来运行 - 而一些组织则更倾向于采用微服务。

对于已经采用了DevOps的组织来说，这仍然很难。既是开发者又是运维者，已经非常艰难（但是要建立好的软件却很关键），但是也必须了解容器编排系统的细微差别，特别是快速发展的系统是非常困难的。这使我想到了下一点。

有专业知识的限制

当很多事情都由专家完成时，最终的结果也将是极好的。但想象一下，一个机构或组织使用单一的整体系统并不总是可以很顺利的运行。那做些什么能够来改善并让这些事情变得更好呢？通过增加系统服务的数量？但同时也会增加运行的复杂性。

不可否认，通过有效的自动化、监控和编排等，这一切都可以改善。但挑战很少是技术本身——真正的挑战其实是找到能够有效使用技术的人。恰恰目前这些技能需求非常高，可能很难找到符合你需求的人。

现实世界的系统往往界限不清

在我们用来描述微服务的好处的所有例子中，我们都谈到了独立的组件。但是在很多情况下，组件并不是完全独立的。正所谓“纸上得来终觉浅，绝知此事要躬行”，某些领域可能看起来有限，但是当你陷入冗繁的细节时，你会发现他们比你预期的更具挑战性。

这是事情变得非常复杂的地方。事实上，如果你的边界没有明确定义，那么会发生什么情况呢？即使理论上的服务可以单独部署，你会发现，由于服务之间的相互依赖关系，你必须部署一系列微服务作为一个组服务。

这意味着你需要管理协同工作的版本，这些版本的服务在联调时会经过验证和测试，你实际上没有可独立部署的系统，因为要部署新功能，你需要仔细编排许多服务的同时去部署。

往往忽略了状态的复杂性

在前面的例子中，我提到一个功能部署可能需要同时部署多个版本的许多服务。假设合理的部署技术将缓解这种情况，例如蓝/绿部署（大多数服务编排平台很少原生支持这种功能），或者并行运行多个版本的服务，以及决定使用哪个版本的消费通道。

如果服务是无状态的，这些技术可以缓解大量的挑战。但是无国界的服务非常坦率，容易处理。事实上，如果你有无状态的服务，那么我会倾向于考虑跳过微服务，并考虑使用无服务器模型。

实际上，许多服务需要管理。我们的视频共享平台的一个例子可能是订阅服务。订阅服务的新版本可以以不同形状将数据存储在订阅数据库中。如果你同时运行这两个服务，则一次运行两个模式的系统。如果您进行了蓝／绿部署，而其他服务依赖于新形状中的数据，则必须同时更新这些数据，并且如果订阅服务部署失败并回滚，则可能还需要使用级联回滚。

同样，可能你会说，在NoSQL数据库中，这些架构问题会消失，但事实并非如此。不强制执行模式的数据库无法连接无模式系统——这意味着模式往往是在应用程序级而不是数据库级进行管理的。理解数据结构以及如何流转的根本性问题并不能被消除。

同样容易忽略的还有沟通的复杂性

当你建立一个相互依赖的大型服务网络时，可能会有很多的服务间通信。这导致了一些挑战。首先，有很多事情可能会失败。我们必须假设网络call可能会失败，这意味着当一个服务call另一个服务时，它应该至少需要重试几次。现在当一个服务可能调用很多服务时，我们最终会遇到一个更加复杂的情况。

用户上传视频共享服务中的视频。我们可能需要运行upload服务，将数据传递到transcode服务，更新订阅，更新建议等等。所有这些调用都需要一定程度的协调，如果过程中任何部分失败，我们都需要重试。

这个重试逻辑可能难以管理。试图同步做事往往会导致站不住脚，失败点太多。在这种情况下，更可靠的解决方案是使用异步模式来处理通信。这里面临的挑战是异步模式本身往往会使系统具有状态性。如前所述，分布式状态系统和有状态系统很难处理。

当一个微服务系统使用消息队列进行服务内通信时，你基本上需要有一个大的数据库（消息队列或代理）将这些服务组合在一起。同样，虽然起初看起来似乎不是一个挑战，但你懂的——出来混迟早都是要还的。X版本的服务可能会写入某种格式的消息，当发送服务更改发送的消息的详细信息时，依赖于该消息的服务也将需要更新。

当然，可以有许多不同格式的消息处理服务，但这很难管理。现在，在部署新版本的服务时，你可能会有两个不同版本的服务尝试处理来自同一队列的消息，甚至可能是由不同版本的发送服务发送的消息。这可能会导致复杂的边缘情况。为了避免这些边缘情况，仅允许特定版本的消息存在可能更容易，这意味着你需要将一组服务的版本作为一个整体来部署，以确保先前版本的消息被正确地屏蔽。

这再次突出表明，独立部署的想法可能不会像预期的那样顺利。

版本控制可能很难

为了缓解前面提到的挑战，版本控制需要非常谨慎的管理。再说一下，看起来貌似有一种趋势——假设遵循像Semver[4]这样的标准或许将可以解决这个问题。然而事实并非完全如此。虽然Semver是一个合理的使用惯例，但是你仍然需要持续的跟踪那些可以一起工作的服务和API的版本。

这可能会使事情变得非常具有挑战性，并且很多时候可能会让你感到困惑——哪些版本的服务可以一起正常工作。

在软件系统中管理依赖关系是非常困难的，无论是节点模块，Java模块，C库还是其他。当一个实体消费独立组件之间的冲突的挑战是很难处理的。

当依赖关系是静态的时候，这些挑战是很难处理的。虽然可以进行修补、更新、编辑等，但是如果依赖关系本身是实时服务，那么你可能根本无法更新它们——你可能需要运行许多版本（上面已经描述过这些挑战），或者直到整个系统得到修复。

分布式事务

在需要跨操作交易完整性的情况下，微服务可能会非常痛苦。分布式状态很难处理，很多小的单位可能会很难进行编排交易。

试图通过使操作幂等性，提供重试机制等来避免这个问题可能听起来很诱人，而且在很多情况下确实可能起作用。但可能有一些场景，你只需要一个事务失败或成功，而不想它处于中间状态。解决这个问题或者在微服务模型中实现它的代价可能是非常高的。

微服务依然可能是单体架构

显然，单独的服务和组件可能是孤立部署的，但是在大多数情况下，你将不得不运行某种编排平台，比如Kubernetes。如果你使用的是托管服务，例如Google的GKE 5或Amazon的EKS 6，则会为你处理管理群集的大量复杂性。

但是，如果你要自己管理集群，那么你正在管理一个庞大而复杂的关键任务系统。尽管单个服务可能具有前面所述的所有优点，但你需要非常小心地管理群集。这个系统的部署可能很难，更新可能很难，故障转移可能也很困难等等。

在许多情况下，总体收益仍然存在，但重要的是不要轻视或低估管理另一个庞大而复杂系统的额外复杂性。托管服务可能会有所帮助，但在很多情况下，这些服务都是新兴的不稳定的（例如，Amazon EKS直到在2017年底才宣布）——谁用谁知道。

微服务的疯狂消亡史！

只有通过仔细考虑才能避免为微服务而微服务的疯狂。为了帮助解决这个问题，我想了一些你可能想问自己的问题，以及可能的答案：

你可以从这里下载到一份PDF的副本：microservice-questions.pdf

最后的想法:不要把微服务和架构混为一谈。

我故意避免这篇文章中的“a”字。但是，我的朋友Zoltan在校对这篇文章的时候提到了一个很好的观点。

没有微服务体系结构。微服务只是组件的另一种模式或实现，无他。无论是否存在于系统中，都不意味着系统的体系结构得到了解决。

微服务在许多方面与打包和运维的技术过程有关，而不是系统的固有设计。组件的适当边界仍然是工程系统中最重要的挑战之一。

无论你的服务是否在Docker容器中，你总是需要仔细考虑如何将系统放在一起。没有唯一的答案，只有更多的选择。

我希望你看完这篇文章觉得有趣！一如既往，如果你有任何疑问或想法，请在下面评论即可。

2018 微服务的疯狂消亡史相关推荐

微服务写的最全的一篇文章
今年有人提出了2018年微服务将疯狂至死,可见微服务的争论从未停止过.在这我将自己对微服务的理解整理了一下,希望对大家有所帮助. 1.什么是微服务 1)一组小的服务(大小没有特别的标准,只要同一团队的 ...
spring cloud(2)---微服务写的最全的一篇文章
微服务写的最全的一篇文章今年有人提出了2018年微服务将疯狂至死,可见微服务的争论从未停止过.在这我将自己对微服务的理解整理了一下,希望对大家有所帮助. 什么是微服务 1)一组小的服务(大小没有特别 ...
请不要在“微服务”的狂热中迷失自我！
2017年是"微服务"疯狂的一年,如同股灾前的狂欢,各种不同行业的技术团队都在宣讲着自己微服务实践的道路.然而大家是否有反思过自己真的在玩"微服务"吗?您真的在 ...
近两年火热的微服务springboot不同配置文件详细讲解
点击上方"好好学java",选择"置顶公众号" 优秀学习资源.干货第一时间送达! 精彩内容 java实战练习项目教程 2018微服务资源springboot.s ...
2018 疯狂微服务之死
戳蓝字"CSDN云计算"关注我们哦! 近期微服务的话题非常火爆,有时可谓非常"疯狂": Netflix 在 devops 上做得很棒,同时 Netfix 也采用 ...
下一代微服务！ServiceMesh的2018年度总结 | 万字雄文
1 前言在 2017 年年底,在 Service Mesh 刚刚兴起之时,应 InfoQ 的邀请撰写过一篇名为 "Service Mesh 年度总结:群雄逐鹿烽烟起" 的文章,对 ...
Netflix如何在上万台机器中管理微服务？（史上最全）
疯狂创客圈为小伙伴奉上以下珍贵的学习资源: 疯狂创客圈经典图书 : 极致经典 < Java 高并发三部曲 > 面试必备 + 大厂必备 + 涨薪必备疯狂创客圈经典图书 : <N ...
下一代微服务！Service Mesh 2018年度总结
作者团:敖小剑.崔秀龙.单家骏.宋净超.田晓亮.徐蓓.张超盟 \n 前言 \n 在2017年年底,在Service Mesh刚刚兴起之时,应InfoQ的邀请撰写过一篇名为 "Service ...
QCon北京2018关键词：Kubernetes、Service Mesh、Istio和微服务
Kubernetes已然是容器编排系统的事实标准,像京东这样的大厂也从OpenStack切换到了Kubernetes.也有不少公司围绕Kubernetes搭建自己的私有云等基础设施,运维体系也随之产生 ...

2018 微服务的疯狂消亡史