为什么应该使用微服务（Microservices） ?

如今，微服务非常流行。几乎每个人都喜欢。不仅仅是Netflix、亚马逊或谷歌，似乎几乎每个人都采用了这种架构风格。虽然微服务已经存在了很长一段时间，也有很多关于它的文章，但我今天想再写一篇，所以请耐心听我说。

要理解对微服务的需求，我们需要理解典型的单体三层架构的问题。

整体式架构是什么?

整体式是指把所有的东西都组合在一起。整体应用程序是自包含的应用程序。必须有应用的所有组件，才能使代码工作。

以构建在三个部分中的典型的三层传统web应用程序为例：用户界面、数据库和服务器端应用程序。这个服务器端应用程序称为monolith，它进一步分为3层—表示层、业务层和数据层。整个代码在同一个代码库中维护。为了使代码工作，它被部署为单个整体单元。任何微小的更改都需要构建和部署整个应用程序。

什么是微服务架构?

微服务体系结构是一种体系结构风格，在这种体系结构风格中，整个应用程序被划分成松散耦合的、独立的、围绕业务领域建模的服务。微服务中的“微”是非常具有欺骗性的。人们对此争论不休，但在我看来，它并没有规定服务的大小。再一次，这是另一个我们应该有另一天的讨论。让我们前进。

重点是，每个独立的服务都有一个业务边界，可以独立开发、测试、部署、监视和扩展。它们甚至可以用不同的编程语言开发。

在基于微服务的体系结构中，每个组件或服务都有自己的数据库。没有集中式数据库，就像一个整体的情况一样。您甚至可以根据需要为每个微服务使用NoSQL、RDBMS或任何其他数据库。这使得微服务真正独立。

单体Monolith架构与微服务对比

扩展难易程度

这些应用程序只能通过在负载均衡器后面有多个完整应用程序实例来水平缩放。如果应用程序中的特定服务需要扩展，那么没有简单的选项。您需要完整地扩展应用程序，这是对资源的不必要浪费。

相反，基于微服务的应用程序允许您根据自己的需求独立地扩展单个服务。在上面的图中，如果服务B需要缩放，您可能有10个实例，而其他的保持原样。这可以根据需要随时更改。

部署方便程度

整个代码库被部署，而不仅仅是受影响的代码。对单个应用程序的任何部分/层所做的任何更改都需要构建和部署整个应用程序。单个开发人员还需要下载整个应用程序代码，而不只是下载他/她所影响的用于修复和测试的模块。这也会影响持续部署。

另一方面，在微服务体系结构中，如果只需要在100个微服务中的一个中进行更改，那么只需要构建和部署经过更改的微服务。不需要部署所有内容。事实上，如果需要，微服务甚至可以在一天中部署好几次。

越来越多的应用程序的复杂性

随着单体应用程序(特性、功能等)的增长，团队也会随之增长，很快，应用程序就变得复杂和交织在一起。随着不同的团队不断修改代码，维护模块化结构变得越来越困难，最终导致混乱的代码。这不仅会影响代码质量，还会影响整个组织。

在基于微服务的应用程序中，每个团队都在各自独立的微服务上工作，这使得制作交织在一起的代码变得不那么困难。

没有明确的所有权

在单体应用程序中，看起来独立的团队实际上并不独立。它们同时在同一个代码基上工作，但彼此之间严重依赖。

在基于微服务的应用程序中，独立的团队在独立的微服务上工作。一个团队将拥有一个完整的微服务。工作有明确的所有权，对服务的所有内容都有明确的控制，包括开发、部署和监视。

故障级联

如果不正确地设计，单个应用程序的某个部分的故障可能会级联并导致整个系统崩溃。

在基于微服务的架构中，我们可以使用断路器来避免这种故障。

开发和运维隔离

开发团队通常会进行开发、测试，一旦部署，就会将维护和支持的所有权交给运营团队。开发团队解散了，运维团队接管了所有权，并努力在生产中支持单块应用程序。

在基于微服务的应用程序中，团队是在“构建它，运行它”的理解下组织起来的。开发团队继续拥有产品中的应用程序。

在技术/语言

用一个整体，一个人被锁定在实现的技术/语言。如果需要进行技术/语言更改，则必须重写整个应用程序。

使用微服务，每个服务都可以根据需求和业务以不同的技术或语言实现。任何更改服务的技术/语言的决定只需要重写该特定服务，因为所有微服务彼此独立。

提供正确的工具/技术来支持微服务

几年前，还没有合适的工具和技术来支持微服务。自从Docker容器和云基础设施(尤其是PaaS)向大众开放以来，由于微服务无需经过传统的供应程序就能提供自由，因此被大量采用。

结论

我们已经详细讨论了单片架构和微服务架构风格。我们还讨论了单体应用程序的各种关键问题，以及微服务如何解决这些问题。简而言之，选择微服务体系结构有以下好处:

独立开发和部署服务

速度和敏捷性

更好的代码质量

围绕业务功能创建/组织代码

提高了生产率

容易扩展

在某种程度上，选择实现技术/语言的自由

即使有微服务体系结构提供的所有好处，它也不是一颗银弹。它有自己的复杂性。考虑一个大项目中数百个服务的多个实例。你将如何监控这些?在任何服务失败的情况下，如何跟踪、跟踪和调试错误?

所有这些开销都是高效应用程序需要解决的问题。