微服务简介

更小，更快，更强：从头开始构建更好的云应用程序

在整个2014年和2015年，微服务成为热门的新流行词，迅速取代了云计算。本教程将向您介绍微服务的历史以及构建微服务架构的意义。

Netflix流媒体：普及微服务的诞生

无论你是否听说过微服务，我相信你已经听说过Netflix了。感谢Netflix在创建和发布用于管理云基础架构的软件方面的成功，我甚至愿意打赌您已经听说过Netflix开源软件（NOSS） - 这是为Netflix数字娱乐流媒体帝国提供动力的软件。

从2009年左右开始 - 完全由API驱动，并将我们作为微服务所知的最初浪潮 -  Netflix完全重新定义其应用程序开发和运营模型。当时，该公司受到行业旁观者的嘲笑：“你们疯了！”或“这可能适用于Netflix，但其他任何人都无法做到这一点。”快进到2013年，当时大部分情绪都变为“我们正在使用微服务。”超过525,000个微服务的谷歌搜索结果表明，这个概念肯定既有效又强大。

但什么是微服务？什么是基于微服务的架构？图1显示了旅行预订服务的微服务的概念视图。图中七个瓦片中的每一个代表一个单独的微服务。它们被安排来显示哪些微服务可以与其他微服务交互，为内部和外部应用程序提供必要的功能。服务的不同垂直高度表示它们如何以不同的量相互使用。在本文中，我将介绍微服务的基础，以便您了解如何表示自己的基于微服务的体系结构。

图1.概念化的微服务

有关微服务开始的深入解释，请阅读Martin Fowler的优秀博客文章。我将在这里尝试捕获的是该帖子的精髓，它在当今环境中的应用，以及如何到达那里。

在一次会议上，前Netflix的Adrian Cockcroft将微服务定义为“细粒度的SOA（面向服务的架构）”。您不需要非常熟悉SOA（十多年前创造的架构风格），只需要在首字母缩略词中使用的术语。理想情况下，从第一天开始就构建整个服务架构。在微服务中，这些服务中的每一项都有一个单独的目的，没有副作用，使您能够以更少的整体专用工程师覆盖更大的规模。

为了定义微服务和相关的架构，我正在调整和修改用于描述现代运动员的“更大，更快，更强”的短语：更小，更快，更强（见图2）。从本质上讲，微服务是许多较小的架构组件，无论是独立还是整体，都可以快速构建和交付。

图2.微服务：更小，更快，更强

较小

微服务意味着不再是巨石。 Monolith很大，很笨重，速度慢，效率低，就像图3中的Grim Monolith一样。我们正在从一个拥有2GB WAR文件的世界（是的，只是WAR文件 - 而不是应用程序服务器或操作系统组件）转向世界 由许多500MB的服务组成，包含整个应用程序，服务器和必要的操作系统组件。

图3.一个严峻的巨石

从大型机到客户端/服务器架构的迁移是一个很大的步骤，也是许多公司和开发人员都在努力解决的问题。 从基于Web的核心应用程序服务器到SOA采用的最新迁移也是类似的问题。 过去几年应用服务器中包含的许多组件都适用于微服务; 但是，它们仍然包含在多GB的安装二进制文件中。 例如，图4显示了使用WebSphere®ApplicationServer和Java™Enterprise Edition组件部署的传统Web应用程序体系结构的体系结构。

图4.标准WebSphere Application Server应用程序体系结构

微服务是与所有交互组件集成的一种练习，它更松散地耦合。 微服务的整个想法变得即插即用。 我将在Stronger部分更多地讨论这个问题，但基本上一个基于微服务的系统大规模采用了霰弹枪方法，以维护和保护更多的小组件而不是更少的大组件。 您可以删除单点故障并在任何地方分发这些故障点。

失败的建筑只能用较小的碎片来完成。 如果你为失败建立一个巨石，你会花太多时间专注于每个边缘情况的低效率。 如果构建单个服务实例以进行故障，则其他服务实例将在消费者发出请求时接管。

图5中的图表是使用微服务的实现的一个示例。

图5.视频流应用程序的概念路由示例

在图5中，每个单独的盒子都是独立维护的，可以自行调整，知道它所在的位置，并知道从何处获取所需的信息。并非每个微服务架构都需要此图中的每个组件，但它们确实有帮助！

比较图4和图5，您可以看到类似应用程序的部署方式的差异。在图4中，所有内容都部署到垂直扩展系统上的单个进程。当需要更多吞吐量时，整个服务器堆栈会一次又一次地被标记出来。每个服务器都在自己的进程内运行。在图4的Web服务引擎或EJB容器中获得更多吞吐量的唯一方法是将整个服务器JVM扩展到集群环境中的新实例。但是，这也会创建另一个Web容器，另一个嵌入式HTTP服务器，另一个消息传递引擎等，无论这些组件是否需要扩展。

与图4的刻度类型相比，图5具有可独立缩放的组件。我将介绍各个组件以及它们如何在Faster部分中扩展，但现在关注每个组件和服务的分布式特性。与图4中的示例应用程序（需要完全高度可用的Web应用程序服务器堆栈以提供可用性）不同，这些组件本质上是分布式的，只提供单一的，集中的功能，通常使用与其他组件不同的技术。此结构使应用程序体系结构能够更快地发展，并包含更新的技术以及更新的版本，而与其他组件无关。

总而言之，较小的开发，操作，维护和交互更好。

快点

与云一起出现的另一个流行语是DevOps。 DevOps运动使开发人员能够在交付管道中控制更多代码，不断集成并实现更高的可见性。 DevOps的主要原理，如图6中顺时针顺序所示，是观察，定位，决定和行动。

图6. DevOps的原理

有什么比更快地交付小件更好，对吧？您无法每两周向单个应用程序服务器实例提供更新，但在同一时间范围内，您绝对可以为许多其他服务所使用的单个服务提供更新。当您构建新的临时环境，通过管道移动项目以及交付到生产环境时，较小的组件会产生较少的开销。

别误会我的意思。仍然可以使用整体进行持续交付和集成。我已经看到它发生了。然而，那时你是杂耍的巨石，而不是大理石。从掉落大理石中恢复比从掉落大石更容易恢复。

与DevOps相关的开发周期非常适合微服务。您的目标是缩短开发周期，不断增加功能，而不是更长的开发周期，从而立即构建完整的整体愿景。这种称为敏捷的开发方法是DevOps成功的基本实践。无论您选择迭代还是增量开发，微服务，DevOps文化和敏捷规划的组合使您能够在过去几年中计划第一个瀑布周期时快速构建整个基础架构。

更快的另一方面涉及执行。微服务建立在这样一种观念之上：如果你需要更快，只需要投入更多的资源。经理的梦想！通过构建可独立扩展的每个服务，您可以允许组件之间的交互，以利用资源池而不是单个组件接口。

回到上一个示例，在图5中，您可以看到Service Registry服务器和客户端。此功能在基于微服务的应用程序中至关重要。在此示例中，边缘服务包含Movie Service和Review Service引用。基于负载，这些服务以不同的速率扩展;因此，你不能再以相同的规模管理它们。

随着Movie Services规模的扩大，Service Registry会自动了解创建的新服务实例。当边缘服务尝试处理请求时，它会调用Service Registry并获取它所依赖的所有服务的客户端引用。 Movie Service客户端引用更可能是最近创建的新引用，而以前使用的旧服务实例可以返回。此Service Registry功能允许您的微服务真正充当“众多之一”，在组件之间具有松散耦合的依赖性，但是在需要时获得更多组件副本的高度可靠性。

图7显示了图5中视频流应用程序的相同概念架构，并为Movie Service添加了扩展的微服务。

图7.视频流应用程序的概念性缩放示例

使用能够自我感知新实例的系统，根据需要进行有效扩展。不，这不是天网。这就是使基于微服务架构的应用程序更强大的原因。

更强

并非所有系统都是长寿的。它们在需要时创建，并在不再用于某个目的时被删除。正如我之前提到的，这通过在整个系统中分发这些点来消除单点故障，因为您知道需要机制来考虑不可用或性能不佳的服务和实例。

牛，不是宠物

使用微服务，部署系统的概念变成了牛，而不是宠物：

• Pets are given names; cattle are given numbers.
• Pets are unique; cattle are often identical.
• Pets are nursed back to health; cattle are simply replaced when ill.

 - 从Gavin McCance的CERN数据中心Evolution演示文稿中获取。

这个概念导致创建许多服务，以及许多服务中的一个。我们不再一方面计算服务实例或管理长期实例，而是担心维护状态，存储，系统修改等。不要误解我的意思 - 我们仍然对性能调优和配置非常感兴趣，但现在这些事情在开发周期中更早发生，而不是在分段或生产中。这种方法为我们提供了许多服务，以及每项服务的许多实例。

为了验证这一力量支柱，在其旅程中，Netflix开始利用混乱 - 确切地说是混沌之猴（见图8）。混沌猴是一个云应用程序组件，Netflix用它来引入应用程序操作的系统混乱。

图8.混沌之猴

此功能将通过基础结构并有目的地关闭对生产至关重要的服务和服务实例。为什么Netflix会这样做？它怎么能这样做并存活下来？

首先，为什么。这是一种让您轻松识别快速失败所需的方法。新服务太慢了吗？他们需要更有效地扩展吗？当外部服务提供商关闭时，而不仅仅是内部服务会发生什么？所有这些都需要在微服务架构中加以考虑。

第二，如何。由于我之前提到的霰弹枪方法，Netflix可以生存。这个想法很简单：提供足够的服务实例，99.9999％的请求将成功完成。任何失败的请求都将在重试时起作用。拔下服务实例上的插件，另一个本地插件将取代它。拔下整个服务上的插头，您的系统应该将用户补偿或重新路由到具有该特定服务的其他可用区或区域。如果没有别的可用，用户或请求应该快速失败，而不是等待超时。

Netflix扩展了Chaos Monkey的概念并发布了作为Simian Army的功能（见图9），包括Chaos Monkeys，Janitor Monkeys，Conformity Monkeys和Latency Monkeys--云应用程序组件，它们将特定的混乱引入操作，包括延迟和合规性问题。

图9.猿人军队

正如您所看到的，Netflix（以及其他采用微服务的公司）认为杀死您的应用程序的想法使其变得更强大。

结论

我提到的微服务的主要好处是：

• 它们的小尺寸使开发人员的工作效率最高。
• 很容易理解和测试每项服务。
• 您可以正确处理任何相关服务的故障。
• 它们减少了相关故障的影响。

致谢和图片学分

我要感谢Jonathan Bond的演讲，这让我能够捕捉和定位我的想法并借用一些图像（图1,5,6和7）。