单体架构与微服务架构的区别

为了理解微服务，我们需要了解什么是单体应用程序，以及是什么要从单体应用程序转向微服务。

单体应用

如果一个项目的所有功能都存在于单个代码库中，则该应用程序称为单体应用程序。我们都必须在生活中设计过一个单一的应用程序，在这个应用程序中，我们得到了一个问题陈述，并被要求设计一个具有各种功能的系统。我们在表示、服务和持久性等各个层中设计应用程序，然后将该代码库部署为单个 jar/war 文件。这只不过是一个单体应用程序，其中“mono”表示包含所有必需功能的单个代码库。

但是，如果我们已经在使用单体应用程序，那么是什么导致我们要使用微服务呢？

单体应用的缺点：

• 随着时间的推移，单体应用变得太大，因此难以管理。
• 需要重新部署整个应用程序，即使是很小的更改。
• 随着应用程序大小的增加，它的启动和部署时间也会增加。
• 对于任何加入项目的新开发人员来说，即使他的职责与单个功能相关，也很难理解大型单体应用程序的逻辑。
• 即使应用程序的单个部分面临较大的负载/流量，也需要将整个应用程序的实例部署在多个服务器中。它效率非常低，并且不必要地占用了更多资源。因此，水平缩放在单片应用程序中是不可行的。
• 采用任何非常适合特定功能的新技术是非常困难的，因为它在时间和成本方面都会影响整个应用程序。
• 单体应用不是很可靠，因为任何模块中的单个错误都可能导致整个单体应用程序崩溃。

单体应用的优势：

• 相对于微服务而言，开发简单，需要熟练的开发人员来识别和开发服务。
• 由于只部署了一个 jar/war 文件，因此更易于部署。
• 与微服务架构相比，开发相对容易和简单。
• 与微服务架构相比，网络延迟和安全问题相对较少。
• 开发人员无需学习不同的应用程序，可以将注意力集中在一个应用程序上。

微服务

它是一种架构开发风格，其中应用程序由较小的服务组成，这些服务通过使用 HTTP 等轻量级协议直接相互通信来处理一小部分功能和数据。根据 Sam Newman 的说法，“微服务是协同工作的小型服务。”微服务架构对应用程序和数据库之间的关系有重大影响。每个微服务都有自己的数据库，而不是与其他微服务共享单个数据库。它通常会导致一些数据的重复，但是如果你想从这种架构中受益，每个微服务都有一个数据库是必不可少的，因为它可以确保松散耦合。每个微服务都有一个单独的数据库的另一个优点是每个微服务都可以使用最适合其需求的数据库类型。每个服务都提供了一个安全的模块边界，以便可以用不同的编程语言编写不同的服务。微服务架构涉及许多模式，如服务发现和注册、缓存、API 网关和通信、可观察性、安全性等。

微服务原理：
单一职责：这是定义为 SOLID 设计模式的一部分的原则之一。它指出单个单元，无论是类、方法还是微服务，都应该有一个且只有一个职责。每个微服务都必须有单一的职责并提供单一的功能。也可以这样说：应该开发的微服务数量等于你需要的功能数量。数据库也是去中心化的，通常每个微服务都有自己的数据库。
围绕业务能力构建：在当今世界，存在如此多的技术，总有一种技术最适合实现特定功能。但在单体应用中，这是一个主要缺点，因为我们不能为每个功能使用不同的技术，因此需要在特定领域做出妥协。微服务永远不会限制自己采用最适合解决业务目的的适当技术堆栈或后端数据库存储，即每个微服务可以根据业务需求使用不同的技术。
失败设计：微服务的设计必须考虑到失败案例。微服务必须利用这种架构的优势，并且关闭一个微服务不应影响整个系统，其他功能必须保持用户可以访问。但在 Monolithic 应用程序中并非如此，其中一个模块的故障会导致整个应用程序的崩溃。

面向服务的架构(SOA)与微服务架构：

Capgemini 的 MDM 史蒂夫琼斯曾经说过，“对于那些知道 SOA 是什么的人来说，微服务就是 SOA”。所以，了解 SOA 的人，大部分都认为它们是一样的，或者说区别不是很清楚。我们也不能责怪他们，如果我们谈论蛋糕和糕点，我们会发现相似之处多于不同之处。因此，让我们尝试了解两者之间的差异。
SOA 的演变是为了解决单体架构中的问题，并在 2000 年代初开始流行。在 SOA 中，大型应用程序被拆分为多个独立部署的较小服务。这些服务不直接相互通信。曾经有一个企业服务总线(ESB，一种中间件或服务器，借助使用不同协议或消息标准的服务，可以轻松地相互通信)，这些服务在其中暴露自己并通过它相互通信。此外，没有为每项服务建立独立数据库的指南。
微服务架构是 SOA 的演进。人们还认为 SOA 是微服务的超集。简单来说，微服务是一种细粒度的 SOA。在这里，微服务直接相互通信，没有像 SOA 中的 ESB 那样的通信中心依赖。此外，还有一个指导方针，即为每个微服务拥有一个单独的数据库。微服务从 SOA 演进的基本思想是减少服务之间的依赖，并使它们与上述准则松散耦合。

微服务的优势：

• 由于它相对较小，因此易于管理。
• 如果其中一个微服务有任何更新，那么我们只需要重新部署那个微服务。
• 微服务是自包含的，因此是独立部署的。它们的启动和部署时间相对较短。
• 对于新开发人员来说，加入项目非常容易，因为他只需要了解提供他将要处理的功能的特定微服务，而不是整个系统。
• 如果某个特定的微服务由于用户过度使用该功能而面临很大的负载，那么我们只需要扩展该微服务。因此，微服务架构支持水平扩展。
• 每个微服务可以根据业务需求使用不同的技术。
• 如果某个特定的微服务由于某些错误而出现故障，那么它不会影响其他微服务，整个系统保持不变并继续为用户提供其他功能。

微服务的缺点：

• 作为一个分布式系统，它比单体应用程序复杂得多。它的复杂性随着微服务数量的增加而增加。
• 熟练的开发人员需要使用微服务架构，它可以识别微服务并管理它们的相互通信。
• 微服务的独立部署很复杂。
• 微服务在网络使用方面的成本很高，因为它们需要相互交互，所有这些远程调用都会导致网络延迟。
• 由于网络上的服务间通信，微服务相对于单体应用程序的安全性较低。
• 调试很困难，因为控制流过许多微服务，并且指出错误发生的原因和确切位置是一项艰巨的任务。