大家好，今天来为大家分享微服务架构七种模式的一些知识点，和为什么不建议链式调用的问题解析，大家要是都明白，那么可以忽略，如果不太清楚的话可以看看本篇文章，相信很大概率可以解决您的问题，接下来我们就一起来看看吧！
本文目录
如何确定JS中链式调用Promise.then()的执行顺序问题
Promise执行是无法预估时间顺序的，如果你想让promise有序的执行，那么可以使用Promise.all方法，或者在promise.then中嵌套使用
微服务架构七种模式
微服务架构有六种模式，分别是。
1、聚合器微服务设计模式
聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。
2、代理微服务设计模式
在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。
3、链式微服务设计模式
这种模式在接收到请求后会产生一个经过合并的响应。
在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。
4、分支微服务设计模式
5、数据共享微服务设计模式
自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（monolithicapplication）”时，SQL数据库反规范化可能会导致数据重复和不一致。
在这种情况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。
6、异步消息传递微服务设计模式
虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应。
jquery为什么能进行链式操作
jquery能进行链式操作的原因是，每个Jquery的函数并不是void类型的，而是会返回操作对象，比如find函数，用于根据选择器表达式寻找对应元素，函数的返回对象就是这些元素对象，此时调用者可以继续在函数后面通过.操作完成后续功能调用，形成链式操作。
Spring中如何使用责任链模式
关于责任链模式，其有两种形式，一种是通过外部调用的方式对链的各个节点调用进行控制，从而进行链的各个节点之间的切换；另一种是链的每个节点自由控制是否继续往下传递链的进度，这种比较典型的使用方式就是Netty中的责任链模式。本文主要讲解我们如何在Spring中使用这两种责任链模式。
1.外部控制模式
对于外部控制的方式，这种方式比较简单，链的每个节点只需要专注于各自的逻辑即可，而当前节点调用完成之后是否继续调用下一个节点，这个则由外部控制逻辑进行。这里我们以一个过滤器的实现逻辑为例进行讲解，在平常工作中，我们经常需要根据一系列的条件对某个东西进行过滤，比如任务服务的设计，在执行某个任务时，其需要经过诸如时效性检验，风控拦截，任务完成次数等过滤条件的检验之后才能判断当前任务是否能够执行，只有在所有的过滤条件都完成之后，我们才能执行该任务。那么这里我们就可以抽象出一个接口，其设计如下：
这里的方法只有一个参数，主要就是控制当前task是否需要被过滤掉，其有一个boolean类型的返回值，通过该返回值以告知外部控制逻辑是否需要将该task过滤掉。对于该接口的子类，我们只需要将其声明为Spring所管理的一个bean即可：
上面我们模拟声明了三个的子类，用于设计一系列的控制当前task是否需要被过滤的逻辑，结构上的逻辑其实比较简单，主要就是需要将其声明为Spring所管理的一个bean。下面是我们的控制逻辑:
在上述的控制逻辑中，对于过滤器的获取，只需要通过Spring的自动注入即可，这里注入的是一个，也就是说，如果我们有新的实例需要参与责任链的过滤，只需要将其声明为一个Spring容器所管理的bean即可。
这种责任链设计方式的优点在于链的控制比较简单，只需要实现一个统一的接口即可，其基本上能够满足大部分的逻辑控制，但是对于某些需要动态调整链的需求其就无能为力了。比如在执行到某个节点之后需要动态的判断是否执行下一个节点，或者说要执行某些分叉的节点等等。这个时候我们就需要将链节点的传递工作交由各个节点进行。
2.节点控制模式
对于节点控制调用的方式，其主要有三个控制点：Handler，HandlerContext和Pipeline。Handler中是用于编写具体的业务代码的；HandlerContext则主要是用于对Handler进行包裹，并且用于控制进行下一个节点的调用的；Pipeline则主要是用于控制整体的流程调用的，比如对于任务的执行，其有任务的查询，任务的过滤和执行任务等等流程，这些流程整体的逻辑控制就是由Pipeline来控制的，在每个流程中又包含了一系列的子流程，这些子流程则是由一个个的HandlerContext和Handler进行梳理的。这种责任链的控制方式整体逻辑如下图所示：
从图中可以看出，我们将整个流程通过对象进行了抽象，这里主要分为了三个步骤：查询task，过滤task和执行task。在每个步骤中，我们都使用了一系列的链式调用。图中需要注意的是，在每次调用链的下一个节点的时候，我们都是通过具体的Handler进行的，也就是说是否进行链的下一个节点的调用，我们是通过业务实现方来进行动态控制的。
关于该模式的设计，我们首先需要强调的就是接口的设计，其设计如下所示：
这里的接口主要是对具体的业务逻辑的一个抽象，对于该主要有如下几点需要说明：
在前面图中的每个层级中对应于该都有一个方法，在需要进行具体的业务处理的时候，用户只需要声明一个bean，具体实现某个当前业务所需要处理的层级的方法即可，而无需管其他的逻辑；每个层级的方法中，第一个参数都是一个类型的，该参数主要是用于进行流程控制的，比如是否需要将当前层级的调用链往下继续传递，这里链的传递工作主要是通过方法进行的；每个层级的方法都有默认实现，默认实现方式就是将链的调用继续往下进行传递；每个中都有一个方法和方法，这两个方法分别用于异常控制和所有调用完成后的清理的，这里的异常控制主要是捕获当前中的异常，而方法则会保证在所有步骤之后一定会进行调用的，无论是否抛出异常；对于的使用，我们希望能够达到的目的是，适用方只需要实现该接口，并且使用某个注解来将其标志为的bean即可，而无需管整个的组装和流程控制。通过这种方式，我们即保留了每个Spring提供给我们的便利性，也使用了模式的灵活性。上述流程代码中，我们注意到，每个层级的方法中都有一个用于传递链相关的控制信息，这里我们来看一下其源码：
在中，我们需要说明如下几点：
之前接口默认实现的方法，在这里都委托给了对应的方法进行调用，而且我们需要注意到，在传递给方法的参数里，传入的对象都是通过方法获取到的。也就是说我们在中调用方法时，都是在调用当前handler的下一个handler对应层级的方法，通过这种方式我们就实现了链的往下传递。在上一点中我们说到，在某个中如果想让链往下传递，只需要调用方法即可，也就是说，如果我们在某个中，如果根据业务，当前层级已经调用完成，而无需调用后续的，那么我们就不需要调用方法即可；在中，我们也实现了方法，该方法的主要作用是供给外部的进行调用的，以开启每个层级的链；在每个方法中，我们都使用try…catch将当前层级的调用抛出的异常给捕获了，然后调用方法处理该异常，这也就是我们前面说的，如果想处理当前中的异常，只需要实现该中的方法即可，异常捕获流程就是在这里的中进行处理的；在的声明处，我们需要注意到，其使用了和注解进行标注了，这说明我们的是由Spring所管理的一个bean，并且由于我们每一个实际上都由一个维护着，所以这里必须声明为类型。通过这种方式，我们的也就具备了诸如Spring相关的bean的功能，也就能够根据业务需求进行一些额外的处理了；前面我们讲解了和的具体实现，以及实现的过程中需要注意的问题，下面我们就来看一下进行流程控制的是如何实现的，如下是接口的定义：
这里主要是定义了一个接口，该接口定义了一系列的层级调用，是每个层级的入口方法。如下是该接口的一个实现类：
关于的实现，主要有如下几点需要说明：
使用和注解进行了标注，前一个注解用于将其声明为一个Spring容器所管理的bean，而后一个注解则用于表征是一个多例类型的，很明显，这里的是有状态的。这里需要进行说明的是，"有状态"主要是因为我们可能会根据业务情况动态的调整个链的节点情况，而且这里的和对象都是与具体的业务相关的，因而必须声明为类型；上面的示例中，对象是通过构造对象的时候传进来的，而对象则是在的流转过程中生成的，这里比如通过完成链的调用之后，就需要通过外部请求得到一个对象，从而进行整个的后续处理；这里我们已经实现了，和，知道这些bean都是被Spring所管理的bean，那么我们接下来的问题主要在于如何进行整个链的组装。这里的组装方式比较简单，其主要需要解决两个问题：
对于后续写业务代码的人而言，其只需要实现一个接口即可，而无需处理与链相关的所有逻辑，因而我们需要获取到所有实现了接口的bean；将实现了接口的bean通过进行封装，然后将其添加到中。这里的第一个问题比较好处理，因为通过ApplicationContext就可以获取实现了某个接口的所有bean，而第二个问题我们可以通过声明一个实现了BeanPostProcessor接口的类来实现。如下是其实现代码：
这里我们整个链的维护工作就已经完成，可以看到，现在基本上已经实现了前面图中整个链式流程的控制。这里需要说明的一点是，上面的方法的执行是在方法之后执行的，也就是说这里在执行时，整个是已经初始化完成了的。下面我们来看一下外部客户端如何进行整个链是流程的控制：
这里我们模拟了一个客户端的调用，首先创建了一个对象，然后依次调用其各个层级的方法，并且这里我们使用try…finally结构来保证方法一定会执行。如此我们就完成了整个责任链模式的构造。这里我们使用前面用到的时效性过滤的filter来作为示例来实现一个：
关于这里的具体业务我们需要说明的有如下几点：
该必须使用注解来将其声明为Spring容器所管理的一个bean，这样我们前面实现的才能将其动态的添加到整个中；在每个中，需要根据当前的业务需要来实现具体的层级方法，比如这里是进行时效性检验，就是"任务过滤"这一层级的逻辑，因为时效性检验通过我们才能执行这个task，因而这里需要实现的是方法，如果我们需要实现的是执行task的逻辑，那么需要实现的就是方法；在实现完具体的业务逻辑之后，我们可以根据当前的业务需要看是否需要将当前层级的链继续往下传递，也就是这里的方法的调用，我们可以看前面方法就是会获取当前节点的下一个节点，然后进行调用。如果根据业务需要，不需要将链往下传递，那么就不需要调用；3.小结
如此，我们就通过两种方式实现了责任链模式，而且我们实现的责任链模式都是符合"开-闭"原则的，也就是说后续我们要为链添加新的节点的时候，只需要根据规范实现相应的接口即可，而无需处理链的维护相关的工作。关于第二种实现方式，这里我们并没有实现链节点的顺序控制功能，以及如何动态的添加或删除链的节点，更有甚者，如果控制每个Handler是单例的还是多例的。当然，有了前面的框架，这些点实现起来也比较简单，这里权当起到一个抛砖引玉的作用，读者朋友可根据自己的需要进行实现。
关于微服务架构七种模式到此分享完毕，希望能帮助到您。