整体应用程序的局限性以及适应微服务架构的需求

如果掌握了任何较早的软件体系结构，就会发现它们始终以Monolithic方式构建。

1.那么，这种单片式架构到底是什么呢？

根据维基百科，整体定义如下：

在软件工程中 ，单片应用程序描述了单层软件应用程序 ，其中用户界面和数据访问代码从单个平台组合到单个程序中。 整体应用程序是独立的，并且独立于其他计算应用程序。

用外行术语来说，可以说这就像一个大容器，其中将应用程序的所有软件组件组装在一起并紧密包装。如果您使用Java编程语言的特定情况，则此软件包可以采用各种格式，例如EAR，WAR ，JAR等，最终将其作为单个单元部署在应用程序服务器上。 用业务术语来说，您可以说所有不同的业务服务都作为一个单元（紧密耦合）打包在一起。 因此，既然我们已经介绍了Monolithic Application的定义，那么让我们更深入地了解带有示例用例的Monolithic体系结构。

让我们以购物车应用程序的经典用例为例。

• 请参见下图，以更好地了解此单片应用程序

整体架构

如果您在上面看到，该应用程序具有以下紧密耦合的业务服务

1. 客户服务
2. 产品服务
3. 购物车服务

2. Monolithic体系结构是否解决了一些使应用程序黯然失色的经典问题？

2.1敏捷性

如果您现在看到的是，业务用例非常敏捷，那么业务流程就在不断发展。 例如，在银行业应用中，新法规不断出台。 我们的Monolithic应用程序肯定可以适应这种变化，但是以降低敏捷性为代价，因为即使必须更改应用程序中的一个小组件，整个应用程序也需要重新包装并组装在一起。因此，在这里可以肯定地说，应用程序降低了敏捷性因为重建整个应用程序需要花费大量的时间，而且还降低了交付新应用程序功能的速度。

所以我们现在可以说它在敏捷性方面输了

2.2可扩展性

让我们考虑一下，我们的购物车应用程序获得了很多客户的青睐，并且当我们的应用程序无法再处理新客户时，就产生了需求，因此我们需要在垂直和水平方向上扩展应用程序。

让我们在下面的图表中更好地理解它。

规模化整体架构

如果您看到了，仅仅是为了容纳更多的客户，我们就牢记客户服务创建了同一应用程序的三个实例，但是由于其他服务不需要扩展，因此浪费了其他服务中使用的资源。

因此，在可伸缩性方面也肯定会失败。

2.3开发运营周期

如果您将持续交付付诸实践，那么它在这方面将惨遭失败，因为即使对应用程序进行很小的更改，构建时间也会大大增加，并且肯定会降低部署频率。 因此，从Dev Ops周期的角度来看，这也是一个很大的问题。

单体应用程序惨遭失败的参数还有很多，例如“ 可用性”，“容错”和“弹性 ”。

3.现在让我们看一下整体架构的一些优势。

3.1单一部署单位

由于整个应用程序打包为一个单元，因此部署过程相对容易。

3.2一站式代码库

整个应用程序的源代码位于一个位置，并且通过使用一些IDE在代码库中导航非常容易。

3.3集成开发环境支持

由于Monolithic体系结构已经存在了很长时间，因此所有IDE的构建基本上都牢记Monolithic体系结构，这意味着如果您以Java应用程序为例，则可以从IDE直接创建部署单元，例如WAR，JAR或EAR文件本身。

3.4多数

由于Monolithic体系结构已经存在很长时间了，因此它们在软件应用程序空间中占多数。 即使实施单片式架构有一些优点，采用它的缺点也绝对大于其所有优点。

4.单片架构的局限性导致了微服务。

微服务是一种体系结构范例，其中，单片应用程序被分解为小的微型微应用程序（这就是为什么在微服务中使用术语“ 微” ）。 一段时间以前，我们所有人都在不知不觉中使用Micro服务。 想象一下一个案例，其中为了在我们的应用程序中支持位置跟踪功能 ，我们使用了Google Maps Geo Location API。 此地理位置服务本身就是微服务。

现在，让我们以上面的购物车单片应用程序为例，尝试将其分解为微服务。 现在，它的所有三个服务“客户服务”，“产品服务”和“购物车服务”将作为微服务加入，此外，我们还创建了一个面向外界的单独的UI Micro服务。

请参阅下图，以更好地了解微服务

微服务架构

因此，从上图可以看出，我们现在已经将单个Monolithic Application分解为四个独立的Micro Services。 现在我们将尝试评估这种架构范例是否解决了整体架构的所有局限性？

4.1可扩展性

单个组件可以根据需要进行扩展，现在无需将所有组件一起扩展，因此我们可以肯定地说，它在可伸缩性方面胜出

规模化微服务架构

从上图可以看到，只有客户微服务已扩展，因为需要容纳更多的客户，使其他微服务保持完整，从而节省了大量资源。

4.2敏捷性

范围更改可以在一个微服务中非常快速地完成，从而减少了部署时间，其他微服务也不受这些更改的影响，因为它们彼此独立，因此在敏捷性方面也有优势。

4.3开发运营周期

如果您看到，由于每个组件都是独立运行的，因此连续交付周期肯定会大大减少，部署时间也会大大减少，因此缩短了Dev Ops周期，因此从持续交付周期的角度来看，这也是一个胜利。

因此，现在我们已经看到微服务架构解决了单片架构的所有局限性，让我们详细了解采用微服务架构的所有优势。

5.微服务架构的优势

5.1可扩展性

每个微服务可以独立扩展，而不会影响其他微服务。 因此，与单片应用程序相比，它无疑具有优势，在单片应用程序中，浪费了大量资源来扩展不需要的服务，因为它们全部打包在一起成为一个可部署的单元。

5.2可用性

即使一项服务发生故障，其他微服务也是高度可用的，并且故障发生的微服务可以在非常短的停机时间内非常Swift地得到纠正。 因此，相对于整体应用必须降低的整体应用，它无疑具有优势。

5.3容错

即使一个微服务在说数据库连接池已用尽方面存在一些故障。 因此，对于任何故障都有一个非常清晰的界限，并且不同于单片方式，其他服务也可以平稳运行，因此仅影响应用程序的一小部分，而不会影响整个应用程序。

5.4敏捷性

如上所述，特定微服务的更改可以非常快速地完成，并且可以非常快速地部署，这使其成为非常适合不断变化的业务需求（即高度敏捷的环境）的体系结构。

5.5多语种持久性

每个微服务都可以根据用例需求选择自己的数据库类型。 因此，通常，应用程序堆栈不绑定到特定数据库。

5.6可维护性

为每个业务服务创建一个单独的微服务。 因此，微服务中的业务代码非常容易理解，因为它可以满足一个业务功能。而且，由于微服务可以满足单个业务功能，因此代码量也大大减少了，因此具有很高的可维护性。

5.7与软件堆栈无关

由于将较大的应用程序分解为n个较小的微服务，因此应用程序不绑定到单个软件堆栈，因此不同的软件堆栈可用于不同的微服务。

5.8更快的发展

与单片应用程序不同，微服务中的代码更改可以随着业务需求的更改而快速完成，从而缩短了开发周期。

5.9更快的部署

由于微服务可满足单个业务功能，因此代码量大大减少，从而为更快的部署铺平了道路。

5.10明确分离业务问题

每个微服务都迎合了独特的业务功能，因此每个微服务之间都存在非常明确的业务关注点分离，因此可以以非常健壮的方式构建每个微服务。

六，结论

在本文中，我们看到了Monolithic应用程序的局限性以及采用微服务架构的需求。 在微服务系列的第2部分中，我们将看到如何使用Spring Boot构造微服务应用程序。

翻译自: https://www.javacodegeeks.com/2016/05/limitations-monolithic-application-need-adapting-micro-services-architecture.html