请不要在“微服务”的狂热中迷失自我！

王杰
架构运维
DD的博客全面升级，阅读体验更佳（尤其是系列教程），后续不再通过这里发布新文章，而是改到 www.didispace.com 发布啦，奔走相告！点击直达～

2017年是“微服务”疯狂的一年，如同股灾前的狂欢，各种不同行业的技术团队都在宣讲着自己微服务实践的道路。然而大家是否有反思过自己真的在玩“微服务”吗？您真的在“微服务”中受益了吗？还是为了凑这波的热点，而被折腾的疲惫不堪？

下面的内容是《The Death of Microservice Madness in 2018》一文的翻译，本文很好地阐述了“微服务”在带来诸多优势的同时也对技术团队增加的复杂度所带来的挑战。各个技术团队Leader们，是时候好好思考一下，在这一波的疯狂中，您的团队是否都做到位了？还是又充当了一回“时髦架构师”？

——程序猿DD

微服务在过去几年一直是一个非常热门的话题（附录1）。何为“微服务的疯狂”，举个例子：

众所周知，Netflix在DevOps上的表现非常棒。Netfix可以做微服务。因此：如果我做微服务，我也将非常擅长DevOps。

很多情况下，我们盲目的投入巨大的努力来接入微服务模式，然而往往却很少去考虑接入的成本和收益能否有效的帮我们解决当前我们正面临的痛点。

下面，我将详细描述微服务是什么，以及为什么这种模式这么吸引人，最后再聊一聊一些微服务正面临的一些关键挑战。

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

image

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

来来来，老司机带你从基础走一波。一个例子：下面这张图是一个假想的视频共享平台的实现方式，左侧是用一个“整体服务”来实现，右侧是多个微服务的形式来实现：

Monolith与微服务视频共享平台的比较

两种系统设计的区别在于左侧是一个整体的大而全的服务。右侧是一组小而多，但每个都是一个具体的服务，每个服务都有特定的角色。

当从系统细节层面来绘制图表时，很容易看出微服务的很多潜在的好处，简单从几个方面来说一下：

独立开发：小型独立组件可由小型独立团队构建。一个小组可以改变“Upload”服务，而不会干扰“Transcode”服务，甚至都不需要知道这个服务。了解组件的时间大大减少，开发新功能也更容易。

独立部署：每个单独的组件都可以独立部署。这样可以以更快的速度和更少的风险发布新功能。比如：“Streaming”组件的修复或功能可以部署，而不需要部署其他组件。

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

可重用性：组件实现一个小的，特定的功能。这意味着它们可以更容易地适用于其他系统、服务或产品。“Transcode”组件可以被其他业务部门使用，甚至可以变成一个新的业务，或者为其他组提供Transcode服务。

从细节层面上来看，微服务模型较之于整体模型的好处显而易见。但是问题来了，如果真的是这样的话 - 为什么微服务模式最近几年才流行？我一生都快走完了（尴尬，貌似暴露年龄了），它才出现？

如果这微服务这么好，为什么之前大家没有这样做呢？

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

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

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

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

微服务有什么问题呢？

微服务如此强大、完美，哪里还会有什么挑战？这是目前我见过的最大的问题。

开发的复杂性增加

对于开发者来说事情会变得更加困难。在开发人员想要在远程工作的情况下，或者可能跨越许多服务的功能的情况下，开发人员必须在他们的机器上运行它们，或者连接到它们。这通常比简单地运行单个程序更复杂。

这个挑战可以通过工具（附录3）得到部分缓解，但随着构成系统的服务数量的增加，开发人员在整个系统运行时面临的挑战也会越来越多。

运维的复杂性增加

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

DevOps的复杂性增加

阅读以上两点，可能会发现运维和开发是分开处理的，尤其是考虑到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容器中，你总是需要仔细考虑如何将系统放在一起。没有唯一的答案，只有更多的选择。

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

附录：进一步阅读

以下链接可能有用：

如果你愿意，请分享你认为值得阅读或观看的话题的任何东东！

参考

  1. https://trends.google.com/tren … rvice
  2. 如果你不想错过这篇文章，你可以订阅RSS源，或者在LinkedIn或Twitter上关注我。
  3. Docker Compose是一个很好的解决方案，Fuge非常聪明，在MiniKube这种情况下，也可以选择在本地运行编排。
  4. https://semver.org/
  5. 谷歌Kubernetes引擎，一个从谷歌云平台诞生Kubernetes托管服务：https://cloud.google.com/kubernetes-engine/
  6. 亚马逊弹性容器服务（已支持Kubernetes），一个从亚马逊Web服务诞生的Kubernetes托管服务：https://aws.amazon.com/eks/

原文链接：The Death of Microservice Madness in 2018（翻译：王杰）

本文作者：王杰，
原文链接：http://dockone.io/article/3058
版权归作者所有，转载请注明作者、原文、译者等出处信息