架构设计思想-微服务架构设计模式

1、微服务架构设计中常常须要处理的问题罗列：

• API Gateway
• 内部服务间互相调用
• 服务发现
• 服务容错、熔断、降级
• 服务部署
• 数据处理

 

2、设计模式

一、微服务-聚合器设计模式：

 

 

 

 

聚合器调用多个服务实现应用程序所需的功能。它能够是一个简单的 WEB 页面，将检索到的数据进行处理展现。它也能够是一个更高层次的组合微服务，对检索到的数据增长业务逻辑后进一步发布成一个新的微服务，这符合 DRY 原则。另外，每一个服务都有本身的缓存和数据库。若是聚合器是一个组合服务，那么它也有本身的缓存和数据库。聚合器能够沿 X轴 和 Z轴 独立扩展。 

本文做者:张永清，转载注明出处：http://www.javashuo.com/article/p-kyqmdqqe-ng.html

DRY 原则：

不作重复的事（Don't Repeat Yourself），意思是说，在一个设计里，对于任何东西，都应该有且只有一个表示，其它的地方都应该引用这一处。这样须要改动的时候，只需调整这一处，全部的地方就都变动过来了。下降可管理单元复杂度的一个基本策略就是将他们拆解成更小的单元。

二、微服务-代理设计模式：

 

 相似聚合设计模式，可是客户端并不聚合数据，但会根据业务需求的差异调用不一样的微服务。代理能够仅仅委派请求，也能够进行数据转换工做。

三、微服务-链式设计模式：

serviceA 接收到请求后会与 serviceB 进行通讯，相似地，serviceB 会同 serviceC 进行通讯。全部服务都使用同步消息传递。在整个链式调用完成以前，客户端会一直阻塞。所以，服务调用链不宜过长，以避免客户端长时间等待，这是一个同步的串行处理过程，没法进行并行处理。

四、微服务-分支设计模式：

 

 容许同时调用两个微服务链，适合于并行调用处理，效率更高。

五、微服务-dataShared设计模式：

 

 部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才能够。对于基于微服务的新建应用程序而言，这是一种反模式，正常的状况下，不推荐这么设计。

六、微服务-异步消息设计模式：

 

  RESTFul 设计模式很是流行，但它是同步的，会形成阻塞。所以部分基于微服务的架构可能会选择使用消息队列代替 RESTFul 请求/响应。