Spring Cloud架构的各个组件的原理分析.docx

我们先认识一下SpringCloud的各个组件，然后知其所以然。SPringCloud（一）Config©springSpringCloudBusSpringCk）udConfigSPnnOEVW9Afi.UfKBjuemaHiMtBftB.B<CVV*e,RXm*M.0UASub*r*0A.SpringCloudBusSpmg件.用于（伪n.肥宝化件）WMM*<.N与SPrtOeGouOConMI台实SMBV.EurekaNMxCMIftXS,一个于RESTM.RTrtt三M.UmnVH务双。Qm”.HystrixFtetftxE9WV9XA口遢注机第EM三万ImY或Mn为adIaaM供更修大WNETF1.IXo三三ZuulZuulNetnaZtM任云翠8上仅秋NM&.务住.安全边身的ZmU于0IONvmXH用的V0RMMWfl<nM11.4ArchaiusjCONSU1.PtvotelCloudFoundryArchaiusMttmxEVVVAR包含一事别配APi.供aan梨化n住.tt三w±Eian.险AMW、SflnnvwConsulHMhCorpNMTConutfH¾.COniUI一个ftXBEVXII.与OOCMr司U无鼻皮.SpringCloudforCloudFoundryPMHalAilQauth21frA三rflRQoudFAndry.GoudFcMy*VMEM出的开普PMS五E原理讲解前，先看一个最经典的业务场景，如开发一个电商网站，要实现支付订单的功能，流程如下：创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付”扣减相应的商品库存通知仓储中心，进行发货给用户的这次购物增加相应的积分如上，微服务的应用场景和核心竞争力：降低耦合：每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。容错机制：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。sefvicbreaker<bord灵活扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。mes«getxo¼ev0留出-S争Dubbo对标SpringCloud微服务：背景分析：Dubbo,是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司；SPringCknId是知名的SPring家族的产品。阿里巴巴是一个商业公司，虽然也开源了很多的顶级的项目，但从整体战略上来讲，仍然是服务于自身的业务为主。SPring专注于企业级开源框架的研发，不论是在中国还是在世界上使用都非常广泛，开发出通用、开源、稳健的开源框架就是他们的主业。活跃度对比：DUbbO是一个非常优秀的服务治理框架，并且在服务治理、灰度发布、流量分发这方面做的比SPringCloUd还好，除过当当网在基础上增加了rest支持外，已有两年多的时间几乎都没有任何更新了。在使用过程中出现问题,提交到GitHub的ISSUe也少有回复。相反SpringCloud自从发展到现在，仍然在不断的高速发展，从GitHub上提交代码的频度和发布版本的时间间隔就可以看出，现在SPringClOUd即将发布2.0版本，到了后期会更加完善和稳定。平台架构：DUbbo框架只是专注于服务之间的治理，如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成，这样无形中使用Dubbo的难度就会增加。SPringCknId几乎考虑了服务治理的方方面面，更有SPringBOOt这个大将的支持，开发起来非常的便利和简单。技术前景：DUbbo在各中小公司也从中受益不少。经过了这么多年的发展，互联网行业也是涌现了更多先进的技术和理念，Dubbo有点可惜。Spring推出SPringBOOt/Cloud也是因为自身的很多原因。SPring最初推崇的轻量级框架，随着不断的发展也越来越庞大，随着集成项目越来越多，配置文件也越来越混乱，慢慢的背离最初的理念。随着这么多年的发展，微服务、分布式链路跟踪等更多新的技术理念的出现，SPring急需一款框架来改善以前的开发模式，因此才会出现SpringBoot/Cloud项目,我们现在访问Spring官网，会发现SpringBoot和SpringCloud已经放到首页最重点突出的三个项目中的前两个，可见SPring对这两个框架的重视程度。DUbbO实现如下：SpringCloud实现思路:Eureka原理：主管服务注册与发现，也就是微服务的名称注册到EUreka,就可以通过Eureka找到微服务，而不需要修改服务调用的配置文件。分析：SPringCloUd封装了NetfliX公司开发的EUreka模块来实现服务的注册与发现，采用的C-S的设计架构，EUrekaSerVer作为服务注册功能的服务器，他是服务注册中心。而系统的其他微服务，使用Eureka的客户端连接到EurekaServer并维持心跳。这样系统的维护人员可以通过EurekaServer来监控系统中的各个微服务是否正常运行。SPringCloUd的一些其他模块（比如ZUUI）就可以通过EurekaServer来发现系统其他的微服务，并执行相关逻辑。EurekaServerEurekaServer提供服务注册服务，各个节点启动后，会在EUrekaSerVer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。EurekaClientEurekaClient是一个Java客户端，用于简化EurekaServer的交互，客户端同时也具备一个内置的、使用轮询（round-robin）负载算法的负载均衡器。在应用启动后，将会向EUrekaSeNer发送心跳（默认周期为30秒），以证明当前服务是可用状态。如果EUrekaSerVer在一定的时间（默认90秒）未收到客户端的心跳，EurekaSerVer将会从服务注册表中把这个服务节点移除。EurekaServer的自我保护机制如果在15分钟内超过85%的节点都没有正常的心跳，那么EUreka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上（即保证当前节点依然可用）当网络稳定时，当前实例新的注册信息会被同步到其它节点中因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像ZooKeeper那样使整个注册服务瘫痪。Eureka和ZooKeeper著名的CAP理论指出，一个分布式系统不可能同时满足C（一致性）、A（可用性）和P（分区容错性）。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。ZooKeeper保证CP当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是ZooKeeper会出现这样一种情况，当Master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行Ieader选举。问题在于，选举Ieader的时间太长，30120s,且选举期间整个ZoOKeePer集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得ZooKeeper集群失去Master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。Eureka保证APEUrek在设计时就优先保证可用性。EUreka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台EUreka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，EUreka还有一种自我保护机制，见上。总结EUreka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper那样使整个注册服务瘫痪。Eureka作为单纯的服务注册中心来说要比ZooKeeper更加“专业”，因为注册服务更重要的是可用性，我们可以接受短期内达不到一致性的状况。SPringCk）Ud组件架构Ribbon和Feign在微服务架构中，业务都会被拆分成一个独立的服务，服务与服务的通讯是基于HTTPRESTful的。SpringCloud有两种服务调用方式，一种是RibbOn+RestTemplate,另一种是FeignO概念基于NetflixRibbon用过轮询策略实现的一套客户端负载均衡的工具。客户端负载均衡：负载均衡Zuul网关将一个请求发送给某一个服务的应用的时候，如果一个服务启动了多个实例，就会通过Ribbon来通过一定的负载均衡策略来发送给某一一个服务实例。SPringClOUd中的RibbOn,客户端会有一个服务器地址列表，在发送请求前通过负载均衡算法(如简单轮询，随机连接等)选择一个服务器，然后进行访问。负载均衡负载均衡：用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。使用负载均衡带来的好处很明显：当集群里的1台或者多台服务器down的时候，剩余的没有down的服务器可以保证服务的继续使用；将访问压力分配到各个服务器，不会由于某一高峰时刻导致系统CPU急剧上升。负载均衡有好几种实现策略,常见的有:随机(RandOm),轮询(ROUndRobin),一致性哈希(ConsistentHash),哈希(Hash),加权(Weighted)Ribbon的默认策略是轮询RestTemplate传统情况下在JaVa代码里访问RESTful服务,一般使用APaChe的HttPClien3不过此种方法使用起来太过繁琐。Spring提供了一种简单便捷的模板类来进行操作，这就是ReStTemPlate。Feign是一个声明式http客户端。使用Feign能让编写http客户端更加简单,它的使用方法是定义一个接口，然后在上面添加注解,避免了调用目标微服务时.，需要不断的解析/封装json数据的繁琐。SPringCloud中Feign默认集成了Ribbon,并和EUreka结合，默认实现了负载均衡的效果。Ribbon和Feign的区别Feign目标使编写JavaHttp客户端变得更容易在使用Ribbon+RestTemplate时，Ribbon需要自己构建http请求，模拟http请求然后使用ReStTemPIate爱送给其他服务，步骤相当繁琐。刷用ReStTemPIate对http请求的封装处理，形成了一套模版化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处,往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign在此基础上做了进一步封装，由他来帮助我们定义和实现依赖服务接口的定义。在Feign的实现下，我们只需创建一个接口并使用注解的方式来配置它(以前是DaO接口上面标注MaPPer注解,现在是一个微服务接口上面标注一个Feign注解即可)，即可完成对服务提供方的接口绑定，简化了使用SpringCloudRibbonW,自动封装服务调用客户端的开发量。Feign集成了RibbonRibbon通过轮询实现了客户端的负载均衡，而与Ribbon不同的是，Feign是一个声明式的Web服务客户端，使得编写Web服务客户端变得非常容易，只需要创建一个接口，然后在上面添加注解，像调用本地方法一样调用它就可以，而感觉不到是调用远程方法。SpringCloud中Feign默认集成了Ribbon,并和EUreka结合，默认实现了负载均衡的效果。Ribbon和Nginx的区别服务器端负载均衡NginXNginx是客户端所有请求统一交给Nginx,由Nginx进行实现负载均衡请求转发，属于服务器端负载均衡。既请求由NginX服务器端进行转发。客户端负载均衡Ribbon,Ribbon是从Eureka注册中心服务器端上获取服务注册信息列表，缓存到本地，然后在本地实现轮询负载均衡策略。既在客户端实现负载均衡。应用场景的区别NginX适合于服务器端实现负载均衡，比如：Tomcat,RibbOn适合与在微服务中RPC远程调用实现本地服务负载均衡，比如：Dubbo.SPringCIoUd中都是采用本地负载均衡。Zuul应用场景假如当前有十几个微服务服务，订单，商品，用户等等，显然是客户端不需要和每个服务逐一打交道，这就需要有一个统一入口，它就是服务网关。APl网关所有的客户端请求通过这个网关访问后台的服务。他可以使用一定的路由配置来判断某一个UR1.由哪个服务来处理。并从Eureka获取注册的服务来转发请求。核心功能Zuul包含了对请求的路由和过滤两个最主要的功能，是各种服务的统一入口，同时还会用来提供监控、授权、安全、调度等等。路由功能：负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。过滤器功能：则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。Zuul和Eureka进行整合：将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息、,也即以后的访问微服务都是通过Zuul跳转后获得。注意：ZUUI服务最终还是会注册进EUreka,提供代理+路由+过滤三大功能。核心原理Zuul的核心是一系列的filters,其作用可以类比Servlet框架的Filter,或者AOPo过滤器之间没有直接进行通信,而是通过RequestCOnteXt（上下文）进行数据传递。Zuul的过滤器是由Groovy写成，这些过滤器文件被放在ZuulServer上的特定目录下面，Zuul会定期轮询这些目录，修改过的过滤器会动态的加载到ZUUISerVer中以便过滤请求使用。Zuul负载均衡:ZUUl拦截对应的API前缀请求做转发,转发到对应的serverld上，在Eureka服务上同一个serverld可以对应多个服务，也就是说用同一个服务节点不同的端口注册两个实例，但是serverld是一样Zuul做转发的时候会结合eureka-server起到负载均衡的效果。过滤器的种类：PRE（前置）：这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现鉴权、限流、参数校验调整等。ROUTING（路由）：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用ApacheHttpClient或NetfilxRibbon请求微服务。POST（后置）：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTPHeader、收集统计信息和指标、将响应从微服务发送给客户端、日志等。ERROR（错误）：在其他阶段发生错误时执行该过滤器。Zuul和NginxZuul虽然在性能上和Nginx没法比，但它也有它的优点。Zuul提供了认证鉴权，动态路由，监控，弹性，安全，负载均衡等边缘服务，在团队规模不大的情况下，没有专门负责路由开发时，使用ZUUl当网关是一个快速上手的好方案。Nginx和Zuul是可以配合使用的，发挥各自的优点，使用Nginx作为负载均衡实现高并发的请求转发，ZUUl用作网关。Zuul和Ribbon实现负载均衡Zuul支持Ribbon和Hystrix,也能够实现客户端的负载均衡。我们的Feign不也是实现客户端的负载均衡和Hystrix的吗？既然ZUUl已经能够实现了，那我们的Feign还有必要吗？可以这样理解：Zuul是对外暴露的唯一接口相当于路由的是controller的请求，而Ribbonhe和Fegin路由了service的请求。Zuul做最外层请求的负载均衡，而Ribbon和Fegin做的是系统内部各个微服务的service的调用的负载均衡。Hystrix介绍Hystrix是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避兔的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。Hystrix的出现就是为了解决雪崩效应。服务雪崩多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。服务熔断熔断机制是应对雪崩效应的一种微服务链路保护机制。当删除链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回''错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值,缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是HyStriXCOmmand。服务降级整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。Hystrix监控和断路器我们只需要在服务接口上添加HyStriX标签，就可以实现对这个接口的监控和断路器功能。HyStriXDaShbOard监控面板，提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。HystrixTurbine监控聚合使用Hystrix监控，我们需要打开每一个服务实例的监控信息来查看。而Turbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统查看。这样就不需要挨个打开一个个的页面一个个查看。Zuul的安全机制签名机制，为防止接口数据篡改和重复调用，增加接口参数校验机制，sig签名算法为MD5（appKey+appSecret+timestamp）,appKey是分配给客户端的ID,appSecret是分配给暑户端的密钥，timestamp为unix时间戳，请求的UR1.有效时间为15分钟。TokenWJ，用户在登录之后会返回一个access,token,客户端在访问需要登录之后才能访问的资源，需要在在Authorization头部使用Bearer模式新增token,如head（"Authorization","Bearertoken"）。Hystrix的设计原则资源隔离（线程池隔离和信号量隔离）机制：限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其它服务调用。限流机制：限流机制主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。熔断机制：当失败率达到阀值自动触发降级（如因网络故障、超时造成的失败率真高），熔断器触发的快速失败会进行快速恢复。降级机制：超时降级、资源不足时（线程或信号量）降级、运行异常降级等，降级后可以配合降级接口返回托底数据。缓存支持：提供了请求缓存、请求合并实现。通过近实时的统计/监控/报警功能，来提高故障发现的速度。通过近实时的属性和配置热修改功能，来提高故障处理和恢复的速度。Config介绍SpringCloudConfig是一个解决分布式系统的配置管理方案。微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、动态的配置管理设施是必不可少的。SpringCloud提供了ConfigServer来解决这个问题,我们每一个微服务自己带着一个application.yml上百个配置文件的管理。应用场景不方便维护，多人同时对配置文件进行修改，冲突不断，很难维护配置内容安全和权限，主要是针对线上的配置来说，一般不对开发公开，只有运维有权限所以需要将配置文件隔离，不放到项目代码里更新配置项目需要重启，每次更新配置文件都需要重启项目，很耗时。使用了配置中心后，即可实现配置实时更新congfigServer和ConfigClient结合SpringCloudBus实现配置自动刷新。原理配置文件存储在远端Git（比如GitHub,Gitee等仓库），config-server从远端Git拉取配置文件，并保存到本地Gk本地Git和COnfig-SerVer的交互是双向的，因为当远端Git无法访问时;会从本地Git获取配置文件。Config-CIient（即各个微服务），从Config-SerVer拉取配置文件。角色ConfigServer：提供配置文件的存储、以接口的形式将配置文件的内容提供出去。ConfigClient:通过接口获取数据、并依据此数据初始化自己的应用。总结如下：SpringCloudBXBWP3.prn¾CoudH>-De一C)JJS1.(MyaMitea'"8HMMWM<vm三<<*三xo*r*HcH«hi<rmrrw”EnStMQy泅"Qm(wv>kMM<IU,iM<'<<>三tt*AJM0»10.SpriHQOoudBm.FHHt3M>W.<UkorA-wwwuvfwrt11imiM!K深入理解SpringCloud核心组件与底层原理一，SPringCIoUd核心组件：EurekaNetflix尤里卡1, EUreka服务端：也称服务注册中心，同其他服务注册中心一样，支持高可用配置。如果Eureka以分配模式部署，当发生中有分片出现故障时,那么Eureka就转入自我保护模式。它允许在分片故障期间继续提供服务的发现和注册，当故障分片恢复运行时，可用中其他分片会把它们的状态再次同步回来；2, EUreka客户端：主要处理服务的注册与发现。客户端服务通过注解和参数配置的方式，嵌入在客户端应用程序的代码中，在应用程序运行时，Eureka客户端想注册中心注册自身提供同时，它也能从服务端查询当前注册的服务信息并把它们缓存到本地并替换地刷新服务状态。3, EurekaSerVer的高可用实际上就是将自己作为服务向其他注册中心注册自己，这样就可以形成各个相互注册的服务注册中心，以实现服务清单的相互同步，达到高可用效果尤里卡详解1，服务提供者A.服务注册服务提供者在启动的时候会通过发送REST请求的方式将自己注册到EurekaServer上，同时带上了自己的服务的一些元数据信息。EurekaServer接收到这个REST请求之后，将元数据信息存储在一个双层结构地图中，其中第一层的键是服务名，第二层的键是具体服务的实例名；B.服务同步两个服务提供者分别注册到了两个不同的服务注册中心上，然后，它们的信息分别被两个服务注册中心所维护。此时，由于服务注册中心之间因互相注册为服务，当服务提供者发送注册请求到一个服务注册中心时，它会调用请求转发给转化中相连的其他注册中心,从而实现注册中心之间的服务同步。通过服务同步,两个服务提供者的服务信息就可以通过两个台服务注册中心中的任意一台获取到；C.服务续约在注册完服务之后，服务提供者会维护一个心跳到持续告诉EurekaServer：“我还活着“，以防止EurekaServer的剔除任务转到服务实例从服务列表中排除出来，我们称该操作为服务续约定义服务续约任务的调用间隔时间，默认30秒eureka.instance.lease-renewal-interval-in-seconds=30#定义服务失效的时间，默认90秒eureka.instance.lease-expiration-duration-in-seconds=902,服务消费者A.获取服务当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单。为了性能考虑，EUrekaSerVer会维护一份替代的服务清单来给给客户端，同时该缓存清单会每隔30秒更新一次；缓存清单的更新时间，默认30秒eureka.client.registry-fetch-interval-seconds=30B.服务调用服务消费者在获取服务清单后，通过服务名获得更多具体提供的服务的实例名称和该实例的元数据信息。在ribbon中会交替采用交替的方式进行调用，从而实现客户端的负载均衡对于访问实例的选择，Eureka中有Region和Zone的概念，一个Region中可以包含多个ZOne,每个服务客户端需要被注册到一个ZOne中，所以每个客户端对应一个Region和一个Zone。在进行服务调用的时候，优先访问同处一个一个Zone中的服务提供方，若访问不到，就访问其他的ZOneC.服务下线当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给EurekaServer,告诉服务注册中心：“我要下线了服务端在接收到请求之后，进入服务状态置为下线（DOWN）,并把该下线事件传播出去3,服务注册中心无效剔除EurekaServer在启动的时候会创建一个定时任务，每隔一次间隔（更改为60秒）将当前清单中超时（至少为90秒）没有续约的服务剔除出去B.自我保护在服务注册中心的信息面板中出现红色警告信息：该警告就是触发了EurekaSerVer的自我保护机制。EUrekaSerVer在运行期间，会统计心跳失败的比例在15分钟之内是否超过85%,如果出现低于的情况，EurekaServer可能会导致当前的实例注册信息保护起来，让这些实例不会过期，恢复保护这些注册信息。但是，在此之后，内部实例若出现问题，那么客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的情况，所以客户端必须要有容错机制，某些可以使用请求重试，断路器等机制关闭保护机制，以确保注册中心可以将不用的实例正确剔除（本地调试可以使用，线上不推荐）eureka.server.enable-self-preservation=false二,SPringCloUd核心组件：RibbonRibbon是一个基于HTTP和TCP的客户端负载均衡器，它可以在通过客户端中配置的ribbonServer1.ist服务端列表去进行访问以达到服务均衡的作用。当Ribbon和Eureka联合使用时，Ribbon的服务实例清单RibbOnSerVer1.iSt会被DiscoveryEnabledNIWSServer1.ist改写，扩展成从Eureka注册中心中获取服务端列表。同时它也会用NlWSDiSCOVeryPing来取代IPing,并强制委托给EUreka来去定服务端是否已经启动在客户端负载均衡中，所有客户端上游都维护着自己要访问的服务端清单，而这些服务端的清单来自于服务注册中心（称为EUreka）。在客户端负载均衡中也需要心跳去维护服务端清单的健康性，只是这个步骤需要与服务注册中心配合完成。通过SpringCloudRibbon的封装，我们在微服务架构中使用客户端负载均衡初始化只需要如下两步：1，服务提供者只需要启动多个服务实例和注册到一个注册中心或多个相关联的服务注册中心2,服务消费者直接通过调用被1.OadBakmCed注解修饰过的RestTemplate来实现面向服务的接口调用三，SPringCIOUd核心组件:假装Feign的关键机制是使用了动态代理1，首先，对某个接口定义了FeignClient注解，Feign就会针对这个接口创建一个动态代理2,接着调用接口的时候，本质就是调用Feign创建的动态代理3,Feign的动态代理会根据在接口上的ReqUeStMaPPing等注解，来动态构造要请求的服务的地址4,针对这个地址，发起请求，解析响应Feign是和丝带以及EUreka紧密协作的1,首先RibbOn会从EUrekaCliem里获取到对应的服务记录，也就知道了所有的服务都部署在了其中机器上，在监听到的端口上2,然后丝带就可以使用交替的R。UndRObin算法，从中选择一台机器3,Feign就会针对这台机器，构造并发起请求四,SPringCIoUd核心组件：Hystrix在微服务架构中，存在着那么多的服务单元，如果一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的崩溃，这样的架构相较传统架构更加复杂。这样的问题，产生了断路器等类别的服务保护机制。在分布式架构中，当某个服务单元发生故障之后，通过断路器的故障监控，向调用方返回一个错误响应，而不是连续的等待。占用不释放，避免了故障在分布式系统中的蔓延。Hystrix具有服务降级，服务熔断，线程和信号隔离，请求缓存，请求合并以及服务监控等强大功能。Hystrix使用舱壁模式实现线程池的隔离，它会为每一个依赖服务创建一个独立的线程池，这样就算是某个依赖服务出现重复过高的情况，也只是该依赖服务的调用会产生影响，而不会拖慢其他的依赖服务五，SPringCloUd核心组件：ZuulSpringCloudZuul通过与SpringCloudEureka进行整合，将自身注册为Eureka服务治理下的应用，同时从Eureka中获得了所有其他微服务的实例信息。对于路由规则的维护，Zuul替代通过以服务名作为COnteXtPath的方式来创建路由映射。Zuul提供了一套过滤器机制，可以支持在API网关无附上进行统一调用来对微服务接口做初始过滤，已实现对微服务接口的拦截和校正。六，总结Eureka：各个服务启动时，EurekaClient都会将服务注册到EurekaServer,并且EUrekaClient还可以反过来从EUrekaSerVer拉取到，从而知道其他服务在哪里；功能区：服务间发起请求的时候，基于丝带做负载均衡，从一个服务的多台机器中选择一台；Feign：基于Feign的动态代理机制，根据注解和选择的机器，分割请求UR1.地址，发起请求；Hystrix:发起请求是通过HyStriX的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题；Zuul:如果前端，移动端要调用约会系统，统一从ZUUl网关进入，由ZUUI网关转发请求给对应的服务。