springcloud项目怎么打包

spring cloud 的核心组件及其作用？那么现在加网微服务这一块呢， spring cloud 呢，应该已经是一个最最主流的解决方案啊，就是我们如果想要啊开发微服务，那么 spring cloud 呢，应该是现在来说应该是最优先的一个选择， 那么 spendcloud 呢？它不，它并不是一个单一的一个框架啊，它解决的是这个微服务，整个一个一个整个流程中啊，各种不同的场景，那么呢 spendcloud 都有了对应的这个解决方案，也就是说它不是一一个解决方案，是一个一套解决方案啊， 那么他针对微服务这个每一个场景中的这种问题，他呢提供了不同的这个组件呢去解决啊，那么他这中间有哪些核心组件以及这些组这些组件啊，解决的是微服务中的哪些问题？那么呢是这是这这一道面试题呢所要 啊，我们需要这个程序员能够回答出来的。那么呢，首先呢，我们来看一下呢，这个斯文格闹的中啊，这个一个调用流程中啊，就是一张很经典的一张图啊， 视频的文档我已经整理好了，并且与往期内容一起汇入放在了视频的最后面，坚持看完一定对你有帮助。那么这张图里面，我们呢能够看出来就是这个整个微服务的呃，一个整个大概的一个流程吧，首先第一步呢是我们这个微服务中啊，这个最最关键的一步 就是我们的这个服务的注册与发现，也就是说我们这个微服务了，他是服务力度了，可能划分的比较小，对吧？他其实是一个应用，一个服务啊，按照微服务的这个定义的话，实际上是一个应用，一个服务， 所以说在这整个，在我们的整个这个分布式集群中可能会存在很多很多的这个节点啊，然后每一个节点呢，可能都是一个呃，一个应用，然后这一个应用上面呢，可能只提供一个服务，当然这只是微服务的最小力度拆分啊。 那么在这种情况下面啊，那么我这么多的节点，这么多的服务，对不对？那么这些服务之间去调用的话，那么我我这个服务，比如说我又要调他啊，又要调他，还要呢？调他，那么 我是不是要在我这个服务本地去维护其他其他啊？所有节点的这个啊服务地址都必须维护在我本地，对不对？要不然的话我怎么去，怎么去调用，对不对？所以说呢，那么如果说这个节点越多的话，那么对于我们这个服务节点来说，他需要存储的这个服务节点的信息呢就越多啊，所以这个时候 就产生了一种这个服务注册与发现的一种机制啊，就是这个优乐卡，那么优乐卡呢，就是我们的每一个服务了都去向这个优乐卡了，去注册这个优乐卡呢，可以理解为它是一个中间键啊，是一个中间键， 他单独部署这个 ur 卡，单独部署，那么所有的节点呢？都来向这个啊 ur 卡来注册自己的这个服务信息，所有的节点都来向他注册， 那么当我这个节点之间要进行相互调用的时候啊，那么比如说我这个节点要调这个节点，哎，我不知道他的地址对不对？我呢也不需要把他地址存储在我的本地，而是呢去这个 ur 卡上面去找，去找这个服务的地址，找到他的地址之后呢再去进行调用，此时呢我这个节点上呢，不 需要去自己去单独维护所有节点的一个信息啊，那么这个是这个 ulo 口的这个服务注册，那么这个服务注册呢？他注册的是啊，每一个服务都往这个 ulo 中呢注册自己的这个 ip 地址端口啊，版本号，通信协议等等啊， 那么然后优乐卡呢，将这每一个服务维护在自己的一个服务清单中，也就是我们的优乐卡的服务端啊，那么它是一个中间键，它呢有服务端，有了客户端，所以说它是一个 cs 架构的，优乐卡是一个 cs 架构的一个框架啊，那么 它里边这个服务清单呢，类似一个双层卖铺啊，这个卖铺的第一层 t 是服务名，也就是我们每一个节点会定义一个，每一个服务啊，定义一个自己的一个服务名字， 那么第二层的 t 呢，是这个实力名，也就说一个服务了会有多个实力去提供服务啊，就多个实力组成这么一个服务集群啊，然后呢啊就说每一个实力都可以去提供服务，但是呢这每一个实力呢，都对应着有自己的一个 u i l 地址啊，每一个实力的这个 u i l 地址，它是不一样的，然后弯钮呢，这个弯钮 那么存储的就是这个服务的地址加端口啊，那么同时呢，这个优乐卡的这个服务端啊，他还会维持对这个服务的一个心跳，就是往往这个优乐卡上注册的这个服务啊，他会与这个优乐卡的服务端维持心跳，那么当这个心跳超过一定的这个时间阀的话，超超过了这个浴池啊，那么呢就会剔除了一些不可用的服务，就是说 这个心跳探测到你这个服务啊不在线了，那么就会将你的剔除掉啊，那么 ulogar 集群中各个节点呢，还会呢就是相互注册啊，那么不仅仅是这个提供服这个微服务啊，提供服务的这些节点往这个 ulogar 这个搜索端去注册， 那么优若考的 sewer 本身啊，它这个 sewer 本身也可以是一个集群由多个节点呢来共同提供这个服务注册的这个功能啊，那么它这些节点之间呢，也会相互去注册啊，从而达到了每一个实力中都拥有拥有啊一样的这个服务清单。但是这里要注意的是它这每一个节点啊上的这个服务清单，它其实这个讲到的就是这个一致性，对不对？ 每一个节点上的数据了保持一致，但是这里要注意啊，他不是强一致，他不是强一致啊，也就是说在我们的这个 ulogo 这个集群中啊，如果说有部分节点要是当掉的话，其他节点呢，也是能够正常提供服务的，只要我们这个集群中有一个节点存活，那么呢这个 ulogo 这个整个集群他就可以正常的对外提供服务啊， 所以说各个节点之间相互注册，他并不是并不是强制的啊，注册不了也不影响整个集群的这个可用性，所以说优乐考是保证了高可用啊，所以说他这个数据一致性并不是强一致啊，那么这个是优乐考的这个服务注册这一块啊，好，那么每一个客户端，对吧？那么也就是说我们这个每一个服务啊，都把自己的这个地址呢都注册到这个优乐考的这个 sewer 上面去， 注册完了之后呢，那么我接下来呢，就是这个，呃，服务跟服务之间的这个调用，对不对？那么服务去调用的时候，就是意味着我们这个服务发现啊，也就是说我这个服务要去调这个服务，我必须知道你的这个地址，我才能去啊，调用，对不对？那么这个就 就是这个服务发现机制啊，也就是说我要找到你的地址啊，那么怎么样去找到他的地址呢？这个 uro 注册的服务之间调用了，不需要再去了指定这个服务地址，不像我们之前啊，我们之前如果你通过这个 h t t p 去调用这个服务的话，你必须要知道这个服务的这个 u r l 对吧？以及它的这个端口地址啊，就是我们所谓的这个 ip 加端口， 必须要知道这些信息，指定 ip 端口才能够呢去调用某一个服务。那么在有了这个 ur 卡之之后啊，那么这个 ur 卡上注册的这些服务之间互相去调用的话，就不需要再指定 ip 端口了， 只需要呢通过这个服务名啊，各自去，就是你只需要啊通过这个服务名去调用指定这个服务名啊，然后呢这个 ur 卡的这个客户端呢，他会自己到这个注册中心上面去找这个 ip 跟端口， 也就说将这个 ip 跟端口这一层呢，就是我们不需要在程序中去指定啊，而是呢通过这个，呃，注册中心上面去找，找到这个地址之后呢，这个 cline 端自己呢去封装这个 ip 加端口的这个调用啊，然后呢获取所有实力的这个清单。注意了，这里有一 布，他还会了把这个整个服务的这个实力清单，就是我们前面讲的这个双层木双层麦谱啊，还会了缓存到这个本地，也就是我们这个 you are coconline 的所在的这个本地啊，然后呢实现这个服务请求的一个高可用啊，那么这个是，呃，整个 spring cloud 啊，就是 我们的微服务中啊，应该算是这个微服务。呃，最先要解决的一个问题啊，就是这个服务注册与发现啊，其实就是我们所谓的这个服务的一个治理啊，好，那么这个是 uroca， 好，那么 有了这个 ur 卡之后啊，我们的这里呢，其实还有个问题，对不对？就是我这边呢，你不是一个双层卖不吗？那么你每一个服务其实对应着有多个实力，对不对？每一个实力的这个 ul 呢？它是不一样的， 那么比如说我这边这个集群里面有很多很多的呃节点，比如说我这三个节点提供的其实是同一个服务，对不对？提供的是同一个服务，但是我的 uil 呢，是不一样的，那么这个时候，比如说我这个客户端来调用的时候，哎，我选择调用哪一个呢？对不对？那么当然呢，是调哪一个都可以啊，但是我，我 具体应该去调哪一个？所以我这三个服务的这个服务名呢，是一样的，对不对？服务名是一样的，而我调用的时候就是通过服务名去调的，那么这个服务名呢，并不能区分这三个节点中的其中一个，对不对？所以说呢，我们还要 干什么？就是要去了做这个负载均衡啊，那么就是我拿到这个服务名之后，哎，我发现了，我找到三个实力了，找到了三个实力，那么此时我怎么样去调用同时呢这三个实力呢？ 本身呢，也应该呢去做这个流量的一个啊，负载均衡，对不对？你不应该把所有的请求都往一个实力上去发啊，其他的实力也应该承担了一定的流量。那么此时呢，就是我们这个 sprinkler 中的第二大组件，这个 reaband 的一个啊，功能啊，其实也就是我们的这一块啊，那么这个 uraka 去调用的时候，通过这个 reaban 去做这个负载均衡啊， 就说实现我们这个节点之间的这个流量的一个负载啊，啊，不至于了，所有的流量都达到一个节点上面去。那么这个是 rebe 在这个 spring cloud 中啊，起到了这么一个角色啊，那么呢，它其实就是 同一台服务的啊，多台机器中去选择一台啊，然后这个 rebe 呢，但是它呢，也是通过了发起这个 s， d， d， p 请求来进行调用啊，只不过是说呢，我们去进行调用的时候呢，是通过这个服务名，而不是呢 ip 加端口，对不对？是通过服务名的方式呢去调用的，那么不需要再去写这个 ip 了，加 port， 不需要去写 ip 加端口，这样的话呢，比如说我这个服务啊，我这个服务要是，呃换了机器，对吧？我换了 ip， 换了这个端口，此时呢我也不需要再去修改代码，这是它的一个好处。但是呢，此时啊，我们的这个调用啊，每一次调用了，还是需要去手动的发起一个 s t t p 请求，对不对？相当于，比如说我这里啊，我要去调用这个 这个 example service 上面这个 index， 那么此时呢，我还是需要写这么一段代码，去调用这么一个服务，对不对？还是需要去写我每调用一个这个实力的都要写这么一行代码，对不对？所以说呢还是会比较的麻烦。那么此时呢，就出现了我们的第三个就是封装，这个调用细节的封装调用细节的这个份，这个呃， spring cloud 中的第三大主见，那么这个凤呢，它是主要是基于这个动态代理机制啊，那么我们下面再来看，呃，下面这个，嗯， 这个，呃这个代码啊，这个 demo， 那么呢它呢，主要是能够让我们调用远程呢，就像调用本地服务一样啊，你不需要再去写什么 ip 破的，也不需要去写什么服务名，以及了这个 呃调用的地址什么的啊，当然地址要写啊，但是你不需要再去指定这个服务名了啊，那么它的这个调用呢，会比上面这个 reaby 的这个调用呢，会更加的简单，我们来看一下啊，比如说我这边呢，定义了一个服务，对吧？定义了一个 user control， 把这么一个接口， 这个接口中呢啊，提供了这么一个啊，业务逻辑的实现啊，那么我这个 get mapping 上面定义的他这个接口地址是 get user， 好，那么只是我们在通过客户端去调用这个服务的时候，我们只需要在客户端定义一个 fin 啊 cline 的，然后呢写一个接口，当这个接口名，无所谓啊，最最核心的是这个 get mapping 的这个接口地址，以及了上面的这个服务名，这个 user， 那么这个 user 这个服务名指的就是我这个服务了，在这个 ur 卡上面注册的这个服务名，好，那么有了这个 funkline 的之后，那么我们再去客户端去调用的时候，那么实际上这里呢通过这个 resours， 对吧？或者是 auto well 的去注入这个接口啊，注意，我们这里呢并没有针对这个 user command 实现，对不对？并没有实现啊，那么这里只是注入了一个接口， 有点呢，像我们这个 my body 词中的，比如说这个什么 user map， 对吧？这个 map 我们在 my beddys 中这呃，写一个，写一个 user map， 对吧？就是这个 d a o 啊，我们也是呢，只需要写一个接口，对不对？ 不需要了这个真正的实线啊，就可以了，去调用这个，呃，让他的去执行这个社会语句，对不对？那么拜拜利斯啊，他之所以能有这种机制啊，可以让我们啊去注入这个接口啊，然后呢直接去调这个接口中的方法啊，其实呢主要的原理呢，也是一样的，都是动态代理，那么这个缝其实也是一样的啊，也是动态代理，那么当你做这么一个操作的时候，其实呢有了这个缝， 有了这个注解，那么呢这个缝呢，他会自动的帮我们啊去实现这个接口，相当于就是起一个代理类啊，去实现这个接口，然后呢完成具体的这个调用逻辑，说白了就是把这个 reaby 中的这行代码啊，把他的封装起来了啊，就是我们对于我们程序员来说呢啊，不需要再去写这么一行代码，然后调用呢，就非常的简单啊，直接写一个 youtube land， 然后呢直接去调就可以了啊， 好，那么啦呢，其实主要是他会基于了你这个接口地址以及你这个服务名去做这么一层封装啊，好，那么这个是凤这一这一个在我们 supreme cloud 中的一个角色，好，那么接下来呢，就是这个啊，开始 tricks， 这个开始 tricks 了，呃，他的是干什么呢？就是在我们这个微服务中起到了就是一个保护，保护我们的服务啊，就是一个服务的一个容错， 比如说我们这个服务之间有存在这么一个调用链啊，存在这么一个调用链，那么如果说此时啊这个 a 服务，如果他的这个容量很大的话啊，这他这个流量很大啊，也就说他的这个并发量超高，那么如果说这一整 条链路啊，这个 a 如果是要垮了的话，他的这个并发量很大很大，那么他整个呢，会把这个所有的这个并发量呢向后传导，对不对？把这个并发量向后面的每一个节点去传导，然后导致了我这里每一个节点这个并发量可能都会很大，对不对？然后极有可能就因为这一个接口将我整个的这个请求链路上的啊每一个微服节点全部压垮啊， 所以说这个开始确实实现呢，就是一个断路器，就是将这条链路把它给断掉啊，那么 a 要垮是没有办法的，因为呢所有的警球都是从 a 进来的，对不对？那么 a 如果垮了的话啊，不倒不至于呢，把后面的这个警球呢给压垮，同时呢我们 啊，当然呢，这整条链路上啊，呃，也有可能是后面的某一个节点呢，执行这个超时，导致这个整条这个警球了会呃占的资源会比较多，导致他一直不能释放，对不对？那么这种这种断路的话，也可以呢，起到这个保护这个 a 服务的一个效果啊，那么这个是断路器啊，好，那么这个断路器他这个实现原理其实就是我们啊，在 使用这个开始 tricks 的时候，我们一般呢都会去实现一个叫做开始 tricks 跟慢的，对不对？实现一个开始 tricks 跟慢的的一个类啊，那么在这个开始 tricks 跟慢的中，它是一个命令模式啊，一个命令模式，那么采用这种东西的话，就调用的话，那么它里边实际上是为了单独生成一个现成池啊，也就是说呢， 你的每一次接口调用走的都是不同的县城池啊，走的是不同的县城池，从而呢使这个服务之间呢，这个服务调用之间呢相互隔离，相互隔离啊，同时呢他还会呢去统计就是这个接口的一个超时次数，比如说我调这个接口一直超时，一直超时，对不对？那么达到了一定的超时次数之后，他的默认会打开这个断路器，那么你后面的这个调用直接呢 进行垄断啊，那么因因为说如果，如果你前面的接口一直超时，你后面的就是前面的这个请求一直超时，你后面的请求还是让他正常的进去的话，实际上呢，他的结果无非也是超时，对不对？但是越来越多的请求堆积在这个地方，超时的话，就极有可能的导致我 我们这个资源呢快速的被耗光啊，那么此时我们啊实现这个街头统计，对吧？统计这个超时次数，我们这个地方呢可以设置一个预值，那么统计的这个次数达到了这个预值之后，那么就可以了将这个请求了，后边的请求啊全部呢 进行拦截掉啊，那么啊来实现这个服务的垄断，达到了一定的次数，那么你再进来的话，我就不往后请求了，而是呢直接给你返回，比如说我们中间的这个什么 forback 啊， 采用这个 footback 的这种机制啊，那么直接呢给你返回一个默认值，直接给你返回一个默认值，而不是真正的去向后面请求走了，真正的这个业务逻辑 好，那么这个呢，就是其实相当于就是实现了熔断，对不对？不至于让他这个请求往后面去走，那么我们在这个 forbike 中呢，还可以去实现一些呃，比较温和的一些提示啊，因为你直接请求过来的时候，如果我直接给你熔断，对吧？不让你往后走，那么此时这个爆错呢，可能千奇百怪，那么这个对客户端呢不太友好，那么此时我们可以实现呢，在这个 forbike 中实现一些比较友 好的一些提示啊，从而就是导致了呃，就是让这个客户端得到的这个错误信息了，相对来说会比较的友好。 还有呢，就是我们还可以在这个 forback 中啊，我们可以呢去把这个请求了，把这个请求的这个参数了给他记录下来，比如说我们记到，记到一个日子中，记到一个日子中啊，或者是说我们把这个消息把这个请求了发到这个 mq 里面去啊，发到这个 mq 里面去，相当于了我的不时时响应，你， 比如说啊，本来我这个接口啊，我可以是三毫秒之内我就可以响应给你的，但是此时呢，我先呢给你返回一个，返回一个友好的提示，比如说啊，嗯， 比如说这个接口可能呢？呃，稍后，对吧？稍后，或者是说，呃，怎么讲？就是讲这个接口啊，本来是三三毫秒响应的，可能此时呢因为这个服务的压力，对吧？我们可以给他一些比较友好的提示，比如说啊，我这个请求可能需要呢，呃，三秒钟，或者是，或者是说啊五秒钟啊，才能给你了，才能给你处理完，对吧？或者是说直接告诉他 订单请求中，对吧？而不是告诉你了啊，订单已完成啊，那么直接告诉你订单处理中，然后过后我们处理完了之后，可能呢再给他的响应一条消息，对吧？此时呢能够实现这个服务的一个降级，也是这个服务的降级啊，就是说我不立刻给你做出响应，而是呢啊，这个响应时间可能会延长，但是呢我会给你一个比较温馨的一个提示，对吧？那么这个呢也是可以通过这个 pastrix 的这种垄断器去实现的 好，那么最后一个就是所谓的这个服务网关，那么这个网关呢，其实主要是针对于我们这个啊，前端调，后端啊，一般是通过前台调进来， 通过前台调进来的话，我们知道这个前台呢，比如说我们前端呢，可能是一个单独的一个应用啊，可能他的本身并没有在我们这个优若卡 server 上面去注册，对不对？那么此时他要来调我们这个优若卡中的服务的话，那么就走不了我里我们里边的这些这这这些逻辑了，对不对？ 因为我们这些逻辑必须是要求什么你这些节点呢？全部注册在 uloca server 中啊，它是必须要求是 sever 这个 uloca server 中注册的这些 节点的互相调用，对不对？我才有可能走这个日本走这个份的这个逻辑啊，以及我们的那个断路器的逻辑。但是我如果是从前端调进来的，从前端调进来的，那么此时我本身都不是这个微服务调用，对不对？本身都不是微服务调用，那么此时怎么办呢？从前端调进来的，我怎么让他也能够走这些逻辑？那么此时就通过这个服务网关，全部通过服务网关进来， 那么服务网关的本身呢，也会注册到这个优乐卡 server 上面，他也会以一个节点的方式注册在这上面，那么此时这个优乐卡跟这个优乐卡 server 上面的这个服务节点，对不对？他们就变成了一个平等的一个地位，变成一个平等的地位啊，那么此时这个网关再去调这个 server 中的这个节点，那么呢就变成了我们正常的这个微服务调用，那么这个是服务网关在这个 在我们 superink log 中起到的这么一个角色啊，当然并不是说服务网关呢，他一定是只能够用于这个前台调后台啊，我只是说这个做在这个 superink log 中起到了这么一个作用啊，那么我们真正的服务网， 其实你服务跟服务之间调用呢，也可以去走网关啊，我们 sever 调 sever， sever 调 sever 也可以走网关啊，只不过是说我们微服务内部调用，没有必要去走网关，对吧？那么只有前台调进来的时候，因为你前台不是一个 sever 节点，那么你在这个优尔卡中并没有这个注册信息， 所以呢，你是走不了我们前面讲的这些逻辑的，对不对？比如说这个 fankline， 那么你前端压根就没有这个东西，对吧？你没有这个 fankline 的，那么你压根就走不了这个缝的这个代理逻辑啊，好，那么同时呢，也就使用不了他的这些功能了吗？对不对？那么 此时啊，就是可以了走我们的这个啊，网关走服网关进来，那么网关本身呢，也是一个节点，因此呢可以实现呢，从前台往后台调的时候，也可以让他能够正常的走我们的这个微服调用的这个逻辑啊，好，那么这个以上就是这个 sprinklove 中的，那么呢几大核心组件以及他各自的一个作用及其的这个实现的一个简单的一个原理的一个讲解。