微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自DDD领域驱动设计。
简单来说，微服务就是将原来庞大的单体架构的各个业务模块变为独立的可运行的服务，一些微服务会暴露一个供其他微服务或应用客户端消费的 API，模块与模块之间通过API互相调用。各个业务模块都是一个服务，整个项目有众多服务组成，这就是微服务。

微服务的优缺点

优点

第一，它解决了复杂问题。它把可能会变得庞大的单体应用程序分解成一套服务。虽然项目的功能数量不变，但是应用程序已经被分解成可管理的块或者服务。每个服务都有一个明确定义边界的方式，如远程过程调用（RPC）驱动或消息驱动 API。微服务架构模式强制一定程度的模块化，实际上，使用单体代码来实现是极其困难的。因此，使用微服务架构模式，个体服务能被更快地开发，并更容易理解与维护。
第二，这种架构使得每个服务都可以由一个团队独立专注开发。开发者可以自由选择任何符合服务 API 契约的技术。当然，更多的组织是希望通过技术选型限制来避免完全混乱的状态。然而，这种自由意味着开发人员不再有可能在这种自由的新项目开始时使用过时的技术。当编写一个新服务时，他们可以选择当前的技术。此外，由于服务较小，使用当前技术重写旧服务将变得更加可行。
第三，微服务架构模式可以实现每个微服务独立部署。开发人员根本不需要去协调部署本地变更到服务。这些变更一经测试即可立即部署。比如，UI 团队可以执行 A|B 测试，并快速迭代 UI 变更。微服务架构模式使得持续部署成为可能。
最后，微服务架构模式使得每个服务能够独立扩展。您可以仅部署满足每个服务的容量和可用性约束的实例数目。此外，您可以使用与服务资源要求最匹配的硬件。

缺点

第一，由于微服务是一个分布式系统，其使得整体变得复杂。开发者需要选择和实现基于消息或者 RPC 的进程间通信机制。此外，由于目标请求可能很慢或者不可用，他们必须要编写代码来处理局部故障。虽然这些并不是很复杂、高深，但模块间通过语言级方法/过程调用相互调用，这比单体应用要复杂得多。
第二，分区数据库架构。更新多个业务实体的业务事务是相当普遍的。这些事务在单体应用中的实现显得微不足道，因为单体只存在一个单独的数据库。在基于微服务的应用程序中，您需要更新不同服务所用的数据库。通常不会选择分布式事务，不仅仅是因为 CAP 定理。他们根本不支持如今高度可扩展的 NoSQL 数据库和消息代理。最后不得不使用基于最终一致性的方法，这对于开发人员来说更具挑战性。
第三，测试微服务应用程序也很复杂。例如，使用现代框架如 Spring Boot，只需要编写一个测试类来启动一个单体 web 应用程序并测试其 REST API。相比之下，一个类似的测试类对于微服务来说需要启动该服务及其所依赖的所有服务，或者至少为这些服务配置存根。再次声明，虽然这不是一件高深的事情，但不要低估了这样做的复杂性。
第四，部署基于微服务的应用程序也是相当复杂的。一个单体应用可以很容易地部署到基于传统负载均衡器的一组相同服务器上。每个应用程序实例都配置有基础设施服务的位置（主机和端口），比如数据库和消息代理。相比之下，微服务应用程序通常由大量的服务组成。

总结

单体架构和微服务各有各的优缺点，并不是说谁好谁坏，更重要的是根据项目做架构选型。比如，单体架构模式只适用于简单、轻量级的应用程序，如果使用它来构建复杂应用，最终会陷入痛苦的境地。微服务架构模式是复杂、持续发展应用的一个更好的选择。

传统架构与微服务架构的区别

对于同一个购物商城的架构，传统架构与微服务架构分别如下：

传统架构

在这里插入图片描述

微服务架构

在这里插入图片描述

说到这儿，自然而然的我们就要思考几个问题：

客户端如何访问这些服务？

原来的单体架构方式开发，所有的服务都是本地的，前端用户可以直接调用，现在按功能拆分成独立的服务，跑在独立的一般都在独立的虚拟机上的 Java 进程了。客户端 UI 如何访问它？

后台有 N 个服务，前台就需要记住管理 N 个服务，一个服务下线、更新、升级，前台就要重新部署，这明显不服务我们拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。

另外，N 个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth）。

所以，一般在后台 N 个服务和 UI 之间一般会一个代理或者叫 API Gateway，他的作用包括：
* 提供统一服务入口，让微服务对前台透明
* 聚合后台的服务，节省流量，提升性能
* 提供安全，过滤，流控等API管理功能

其实这个 API Gateway 可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的 MVC 框架，甚至是一个 Node.js 的服务端。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过 API Gateway 也有可能成为单点故障点或者性能的瓶颈。

微服务架构中，所有的微服务都是独立的 Java 进程跑在独立的虚拟机上，那么服务与服务之间如何通信呢？

服务间的通信是 IPC（Inter Process Communication），已经有很多成熟的方案。

基本最通用的有两种方式：

同步调用: REST（JAX-RS，Spring Boot）、 RPC（Thrift, Dubbo）

异步消息调用: RabbitMQ 、ActiveMQ 、 Kafka 、Notify 、MessageQueue

如此多的服务，如何实现？

在微服务架构中，一般每一个服务都是有多个拷贝(也就是集群，实现高可用)，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知？服务如何管理？

这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过 Zookeeper 等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到 ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过 ZK 寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK 会发通知给服务客户端。

服务挂了，如何解决？

前面提到，单体架构方式开发一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。所以当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：
重试机制
限流
熔断机制
负载均衡
降级（本地缓存）

微服务核心思想

微服务相关概念

在这里插入图片描述

乍一看这张图，是不是一脸懵逼？？？？这都是些什么鬼哦。
下面且听我细细给你道来。

服务注册与发现

到底什么是服务注册，什么又是发现呢？
- 举一个生活中的例子，就比如我们平时寻女朋友找婚姻介绍所的事情。
- 在没有婚姻介绍所的时候我们需要茫茫人海、苦苦去寻找是世界之中否有你心中梦寐以求想要的那个女孩子，这显然会非常的费力。而且你仅凭一个人的能力是找不到很多那么多供你选择，又或者你也懒得满世界这么找下去(找了这么久，没有合适的只能随便将就…说到这儿，单身狗默默流下了不知名的眼泪…我这连个可以将就的都没有…)。这里的我们就相当于微服务中的Consumer（消费者），而女朋友就相当于微服务中的Provider（提供者）。消费者Consumer需要调用提供者Provider提供的一些服务，就像我们现在需要她们的人一样，来跟我们结婚、一起过甜美的二人世界。
- 但是如果只是男孩子与女孩子之间进行寻找的话，效率是如此低下，你找不到女朋友，女孩子也找不到男朋友。所以，后来聪明的你肯定就想到了广播自己的招婚信息(比如在街边贴贴小广告，搞不好还要被城管追着满城跑，网上发发博客，朋友圈…hahh)，这样对于你来说，已经完成你的任务(将你的招婚信息公布出去)，但是这个时候我们是否能想到一些问题。第一、其他不是你理想的女孩子们是不是能收到这种消息，这在现实世界没什么，但是在计算机的世界中就会出现资源消耗的问题了。第二、想找男朋友的女孩子这样还是很难找到你，试想一下我需要找个男朋友，我还需要满大街的去找街边小广告，麻不麻烦？
- 那怎么办呢？我们当然不会那么傻乎乎的，第一时间就是去找婚姻介绍所呀，它为我们提供了统一信息的地方，我们只需要跑到它那里去找就行了。而对于女孩子来说，她们也只需要把自己的招婚信息在婚姻介绍所那里注册发布就行了。
- 那么现在，我们的模式就是这样的了。
但是，这个时候还会出现一些问题。
- 女神注册之后如果不想找男朋友了怎么办？我们是不是需要让女神定期续约？如果女神不进行续约是不是要将他们从婚姻介绍所那里的注册列表中移除。
- 男孩子们是不是也要进行注册呢？
- 婚姻介绍所可不可以做连锁店呢？如果这一个店因为某些不可抗力因素而无法使用，那么我们是否可以换一个连锁店呢？
针对上面的问题我们来重新构建一下上面的模式图
婚姻介绍所就是一个中心，那里的信息就是权威。在 Spring Cloud 体系中，最常用的注册中心主要是 Eureka、Zookeeper、Consul、Nacos。
任何服务启动以后，都会把自己注册到注册中心的注册表中；当服务死亡的时候，也会通知注册中心。

服务调用

负载均衡之 Ribbon

什么是 RestTemplate?

RestTemplate是Spring提供的一个访问Http服务的客户端类，怎么说呢？就是微服务之间的调用是使用的RestTemplate。比如这个时候我们消费者B 需要调用提供者A 所提供的服务我们就需要这么写。

伪代码

public class OrderController {
    //private static final String PAYMENT_URL="http://localhost:8001";  //单机版
    private static final String PAYMENT_URL="http://CLOUD-PROVIDER-SERVICE";  //集群版,(负载均衡)

    @Resource
    private RestTemplate restTemplate;

    @GetMapping("/consumer/payment/create")
    public CommonResult<Payment> create(Payment payment){
        return restTemplate.postForObject(PAYMENT_URL+"/payment/create",payment,CommonResult.class);
    }
}

RestTemplate使用：官网地址

为什么需要 Ribbon？
- Ribbon 是Netflix公司的一个开源的负载均衡项目，是一个客户端/进程内负载均衡器，运行在消费者端。
- 比如我们设计了一个秒杀系统，但是为了整个系统的高可用，我们需要将这个系统做一个集群，而这个时候我们消费者就可以拥有多个秒杀系统的调用途径了，如下图。
- 如果这个时候我们没有进行一些均衡操作，如果我们对秒杀系统1进行大量的调用，而另外两个基本不请求，就会导致秒杀系统1崩溃，而另外两个就变成了傀儡，那么我们为什么还要做集群，我们高可用体现的意义又在哪呢？
- 所以Ribbon出现了，注意我们上面加粗的几个字——运行在消费者端。指的是，Ribbon是运行在消费者端的负载均衡器，如下图。
- 其工作原理就是Consumer端获取到了所有的服务列表之后，在其内部使用负载均衡算法，进行对多个系统的调用。

Nginx 和 Ribbon 的对比

提到负载均衡就不得不提到大名鼎鼎的Nignx了，而和Ribbon不同的是，它是一种集中式的负载均衡器。
- 何为集中式呢？简单理解就是将所有请求都集中起来，然后再进行负载均衡。如下图。
- 我们可以看到Nginx是接收了所有的请求进行负载均衡的，而对于Ribbon来说它是在消费者端进行的负载均衡。如下图。

注意：Request的位置，在Nginx中请求是先进入负载均衡器，而在Ribbon中是先在客户端进行负载均衡才进行请求的。

Ribbon 的几种负载均衡算法
负载均衡，不管Nginx还是Ribbon都需要其算法的支持，Nginx使用的是轮询、轮询权值、ip_hash算法等五种。而在Ribbon中的负载均衡调度算法，其默认是使用的RoundRobinRule轮询策略。
- RoundRobinRule：轮询策略。Ribbon默认采用的策略。若经过一轮轮询没有找到可用的provider，其最多轮询 10 轮。若最终还没有找到，则返回 null。
- RandomRule: 随机策略，从所有可用的 provider 中随机选择一个。
- RetryRule: 重试策略。先按照 RoundRobinRule 策略获取 provider，若获取失败，则在指定的时限内重试。默认的时限为 500 毫秒。

什么是 Open Feign

OpenFeign 也是运行在消费者端的，使用 Ribbon 进行负载均衡，所以 OpenFeign 直接内置了 Ribbon。Feign集成了Ribbon,利用Ribbon维护了Payment 的服务列表信息，并且通过轮询实现了客户端的负载均衡。而与Ribbon不同的是，通过feign 只需要定义服务绑定接口且以声明式的方法，优雅而简单的实现了服务调用。

@Component
@FeignClient(value = "CLOUD-PROVIDER-SERVICE")  //指定调用哪个微服务
public interface PaymentFeignService {

    @GetMapping(value = "/payment/get/{id}")    //哪个地址
    CommonResult<Payment> getPaymentById(@PathVariable("id") Long id);
}

在Controller就可以像原来调用Service层代码一样调用它了。

@RestController
@Slf4j
public class OrderFeignController {

    @Resource
    private PaymentFeignService paymentFeignService;

    @GetMapping(value = "/consumer/payment/get/{id}")
    public CommonResult<Payment> getPaymentById(@PathVariable("id") Long id){
        return paymentFeignService.getPaymentById(id);
    }
}

Ribbon和Open Feign，它们有一个比较通用的名词，就叫做 RPC（远程调用）。

服务降级、熔断和限流

服务雪崩

在这里插入图片描述

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的 “ 扇出 ” 。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A 的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的 “ 雪崩效应 ”。
对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接受流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。
要避免这样的级联故障，就需要有一种链路中断的方案：服务降级、服务熔断

什么是 Hystrix之服务熔断、降级和限流

在分布式环境中，不可避免地会有许多服务依赖项中的某些失败。Hystrix是一个库，可通过添加等待时间容限和容错逻辑来帮助您控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点，停止服务之间的级联故障并提供后备选项来实现此目的，所有这些都可以提高系统的整体弹性

什么是熔断？

熔断就是服务雪崩的一种有效解决方案。当指定时间窗内的请求失败率达到设定阈值时，系统将通过断路器直接将此请求链路断开。也就是我们上面服务B调用服务C在指定时间窗内，调用的失败率到达了一定的值，那么熔断器则会自动将服务B与C 之间的请求都断了，以免导致服务雪崩现象。
其实这里所讲的熔断就是指的[Hystrix]中的断路器模式，你可以使用简单的@HystrixCommand 注解来标注某个方法，这样[Hystrix]就会使用断路器来“包装”这个方法，每当调用时间超过指定时间时(默认为1000ms)，断路器将会中断对这个方法的调用。
当然你可以对这个注解的很多属性进行设置，比如设置超时时间，像这样。当请求时间超过1.5秒的时候，服务就会中断paymentInfo_TimeOut方法的调用。

@RestController
public class OrderHystrixController {

    @Resource
    private PaymentHystrixService paymentHystrixService;

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
    @HystrixCommand(commandProperties = {
          @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "1500")
    })
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id){
        return paymentHystrixService.paymentInfo_TimeOut(id);
    }
}

什么是降级呢？

降级是为了更好的用户体验，当一个方法调用异常时，通过执行另一种代码逻辑来给用户友好的回复。这也就对应着[Hystrix]的后备处理模式。你可以通过设置@HystrixCommand 注解的fallbackMethod属性来给一个方法设置备用的代码逻辑。比如这个时候有一个微博里有一个热点新闻出现了，我们会推荐给用户查看详情，然后用户会通过id去查询新闻的详情，但是因为这条新闻太火了，大量用户同时访问可能会导致系统崩溃，那么我们就进行服务降级，一些请求会做一些降级处理。比如，当前人数太多请稍后查看等等。

通过@DefaultProperties(defaultFallback = "payment_Global_FallBackMethod") + @HystrixCommand 注解实现全局异常降级服务
通过 @HystrixCommand(fallbackMethod = "paymentTimeOutFallBackMethod",commandProperties = { @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "1500") })实现paymentInfo_TimeOut方法的降级服务。

@RestController
@DefaultProperties(defaultFallback = "payment_Global_FallBackMethod")
public class OrderHystrixController {

    @Resource
    private PaymentHystrixService paymentHystrixService;

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
    /*@HystrixCommand(fallbackMethod = "paymentTimeOutFallBackMethod",commandProperties = {
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "1500")
    })*/
    @HystrixCommand
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id){
        return paymentHystrixService.paymentInfo_TimeOut(id);
    }

    public String paymentTimeOutFallBackMethod(@PathVariable("id") Integer id){
        return "我是消费者80，对方支付系统繁忙，请稍后再试，o(╥﹏╥)o";
    }

    public String payment_Global_FallBackMethod(){
        return "全局异常降级处理，请稍后再试...";
    }
}

什么是限流呢？

秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行

Sentinel: 分布式系统的流量防卫兵

Sentinel 是什么

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式服务架构的轻量级流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护等多个维度来帮助您保障微服务的稳定性。

服务网关

网关——Zuul

ZUUL 是从设备和 web 站点到 Netflix 流应用后端的所有请求的前门。作为边界服务应用，ZUUL 是为了实现动态路由、监视、弹性和安全性而构建的。它还具有根据情况将请求路由到多个 Amazon Auto Scaling Groups（亚马逊自动缩放组，亚马逊的一种云计算方式）的能力.

网关应该很熟吧，简单来讲网关是系统唯一对外的入口，介于客户端与服务器端之间，用于对请求进行鉴权、限流、路由、监控等功能。

Gateway网关

Gateway支持 Reactor 和 WebFlux
传统的Web框架，比如说：struts2，springmvc等都是基于Servlet API与servlet容器基础之上运行的。但是Servlet3.1之后有了异步非阻塞的支持，而WebFlux是一个典型非阻塞异步的框架，它的核心是基于Reactor的相关API实现的。相对与传统的Web框架来说，它可以运行在诸如Netty，Undertow及支持Servlet3.1的容器上。非阻塞式+函数式编程
Spring WebFlux 是 Spring 5.0引入的新的响应式框架，区别于Spring MVC，它不需要依赖Servlet API，它是完全异步非阻塞的，并且基于 Reactor 来实现响应式流规范

服务配置

Spring Cloud Config

能进行配置管理的框架不止Spring Cloud Config一种，大家可以根据需求自己选择（disconf，阿波罗等等）。而且对于Config来说有些地方实现的不是那么尽人意。

为什么要使用进行配置管理？
- 当我们的微服务系统开始慢慢地庞大起来，那么多Consumer、Provider、[Eureka] Server、Zuul系统都会持有自己的配置，这个时候我们在项目运行的时候可能需要更改某些应用的配置，如果我们不进行配置的统一管理，我们只能去每个应用下一个一个寻找配置文件然后修改配置文件再重启应用。
- 首先对于分布式系统而言我们就不应该去每个应用下去分别修改配置文件，再者对于重启应用来说，服务无法访问所以直接抛弃了可用性，这是我们更不愿见到的。
简单来说，Spring Cloud Config就是能将各个应用/系统/模块的配置文件存放到统一的地方然后进行管理(Git 或者 SVN)。
你想一下，我们的应用是不是只有启动的时候才会进行配置文件的加载，那么我们的Spring Cloud Config就暴露出一个接口给启动应用来获取它所想要的配置文件，应用获取到配置文件然后再进行它的初始化工作。就如下图。
那怎么进行动态修改配置文件呢？一般我们会使用Bus消息总线 +Spring Cloud Config进行配置的动态刷新。

Spring Cloud Bus

用于将服务和服务实例与分布式消息系统链接在一起的事件总线。在集群中传播状态更改很有用（例如配置更改事件）。

简单理解为Spring Cloud Bus的作用就是管理和广播分布式系统中的消息，也就是消息引擎系统中的广播模式。当然作为消息总线的Spring Cloud Bus可以做很多事而不仅仅是客户端的配置刷新功能。
而拥有了Spring Cloud Bus之后，我们只需要创建一个简单的请求，并且加上@ResfreshScope注解就能进行配置的动态修改了

Nacos 的动态配置服务

动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。
配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。
Nacos 提供了一个简洁易用的UI 帮助您管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。

总结

如果你能这个时候能看懂下面那张图，也就说明了你已经对Spring Cloud微服务有了一定的架构认识。

在这里插入图片描述

主流微服务架构

技术架构图

在这里插入图片描述

第一套微服务架构解决方案：Spring Boot + Spring Cloud Netflix

2018 年 12 月 12 日，Netflix 宣布 Spring Cloud Netflix 系列技术栈进入维护模式（不再添加新特性）

服务注册与发现 Eureka

服务调用 OpenFeign/Ribbon

服务降级 Hystrix

服务网关 Zuul

服务配置 Nacos

链路追踪 SkyWalking

第二套微服务架构解决方案：Spring Boot + Dubbo + Zookeeper

第三套微服务架构解决方案：Spring Boot + Spring Cloud Alibaba

服务注册与发现 Nacos

服务调用 OpenFeign

服务降级 Sentinel

服务网关 Gateway

服务配置 Config

链路追踪 ZipKin

微服务架构设计模式

聚合器微服务设计模式

在这里插入图片描述

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

代理微服务设计模式

在这里插入图片描述

在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。

链式微服务设计模式

在这里插入图片描述

在这种情况下，服务A 接收到请求后会与服务B 进行通信，类似地，服务B 会同服务C 进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待

分支微服务设计模式

在这里插入图片描述

这种模式是聚合器模式的扩展，允许同时调用两个微服务链

数据共享微服务设计模式

自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（Monolithic Application）”时，SQL 数据库反规范化可能会导致数据重复和不一致。因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式，如下图所示

在这里插入图片描述

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

异步消息传递微服务设计模式

虽然 REST 设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替 REST 请求/响应，如下图所示

在这里插入图片描述

以上这些知识，是我个人的一些见解和看法。如果有不对的地方，还请各位多多赐教。
后续，我会出一些微服务入门的相关博客，还请大家继续关注。
最后，希望大家能给个三连（点赞、评论、关注），谢谢大家啦

你知道的越多，你不知道的越多。
有道无术，术尚可求，有术无道，止于术。
如有其它问题，欢迎大家留言，我们一起讨论，一起学习，一起进步

斗士（Carroll）

发布了193 篇原创文章 · 获赞 116 · 访问量 1万+

私信关注

微服务入门，有这一篇就够了

文章目录

何为微服务？

微服务的优缺点

优点

缺点

总结

传统架构与微服务架构的区别

传统架构

微服务架构

微服务核心思想

微服务相关概念

服务注册与发现

服务调用

负载均衡之 Ribbon

Nginx 和 Ribbon 的对比

什么是 Open Feign

服务降级、熔断和限流

服务雪崩

什么是 Hystrix之服务熔断、降级和限流

什么是熔断？

什么是降级呢？

什么是限流呢？

Sentinel: 分布式系统的流量防卫兵

Sentinel 是什么

服务网关

网关——Zuul

Gateway网关

服务配置

Spring Cloud Config

Spring Cloud Bus

Nacos 的动态配置服务

总结

主流微服务架构

技术架构图

第一套微服务架构解决方案：Spring Boot + Spring Cloud Netflix

第二套微服务架构解决方案：Spring Boot + Dubbo + Zookeeper

第三套微服务架构解决方案：Spring Boot + Spring Cloud Alibaba

微服务架构设计模式

聚合器微服务设计模式

代理微服务设计模式

链式微服务设计模式

分支微服务设计模式

数据共享微服务设计模式

异步消息传递微服务设计模式

猜你喜欢