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

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。