在过去几年中，基于微服务的体系结构吸引了众多媒体的关注。
关于基于微服务的体系结构的好处，已经有很多教程 和文章。
它不过是将应用程序设计为不同的小组件的独特方式，可以将其独立部署为单独的服务。

简而言之，微服务架构不过是应用程序开发的一种方法，其中将应用程序分解为不同的组件，并且每个应用程序组件分别开发，单独打包并分别部署在单独的进程中。

这些服务通常可以使用HTTP REST API之类的机制彼此通信。
这些不同的组件通常由各个团队开发，并通常通过不同的机制分别部署。
大多数时候，这些不同的服务是用不同的编程语言编写的。
要了解基于微服务的体系结构，首先应该研究应用程序开发的更广泛采用的标准单片体系结构。

整体应用程序作为单个程序包构建，其中包含了所有必需的组件，包括服务。

通常，Web应用程序具有两个主要组件。

• 关系数据库。
• 服务器端应用程序。

服务器端应用程序将在这里进行繁重的工作。
服务器端应用程序将负责处理来自客户端的HTTP请求，从数据库检索数据，使用新数据更新数据库，为客户端提供适当HTML响应。

如上图所示，前端与核心逻辑完全分离，可以独立缩放。
后端组件也通过单独的数据库分离到不同的服务。
为每个服务拥有单独的数据库可以帮助修改数据库架构，而不会影响基础架构中的任何其他组件。

可以将上面显示的每个服务放置在它们自己的负载平衡器之后，以实现该服务的更高吞吐量和可用性。

使用服务的另一个主要优点是每个服务都可以使用自己所需的数据库类型。
如果需要，某些服务可以使用nosql数据库，某些服务可以使用传统的RDB。

微服务这个名字有点侧重于服务的大小。
不幸的是，micro没有说多少被认为是micro（在应用程序开发中，我们可以考虑并以代码行的形式进行计算）。
对于不同的，这可能会有所不同。
一个好的方法是让由10名成员或者类似成员组成的团队来管理和开发单个服务。

这里的主要优势是让较小的团队在这里管理不同的服务。
而且，各个团队现在都拥有选择最适合其服务的所需技术堆栈的完整权限。
团队唯一需要确保的是服务公开的接口必须满足其他互通服务的要求。

由于每个服务都可以单独部署，因此可以继续部署而不会影响体系结构的其他组件。
而且，每个服务都可以单独扩展，这使得轻松部署满足特定服务要求的所需实例数成为可能。
我们也可以为特定服务选择最合适的硬件。

假设我们有一项用于将视频转码为不同格式的服务（这是一个cpu密集过程），在这里我们可以使用更高的CPU硬件，仅用于此服务（其他服务可以使用更少的CPU硬件）。
在整体式中，我们必须选择一种满足大型应用程序一部分（不能有效利用资源）的所有其他服务的硬件。

基于微服务的设计实际上并不是什么新鲜事物。
实际上，UNIX设计理念是完全相同的。
尽管使用基于微服务的体系结构有很多优点，但它并不是解决所有应用程序开发和部署问题的解决方案。

以下是一些较小的问题，或者我必须说的是迁移到基于微服务的体系结构中的缺点。

• 在单片应用程序中，组件可以通过简单地使用语言内部过程或者调用特定方法（因为所有内容都是单个应用程序的一部分）进行对话和处理。对于基于微服务的体系结构，开发人员将不得不处理用于服务之间相互通信的逻辑，并且还必须处理它们之间的故障。尽管它没什么大不了，但与单片应用程序相比，它仍然有些复杂。
• 与单片应用程序相比，测试服务有点单调乏味，因为一个服务也可能依赖于其他服务。
• 需要一种服务发现机制，该机制服务查找其他服务。这是必需的，因为在微服务体系结构中，服务实例通常是不可变的。此外，服务的位置（IP地址）将动态更改（在放大，缩小或者新部署等过程中），其他人需要毫不延迟地获取新位置。

如果应用程序本身很小，并且其中没有太多的逻辑和模块，则适用单独式。
如果应用程序确实很大，很复杂并且做了很多不同的事情，那么基于微服务的体系结构最适合。