微服务–解决复杂性

与其构建一个单一的，单一的应用程序，不如将您的应用程序拆分为一组较小的，相互连接的服务。
服务通常实现一组不同的特征或功能，例如订单管理，客户管理等。每个微服务都是一个微型应用程序，具有自己的六边形体系结构，该体系结构由业务逻辑和各种适配器组成。某些微服务会公开其他微服务或应用程序客户端使用的API。其他微服务可能实现Web UI。在运行时，每个实例通常是云VM或Docker容器

微服务

每个微服务都是一个微型应用程序 - 在运行时，每个实例通常是云VM或Docker容器。
每个服务实例都是一个Docker容器。为了高度可用，这些容器在多个Cloud VM上运行

通信：

*基于消息的异步通信。通信是通过称为API网关的中介进行的。API网关负责执行诸如负载平衡，缓存，访问控制，API计量和监视之类的任务

微服务与数据库之间的关系

每个服务都具有数据库架构是必不可少的，因为这样可以确保松散耦合。

image.png

微服务的好处

巨大的整体应用程序分解为一组服务。虽然功能总数不变，但该应用程序已分为可管理的块或服务
该体系结构使每个服务可以由专注于该服务的团队独立开发。开发人员可以自由选择任何有意义的技术，只要该服务遵守API合同即可。
微服务架构模式使每个微服务可以独立部署。
微服务架构模式使每个服务都可以独立扩展。您可以仅部署满足其容量和可用性约束的每个服务的实例数。此外，您可以使用最符合服务资源要求的硬件。例如，您可以在EC2 Compute Optimized实例上部署CPU密集型图像处理服务，并在EC2 Memory Optimized实例上部署内存数据库服务。

微服务的缺点

微服务一词过分强调服务规模。实际上，有些开发人员主张构建极细粒度的10-100 LOC服务。尽管小型服务是更可取的，但重要的是要记住，它们是达到目的的一种手段，而不是主要目标。微服务的目标是充分分解应用程序，以促进敏捷应用程序的开发和部署。
分布式系统这一事实而导致的复杂性。开发人员需要选择并实现基于消息传递或RPC的进程间通信机制。此外，由于请求的目的地可能很慢或不可用，它们还必须编写代码来处理部分失败。
分区数据库体系结构。更新多个业务实体的业务交易相当普遍。由于只有一个数据库，因此在单一应用程序中实现这类事务很简单。但是，在基于微服务的应用程序中，您需要更新不同服务拥有的多个数据库。
微服务架构模式的另一个主要挑战是实现跨多个服务的更改。例如，假设您正在实现一个需要更改服务A，B和C的案例，其中A依赖于B，B依赖于C。
在微服务架构模式中，您需要仔细计划和协调对每个服务的更改的推出。例如，您需要先更新服务C，然后再更新服务B，最后再更新服务A。
部署基于微服务的应用程序也要复杂得多。