一、微服务架构设计中经常需要处理的问题罗列：
- API Gateway
- 内部服务间互相调用
- 服务发现
- 服务容错、熔断、降级
- 服务部署
- 数据处理
二、设计模式
1、微服务-聚合器设计模式：
聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的 WEB 页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合 DRY 原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿 X轴 和 Z轴 独立扩展。
本文作者:张永清，转载注明出处：https://www.cnblogs.com/laoqing/p/13187684.html
DRY 原则：
不做重复的事（Don't Repeat Yourself），意思是说，在一个设计里，对于任何东西，都应该有且只有一个表示，其它的地方都应该引用这一处。这样需要改动的时候，只需调整这一处，所有的地方就都变更过来了。降低可管理单元复杂度的一个基本策略就是将他们拆解成更小的单元。
2、微服务-代理设计模式：
类似聚合设计模式，但是客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。
3、微服务-链式设计模式：
serviceA 接收到请求后会与 serviceB 进行通信，类似地，serviceB 会同 serviceC 进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待，这是一个同步的串行处理过程，无法进行并行处理。
4、微服务-分支设计模式：
允许同时调用两个微服务链，适合于并行调用处理，效率更高。
5、微服务-dataShared设计模式：
部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式，正常的情况下，不推荐这么设计。
6、微服务-异步消息设计模式：
RESTFul 设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替 RESTFul 请求/响应。
来源：oschina
链接：https://my.oschina.net/u/4344048/blog/4322265