阅读“微服务架构”一词可能会让您直观地了解该术语的含义：计算架构中的小型服务。这个定义并不完全错误，但也不完全正确。 

微服务架构通常被称为“打破整体”的一种方式。遗憾的是，这与《2001：太空漫游》无关，而是将单个大型程序分解（或分解）的概念。

最新的 DZone 参考卡

NoSQL 迁移要点

您可能还喜欢：什么是微服务？微服务架构简介

因此，微服务架构就是从整体上创建小程序（微服务）。结果有时仍然需要像单个实体一样运行，而有时它需要具有许多较小程序的属性。

一个很好的比喻可能是您家中的 HVAC（供暖、通风和空调）系统。该系统可能由熔炉、空调、加湿器、恒温器和新鲜空气交换器组成。至关重要的是，您永远不会直接走到加湿器或炉子旁并按下开关将其打开。相反，您调整恒温器，然后恒温器控制所有组件系统 - 您不需要了解有关各个部件的任何信息。每个单独的系统都装在制造商提供的盒子中，但全部连接在一起作为一个单元。您可以将煤气炉更换为电动型号，最终用户的操作保持不变。

在这个比喻中，每个 HVAC 组件都是一个服务，而 HVAC 系统的整个设计就是微服务架构。

当然，微服务架构比 HVAC 系统更加动态和复杂。云实例有时会上下波动，有时每天会多次部署新版本。微服务架构可能有数千（甚至数百万！）输入并执行许多极其复杂的活动，这些活动构成了应用程序的全部功能

微服务的优点
当然，包含如此多的服务会带来复杂性，这通常被认为是优秀软件的主要敌人。但另一种选择更糟糕。 

在整体架构中，所有内容都包含在一个大单元中。在一个整体中，当某些东西发生故障时，即使是最好的软件也不可避免地会发生这种情况，一切都会崩溃。即使是精益的软件项目，随着时间的推移，也会变得越来越复杂——添加越来越多的功能和解决方法，直到最终变成一个笨重的怪物。更新和发布变得越来越缓慢和痛苦。当某些东西出现故障时（即使是最好的软件也不可避免地会发生这种情况），一切都会崩溃。

在微服务架构中，单个服务只承担最少的职责。如果单个服务出现问题，重写该单个服务比重写并合并修复整个整体要容易得多。 

另外，同样重要的是，当您尝试扩展单体应用时，往往会出现问题。整体架构的一部分可能特别需要大量资源，但您通常无法扩展整体架构的单个部分 - 您必须创建整个系统的副本，这会浪费资源。在极端情况下，单体架构并不是为了复制而构建的，从而对规模造成了硬性限制。

服务更容易构建和管理。微服务架构隔离了复杂性，允许更小、更敏捷的团队创建服务。您可能听说过两个比萨饼团队的效率，或者小到只需几个比萨饼馅饼的团队的效率。微服务架构适合由大量两块披萨团队构建。

最后，微服务架构更加灵活。单个服务可以利用各种平台、语言和工具，因为这些选择一次只影响一小群团队。只要输入和输出不受影响，这些团队中的开发人员就可以快速行动而不会破坏事物。

在哪里使用微服务架构
虽然使用微服务架构可以在许多情况下带来巨大的好处，但它并不适合所有情况。微服务架构往往在以下环境中表现最佳： 

庞大的 代码库。 较小的代码库可能会因分割为逻辑服务而获得较少的好处。
有足够的开发人员来创建致力于个人服务的团队。 如果整个团队一次只处理一项服务，微服务架构的许多优势就会丧失。
能够支持架构中许多服务的运营团队。 尽管微服务架构具有长期的运营优势，但一开始运行许多服务器或实例似乎比运行单个大型服务器或实例要多得多。
明确定义的底层业务流程。 具有业务知识的人应该能够查看架构图并看到映射。另一方面，如果业务流程是临时的或描述不清晰，这种混乱就会反映在架构中。