为了理解微服务，我们需要了解什么是单片应用程序以及什么使我们在近代从单片应用程序迁移到微服务。
单片应用
如果项目的所有功能都存在于单个代码库中，则该应用程序称为整体应用程序。我们每个人都必须在自己的生活中设计一个整体应用程序，在该应用程序中，我们得到了问题陈述，并被要求设计具有各种功能的系统。我们在表示，服务和持久性等各个层面上设计应用程序，然后将该代码库部署为单个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演进微服务的基本思想是减少服务之间的依赖性，并通过上述准则使它们松散耦合。
微服务的优势：
- 它相对较小，因此易于管理。
- 如果其中一个微服务有任何更新，那么我们仅需要重新部署该微服务。
- 微服务是独立的，因此是独立部署的。它们的启动和部署时间相对较少。
- 对于新开发人员来说，加入项目非常容易，因为他只需要了解提供他将要工作的功能而不是整个系统的特定微服务即可。
- 如果某个特定的微服务由于用户过度使用该功能而面临巨大的负载，那么我们仅需要扩展该微服务。因此，微服务架构支持水平扩展。
- 每个微服务都可以根据业务需求使用不同的技术。
- 如果某个特定的微服务由于某些错误而关闭，那么它不会影响其他微服务，并且整个系统将保持完整，并继续为用户提供其他功能。
微服务的缺点：
- 作为一个分布式系统，它比单一应用程序要复杂得多。随着微服务数量的增加，其复杂性也随之增加。
- 熟练的开发人员需要使用微服务体系结构，该体系结构可以识别微服务并管理其相互通信。
- 微服务的独立部署非常复杂。
- 由于微服务需要相互交互，因此微服务的网络使用成本很高，所有这些远程调用都会导致网络延迟。
- 由于通过网络进行服务间通信，因此相对于单片应用程序，微服务的安全性较低。
- 由于控件流经许多微服务，因此调试很困难，并且指出错误发生的原因和确切位置是一项艰巨的任务。