为了理解微服务，我们需要了解什么是单体应用，以及是什么导致我们最近从单体应用转向微服务。
单体应用
如果项目的所有功能都存在于单个代码库中，则该应用程序称为单体应用程序。我们都必须在我们的生活中设计过一个单体应用程序，在其中我们得到了一个问题陈述，并被要求设计一个具有各种功能的系统。我们在呈现、服务和持久性等各个层设计我们的应用程序，然后将该代码库部署为单个 jar/war 文件。这只不过是一个单体应用程序，其中“mono”代表包含所有必需功能的单个代码库。 
但是，如果我们已经在使用单体应用程序，那么是什么导致我们使用微服务呢?
单体应用的缺点：
- 随着时间的推移，它变得太大，因此难以管理。
- 即使是很小的更改，我们也需要重新部署整个应用程序。
- 随着应用程序大小的增加，其启动和部署时间也会增加。
- 对于任何加入该项目的新开发人员来说，即使他的职责与单个功能相关，也很难理解大型 Monolithic 应用程序的逻辑。
- 即使应用程序的单个部分面临较大的负载/流量，我们也需要将整个应用程序的实例部署在多个服务器中。它非常低效并且不必要地占用更多资源。因此，水平扩展在单体应用中是不可行的。
- 很难采用任何非常适合特定功能的新技术，因为它会影响整个应用程序，无论是时间还是成本。
- 它不是很可靠，因为任何模块中的单个错误都会导致整个单体应用程序崩溃。
单体应用的优点：
- 相对于需要熟练的开发人员来识别和开发服务的微服务而言，开发简单。
- 更容易部署，因为只部署了一个 jar/war 文件。
- 与微服务架构相比，开发相对容易和简单。
- 与微服务架构相比，网络延迟和安全性问题相对较少。
微服务
它是一种架构开发风格，其中应用程序由较小的服务组成，这些服务使用 HTTP 等轻量级协议直接相互通信。根据 Sam Newman 的说法，“微服务是协同工作的小服务。” 
微服务架构对应用与数据库的关系有很大的影响。每个微服务都有自己的数据库，而不是与其他微服务共享一个数据库。它通常会导致某些数据重复，但是如果您想从这种架构中受益，那么每个微服务都有一个数据库是必不可少的，因为它可以确保松散耦合。每个微服务拥有单独的数据库的另一个优点是每个微服务都可以使用最适合其需求的数据库类型。
微服务原理：
- 单一职责：它是定义为 SOLID 设计模式一部分的原则之一。它指出单个单元，无论是类、方法还是微服务，都应该有一个且只有一个职责。每个微服务必须具有单一职责并提供单一功能。您也可以说：您应该开发的微服务数量等于您需要的功能数量。数据库也是去中心化的，通常每个微服务都有自己的数据库。
- 围绕业务能力构建：在当今存在如此众多技术的世界中，总有一种技术最适合实现特定功能。但在单体应用中，这是一个主要缺点，因为我们不能为每个功能使用不同的技术，因此需要在特定领域妥协。微服务永远不会限制自己采用最适合解决业务目的的适当技术堆栈或后端数据库存储，即每个微服务可以根据业务需求使用不同的技术。
- 为失败而设计：微服务的设计必须考虑到失败案例。微服务必须利用这种架构的优势，一个微服务的关闭不应影响整个系统，其他功能必须保持用户可以访问。但在 Monolithic 应用程序中情况并非如此，其中一个模块的故障会导致整个应用程序的崩溃。
面向服务的架构 (SOA) 与微服务架构：
Capgemini 的 MDM Steve Jones 曾经说过，“微服务就是 SOA，对于那些了解 SOA 是什么的人来说”。所以，了解SOA的人，大多认为他们是相同的，或者他们心中的区别并不十分清楚。我们也不能责怪他们，如果我们谈论蛋糕和糕点，我们会发现相同之处多于不同之处。因此，让我们尝试了解两者之间的差异。
SOA 的发展是为了处理单体架构中的问题，并在 2000 年代初流行起来。在 SOA 中，大型应用程序被拆分为多个独立部署的较小服务。这些服务不直接相互通信。曾经有一个企业服务总线(ESB，中间件或服务器在使用不同协议或消息标准的服务的帮助下可以轻松地相互通信)，这些服务通过它暴露自己并相互通信。此外，也没有为每项服务建立独立数据库的指导方针。
微服务架构是 SOA 的演进。人们还将 SOA 视为微服务的超集。简单来说，微服务就是细粒度的 SOA。在这里，微服务之间直接通信，并且没有诸如 SOA 中的 ESB 之类的中心通信依赖。此外，还有一个指导方针，为每个微服务拥有一个单独的数据库。 SOA 微服务演进的基本思想是减少服务之间的依赖关系，并通过上述指南使它们松散耦合。
微服务的优势：
- 它易于管理，因为它的尺寸相对较小。
- 如果其中一个微服务有任何更新，那么我们只需要重新部署该微服务。
- 微服务是自包含的，因此可以独立部署。它们的启动和部署时间相对较短。
- 新开发人员很容易加入该项目，因为他只需要了解提供他将要处理的功能的特定微服务，而不是整个系统。
- 如果某个特定的微服务由于用户过度使用该功能而面临大量负载，那么我们只需要扩展该微服务。因此，微服务架构支持水平扩展。
- 每个微服务可以根据业务需求使用不同的技术。
- 如果某个特定的微服务由于某些错误而宕机，那么它不会影响其他微服务并且整个系统保持完整，继续为用户提供其他功能。
微服务的缺点：
- 作为分布式系统，它比单体应用程序复杂得多。它的复杂性随着微服务数量的增加而增加。
- 熟练的开发人员需要使用微服务架构来识别微服务并管理它们的相互通信。
- 微服务的独立部署很复杂。
- 微服务在网络使用方面的成本很高，因为它们需要相互交互，并且所有这些远程调用都会导致网络延迟。
- 由于网络上的服务间通信，微服务相对于单体应用程序的安全性较低。
- 调试很困难，因为控制流过许多微服务，指出错误发生的原因和位置是一项艰巨的任务。