微服务架构基本介绍与微服务设计模式

微服务与传统单体服务

一个项目中包含了所有的服务叫做单体服务

优点：

缺点:

微服务是把每一个职责单一的功能放在独立的服务中，且每个服务运行在一个单独的进程中，每个服务都有自己的数据存储（如缓存、消息队列）

优点：

缺点：

SOA（面向服务的架构）：SOA是一个组件模型，将不同功能单元通过定义好的接口和契约进行关联。使得构建在各种各样的系统中的服务可以以一种统一和通用的方式交互。

微服务：将一个单体应用作为一套小型服务开发的方法，每个服务都在自己的进程中运行。同行使用轻量级（通常是HTTP）机制通信。每个服务可以使用不同的编程语言编写，并使用不同的数据存储技术。

区别如下：

类似于数据库中的聚合查询一样，聚合器调用多个服务实现应用程序所需的功能。
它可以是一个web页面，将所有微服务的数据进行处理后展示；也可以是对多个微服务进行组合，发布成为一个新的微服务（符合DRY（Don’t Repeat Yourself）原则）

代理和聚合的主要区别是：代理不做聚合数据，仅仅做代理。
代理模式会根据需求的差别调用不同的微服务，代理可以仅仅做请求委派，也可以对数据进行转换

各种服务之间具有逻辑上的执行顺序，需要串行操作

在这种情况下，服务A（SA）接收到请求后会与服务B通信，服务B会与服务C通信。所有服务都是用同步消息传递。在整个链式调用结束之前，客户端会一致阻塞等待响应，因此服务调用链不宜过长，避免客户端长时间等待。

SA服务的分支为SB、SC两个服务，也就意味着SA可以与SB、SC两个服务进行交互，很多的业务模型可以通过此模型进行处理

在单体应⽤用到微服务架构的过渡阶段，可以使⽤用这种设计模式

在这种情况下，部分微服务可能会共享缓存和数据库存储。不过只有在两个服务间存在强耦合关系才可以。

虽然REST规范非常流行，但它是同步的，会造成客户端阻塞。因此部分基于微服务的架构可能会选择使用消息队列来代替REST的请求/响应，因为消息队列可以是异步的。

如图可知，SA、SB、SC之间通过消息队列进行异步消息通信，服务之间不需要等待请求结束

除了以上几种微服务设计模式，我们还可以基于几种基础的设计模式进行组合，如分叉+链式组合、链式+异步消息传递组合等

Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的⼯具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。
分布式系统的协调板模式, 使用SpringCloud开发人员可以快速地支持实现这些模式的服务和应用程序