Kubernetes——Kubernetes 的单体架构

有一种使用微服务架构开发软件应用程序的新方法。那时，围绕容器和容器编排的所有讨论都在增加，但我们甚至在我们大多数人出生之前就已经在开发和使用这些大型软件应用程序。因此，在本文中，我们将讨论我们甚至在微服务之前使用的旧软件架构是什么，以及它的缺点是什么导致我们将注意力转移到微服务上。

因此，谈到本文的主要目标，我们将讨论四件主要的事情：

什么是单片机？
什么是单体架构？
单体架构的优缺点。
单体架构的挑战。

什么是单体？

单体一般是一个单一的大块，不可分割，不灵活，并且可以移动。因此，这从高层次上简要解释了单体架构的统一性及其特征。

IT 中的单体应用程序是基于单体架构构建的应用程序。它是自包含的，这意味着它包含打包和部署在一起的应用程序的所有部分。因此，为了简化这一点，您可以将其想象成一个大容器，其中应用程序的所有软件组件都组装在一起，紧密打包并部署为一个单元。想象一下，你在Java平台上开发了一个应用程序，然后你可以将它们相应地打包成各种格式，例如.jar ，然后最终作为一个单元部署到应用程序服务器上。

什么是单体架构？

因此，在业务术语中，您可以说所有不同的业务服务作为一个紧密耦合的单元打包在一起，因此通常当您查看单体架构时，它主要由三层组成。

高级单体架构：

表示层：在较高层次上，表示层是三层架构的前端层。它主要是 Web 应用程序的用户界面。该层通常使用 HTML、Javascript、CSS 等 Web 技术或通过其他流行的 Web 开发框架构建，并且该层使用 API 调用与底部的其他两层进行通信。
应用层：这是您拥有所有业务逻辑的地方。它通常用Java、Dotnet、C、 Python、C++ 或一些更相关的语言编写。
数据层：这是存储所有数据的地方，并且在 API 调用时由应用程序层访问这些数据。该层由 MySQL、Oracle DB、Microsoft SQL Server、MongoDB 等数据库技术组成

这是对单体架构及其层级的高级概述。因此，所有这些层都作为一个单独的单元打包和部署在一起，这就是它被称为单体架构的主要原因之一。

现在让我们看一个简单的单体应用程序的示例。当您使用书店网络应用程序时，它主要由四个组件组成，它们是：

客户帐户
付款
存货
船运

因此，如果开发人员基于单一的 ID 图片开发此应用程序，那么所有这四个组件将一起开发，它们可能相互依赖，并作为一个单独的单元部署到 Web 服务器上。

单体架构的优缺点

使用这种开发应用程序的架构风格，有一些优点也有缺点，现在是时候看看单体架构的一些优点和缺点了。

单体架构的优点：

单一部署单元：由于它是单一部署单元，因此整体上只有一个应用程序需要测试和部署。因此，单体应用程序易于开发和部署。
IDE 支持：近两到三年来，我们一直在开发单片应用程序。它成熟且陈旧，因此 IDE 和其他开发工具的设计与整体架构同步。

单体架构的缺点：

大型应用程序：使用单体设计构建的应用程序通常非常大。如果应用程序很小，那么就没有问题。然后它将很容易开发和维护。如果应用程序很大并且有多个组件，那么开发人员可能会在业务需求、组件及其代码之间迷失方向。并且很可能没有一个开发人员甚至一组开发人员可以了解整个应用程序，特别是对于那些最近加入团队的开发人员来说，了解一个应用程序需要大量时间
技术依赖性：这些单体应用程序将被锁定在围绕他们开发此应用程序的技术的初始决策中。即使有更好的技术、语言和工具在一段时间内出现以解决业务问题，但不幸的是这些单体应用程序应用程序将不得不坚持其最初的技术和最初做出的决定。
单栈开发：在开发软件应用程序时，这里没有一刀切的原则，这意味着让我们假设应用程序内部有多个组件，并且可能存在您认为一种技术最适合一个组件的情况并且不适合其他组件。但是，这种单片设计将限制您使用单个开发堆栈。
不切实际的频繁部署：频繁部署是不切实际的，因为在一个单一的应用程序中将各种应用程序组件链接在一起，因此它需要许多开发人员甚至负责这些组件的部门的协调。安排部署和测试新功能和错误修复可能需要数小时甚至数天。
难以扩展：单体应用程序的扩展通常非常具有挑战性，因为它被部署为应用程序的单个单元，而不是单个组件，因此必须扩展整个应用程序。

单体应用的挑战

现在，单体架构面临着一个巨大的挑战，尽管它已经运行了 30 多年。大型组织几十年来一直使用这种打包和部署应用程序的方式，并开发出有效的方法来解决这些缺点，但这是在互联网带来新挑战之前，挑战之一是 用户对应用程序需求的不可预测性。

想象一下，您的公司内部有一个内部 Web 应用程序，每天有大约 10,000 名公司员工使用它。因此，您确切地知道您的公司有多少员工，他们在什么时候工作以及工作了多长时间。因此，基于这些标准，您可以为这些应用程序提供足够的资源以使其发挥最佳性能。因此，如果有更多员工加入公司，您会提前知道这一点，并且可以向运行此应用程序的服务器添加更多资源，以尽可能保持最佳性能。

现在让我们假设您的公司有一个外部网站，他们在其中在线销售产品，如amazon.com或walmart.com。在这种情况下，您不知道今天将有多少人使用您的网站。您所能做的只是根据您拥有但不能确定的一些历史数据做出良好的估计。因此，如果您查看假期期间的销售额，您会发现由于一些营销活动或社交媒体的嗡嗡声，访客人数迅速增加。因此，一旦您看到流量激增，您就需要立即扩展应用程序资源。不幸的是，您没有几周的通知时间，所以如果您只是未能提供这些资源，它显然会降低您的应用程序的性能，甚至可能导致它们崩溃。

这曾经发生在 Internet 的早期，当 Web 应用程序是单一的并且当它们具有一定的访问者数量时，它会减慢应用程序并可能完全停止它们。这里的主要问题是不能足够快地提供资源来满足需求。因此，单体架构模式的主要缺点是它不能很好地根据需要动态扩展资源。