如何使用Spring Cloud
作者：何明璐链接：/question/29483490/answer/98237582来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。首先是不建议采用XA两阶段提交方式去处理分布式事务，要知道要能够支持XA分布式事务，必须是要实现XA规范才可以，而Service本身是无状态的，如果这样去做了等于是把Service内部的东西暴露了出去。对于分布式事务最好的方式还是事务补偿或者BASE基于消息的最终一致性。可以设想一个最简单的分布式事务场景，对于跨银行的转账操作，该操作涉及到调用两个异地的Service服务，一个是本地提供的取款服务，一个是目标银行提供的存款服务，该两个服务本身无状态且独立，构成一个完整的事务。对于事务的处理初步分析:事务补偿机制事务补偿即在事务链中的任何一个正向事务操作，都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链，则必须事务链中的每一个业务服务或操作都有对应的可逆服务。对于Service服务本身无状态，也不容易实现前面讨论过的通过DTC或XA机制实现的跨应用和资源的事务管理，建立跨资源的事务上下文。因此也较难以实现真正的预提交和正式提交的分离。在这种情况下以上面例子来说，首先调用取款服务，完全调用成功并返回，数据已经持久化。然后调用异地的存款服务，如果也调用成功，则本身无任何问题。如果调用失败，则需要调用本地注册的逆向服务（本地存款服务），如果本地存款服务调用失败，则必须考虑重试，如果约定重试次数仍然不成功，则必须log到完整的不一致信息。也可以是将本地存款服务作为消息发送到消息中间件，由消息中间件接管后续操作。在上面方式中可以看到需要手工编写大量的代码来处理以保证事务的完整性，我们可以考虑实现一个通用的事务管理器，实现事务链和事务上下文的管理。对于事务链上的任何一个服务正向和逆向操作均在事务管理和协同器上注册，由事务管理器接管所有的事务补偿和回滚操作。基于消息的最终一致性在这里首先要回答的是我们需要时实时一致性还是最终一致性的问题，如果需要的是最终一致性，那么BASE策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现了两个服务的真正解耦，解耦的关键就是异步消息和消息持久化机制。还是以上面的例子来看。对于转账操作，原有的两个服务调用变化为第一步调用本地的取款服务，第二步发送异地取款的异步消息到消息中间件。如果第二步在本地，则保证事务的完整性基本无任何问题，即本身就是本地事务的管理机制。只要两个操作都成功即可以返回客户成功。由于解耦，我们看到客户得到成功返回的时候，如果是上面一种情况则异地卡马上就能查询账户存款增加。而第二种情况则不一定，因为本身是一种异步处理机制。消息中间件得到消息后会去对消息解析，然后调用异地银行提供的存款服务进行存款，如果服务调用失败则进行重试。异地银行存款操作不应该长久地出现异常而无法使用，因此一旦发现异常我们可以迅速的解决，消息中间件中异常服务自然会进行重试以保证事务的最终一致性。这种方式假设问题一定可以解决，在不到万不得已的情况下本地的取款服务一般不进行可逆操作。在本地取款到异地存款两个服务调用之间，会存在一个真空期，这段时间相关现金不在任何一个账户，而只是在一个事务的中间状态，但是客户并不关心这个，只要在约定的时间保证事务最终的一致性即可。关于等幂操作的问题重复调用多次产生的业务结果与调用一次产生的业务结果相同，简单点讲所有提供的业务服务，不管是正向还是逆向的业务服务，都必须要支持重试。因为服务调用失败这种异常必须考虑到，不能因为服务的多次调用而导致业务数据的累计增加或减少。关于是否可以补偿的问题在这里我们谈的是多个跨系统的业务服务组合成一个分布式事务，因此在对事务进行补偿的时候必须要考虑客户需要的是否一定是最终一致性。客户对中间阶段出现的不一致的承受度是如何的。在上面的例子来看，如果采用事务补偿机制，基本可以是做到准实时的补偿，不会有太大的影响。而如果采用基于消息的最终一致性方式，则可能整个周期比较长，需要较长的时间才能给得到最终的一致性。比如周六转款，客户可能下周一才得到通知转账不成功而进行了回退，那么就必须要考虑客户是否能给忍受。其次对于前面讨论，如果真正需要的是实时的一致性，那么即使采用事务补偿机制，也无法达到实时的一致性。即很可能在两个业务服务调用中间，客户前台业务操作对持久化的数据进行了其它额外的操作。在这种模式下，我们不得不考虑需要在数据库表增加业务状态锁的问题，即整个事务没有完整提交并成功前，第一个业务服务调用虽然持久化在数据库，但是仍然是一个中间状态，需要通过业务锁来标记，控制相关的业务操作和行为。但是在这种模式下无疑增加了整个分布式业务系统的复杂度。
关于Spring Cloud Alibaba，看这篇文章就够了！（附教程资料）
首先我们需要了解一下Spring Cloud，然后再来了解Spring Cloud Alibaba；
源自官方描述：
Spring Cloud为开发人员提供了一些工具用来快速构建分布式系统中的一些常见模式和解决一些常见问题（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、群集状态）。分布式系统的协调导致了很多样板式的代码（很多固定套路的代码），使用Spring Cloud开发人员可以快速建立实现这些模式的服务和应用程序。它们在任何分布式环境中都能很好地运行，包括开发人员自己的笔记本电脑、裸机数据中心和云计算等托管平台；
Spring Cloud为分布式系统开发的典型应用场景提供良好的开箱即用的功能:
Spring Cloud Alibaba是Spring Cloud下的一个子项目，Spring Cloud Alibaba为分布式应用程序开发提供了一站式解决方案，它包含开发分布式应用程序所需的所有组件，使您可以轻松地使用Spring Cloud开发应用程序，使用Spring Cloud Alibaba，您只需要添加一些注解和少量配置即可将Spring Cloud应用程序连接到Alibaba的分布式解决方案，并使用Alibaba中间件构建分布式应用程序系统；
Spring Cloud Alibaba 是阿里巴巴开源中间件跟 Spring Cloud 体系的融合:
动力节点的Spring Cloud Alibaba学习教程，将带你深入掌握基于Spring Cloud Alibaba技术栈的微服务开发技术，包括nacos、sentinel、seata、gateway、skywalking等，培养独立进行企业微服务项目架构的能力;
Spring Cloud Alibaba视频教程
Spring Cloud Alibaba资料下载
•001.视频导读
•002.Spring家族产品梳理
•003.What is Spring-Cloud-Alibaba？
•004.Nacos运行环境部署
•005.向Nacos注册中心注册服务
•006.从Nacos发现服务并负载均衡调用
•007.从Nacos发现服务并负载均衡调用
•008.Nacos客户端信息缓存
•009.Nacos客户端信息缓存
•010.Nacos Config配置中心启动读取外部配置
•011.Nacos Config配置中心自动刷新
•012.Nacos Config配置中心yaml配置
•013.Nacos Config配置中心多环境配置
•014.问答交流
•015.内容回顾-配置中心数据模型
•016.配置中心三层结构数据配置隔离
•017.配置中心三层结构数据配置隔离
•018.配置版本回滚-服务注册分组
•019.Nacos管控台用户权限管理
•020.Nacos数据持久化
•021.Nacos数据持久化
•022.Nacos集群环境部署
•023.Nacos集群环境测试
•024.Nacos集群统一入口Nginx
•025.快速回顾
•026.RestTemplate无参数Get调用返回String
•027.RestTemplate无参数Get调用返回User
•028.RestTemplate有参数Get调用返回User
•029.RestTemplate有参数Get调用返回User
•030.RestTemplate有参数Post调用返回User
•031.RestTemplate有参数Post调用返回User
•032.RestTemplate传输User对象参数Post调用返回User
•033.RestTemplate传输JSON参数Post调用返回User
•034.RestTemplate有参数Put调用
•035.RestTemplate有参数Delete调用
•036.RestTemplate方法调用梳理总结
•037.RestTemplate结合Ribbon实现负载均衡
•038.RestTemplate结合Ribbon实现负载均衡
•039.Ribbon负载均衡实现策略
•040.自定义Ribbon负载均衡实现策略
•041.更改Ribbon负载均衡实现策略
•042.Ribbon的核心接口组成
•043.Ribbon负载均衡策略个性化配置
•044.Ribbon结合Nacos实现权重负载均衡策略
•045.Ribbon结合Nacos负载均衡策优先调用同名集群
•046.Ribbon结合Nacos基于版本负载均衡策略
•047.Ribbon结合Nacos基于命名空间负载均衡策略
•048.What is Feign？
•049.Spring Cloud Alibaba基于Feign的远程调用
•050.Spring Cloud Alibaba基于Feign+Ribbon负载均衡远程调用
•051.Spring Cloud Alibaba基于Feign的相关配置
•052.脱离Ribbon的Feign的远程调用
•054.微服务的级联故障服务雪崩
•055.Spring Cloud Alibaba集成Sentinel
•056.Spring Cloud Alibaba基于Sentinel管理后台数据测试
•057.Spring Cloud Alibaba基于Sentinel实现限流
•058.Spring Cloud Alibaba基于Sentinel实现限流自定义返回结果
•059.Spring Cloud Alibaba基于Sentinel实现限流自定义跳转页面
•060.Spring Cloud Alibaba基于Sentinel线程数限流
•061.Spring Cloud Alibaba基于Sentinel资源关联限流
•062.Spring Cloud Alibaba基于Sentinel流控规则和流控效果
•063.问答交流
•064.快速回顾和演示环境预备
•065.Spring Cloud Alibaba Sentinel 服务降级RT
•066.Spring Cloud Alibaba Sentinel 服务降级异常比例和异常数
•067.Spring Cloud Alibaba Sentinel 热点参数规则
•068.Spring Cloud Alibaba Sentinel 热点参数规则小细节
•069.Spring Cloud Alibaba Sentinel 系统保护规则
•070.Spring Cloud Alibaba Sentinel 授权规则
•071.Spring Cloud Alibaba Sentinel Dashboard控制台通信原理
•072.Spring Cloud Alibaba Sentinel 对Controller请求url埋点
•073.Spring Cloud Alibaba Sentinel 手写代码实现埋点
•074.Spring Cloud Alibaba Sentinel 采用注解实现埋点
•075.Spring Cloud Alibaba Sentinel 对RestTemplate流控和熔断
•076.Spring Cloud Alibaba Sentinel 对Feign流控和熔断
•077.问答交流
•078.Sentinel规则持久化-拉模式持久化到本地文件
•079.Sentinel规则持久化-拉模式持久化到本地文件
•080.Sentinel规则持久化-推模式持久化到Nacos
•081.Sentinel规则持久化-推模式持久化到Nacos
•082.Spring Cloud Gateway 网关功能特性
•083.Spring Cloud Gateway 网关搭建
•084.Spring Cloud Gateway 网关服务调用
•085.Spring Cloud Gateway 网关谓词
•086.Spring Cloud Gateway 网关谓词
•087.Spring Cloud Gateway 网关谓词
•088.Spring Cloud Gateway 网关过滤器
•089.Spring Cloud Gateway 问答交流
•090.Spring Cloud Gateway自定义谓词
•091.Spring Cloud Gateway自定义谓词
•092.Spring Cloud Gateway自定义谓词不匹配404页面
•093.Spring Cloud Gateway自定义过滤器
•094.Spring Cloud Gateway全局过滤器
•095.Spring Cloud Gateway自定义全局过滤器
•096.Spring Cloud Gateway集成Ribbon实现负载均衡
•097.Spring Cloud Gateway集成Sentinel限流
•098.Spring Cloud Gateway集成Sentinel限流自定义错误页
•099.Spring Cloud Gateway集成Sentinel规则持久化到文件
•100.Spring Cloud Gateway集成Sentinel规则持久化到Nacos
•101.Spring Cloud Gateway内部执行流程源码分析
•102.Spring Cloud Gateway小结
•103.快速回顾
•104.Spring Cloud Gateway跨域CORS请求
•105.Spring Cloud Gateway跨域CORS请求
•106.What is SkyWalking？
•107.Skywalking运行环境部署
•108.SkyWalking Agent对微服务的链路追踪
•109.SkyWalking Agent对微服务链路追踪
•110.SkyWalking Agent加入IDEA中对微服务链路追踪
•111.SkyWalking 监控告警通知
•112.SkyWalking 监控告警通知
•113.SkyWalking 微服务链路追踪数据持久化MySQL
•114.SkyWalking 问答交流
•115.Skywalking持久化跟踪数据elasticsearch
•116.Skywalking持久化跟踪数据elasticsearch
•117.Skywalking对多个跨服务的链路跟踪
•118.Skywalking对多个跨服务的链路跟踪
•119.Skywalking自定义链路跟踪
•120.Skywalking集成logback输出traceId日志
•121.Skywalking UI界面-仪表盘
•122.Skywalking UI界面-拓扑图-追踪-性能剖析-告警
•123.Skywalking 基于nacos集群
•124.Skywalking 基于nacos集群
•125.Skywalking 基于nacos集群
•126.Skywalking 问答交流
•127.What is Seata？
•128.Seata分布式事务生命周期
•129.Seata TC Server运行环境部署
•130.Seata基于AT事务模式单体应用多数据源分布式事务
•131.Seata基于AT事务模式单体应用多数据源分布式事务
•132.Seata基于AT事务模式单体应用多数据源分布式事务
•133.Seata基于AT事务模式多个微服务分布式事务
•134.Seata基于AT事务模式多个微服务分布式事务
•135.Seata基于AT事务模式多个微服务分布式事务
•136.Seata基于AT事务模式执行机制
•137.Seata AT事务模式
•138.Seata AT事务模式写数据隔离
•139.Seata AT事务模式写数据隔离
•140.Seata AT事务模式读数据隔离
•141.Seata AT事务模式读数据隔离
•142.Seata TC Server集群环境部署
•143.Seata TC Server集群环境部署
•144.Seata TC Server集群环境集成测试
•145.Seata TC Server集群环境集成测试
•146.Seata TCC事务模式的运行机制
•147.Seata TCC事务模式SpringBoot单体应用案例
•148.Seata TCC事务模式SpringBoot单体应用案例
•149.Seata TCC事务模式SpringCloudAlibab微服务应用案例
•150.Seata TCC事务模式SpringCloudAlibab微服务应用案例
•151.What is Spring Cloud Stream
•152.Spring Cloud Stream的核心概念
•153.Spring Cloud Stream集成RocketMQ配置
•154.Spring Cloud Stream集成RocketMQ发送消息
•155.Spring Cloud Stream集成RocketMQ接收消息
•156.Spring Cloud Stream集成RocketMQ监听接收消息
•157.Spring Cloud Stream集成RocketMQ多种发送消息方式
•158.Spring Cloud Stream Starter代码分析
•159.Spring Cloud Stream集成RocketMQ发送事务消息
•160.Spring Cloud Stream集成RocketMQ对象标签消息
•161.Spring Cloud Stream问答交流
生产级基于SpringCloud微服务架构性能优化实战，建议收藏
本文将从 Tomcat性能优化，SpringCloud开启重试机制，Zuul网关性能参数优化，Ribbon性能参数优化，Feign与Hystrix性能优化等 五个方面分享在生产环境如何做好SpringCloud性能优化。
一般基于SpringCloud的微服务能够脱离传统的tomcat，独立跑起来，SpringBoot功不可没，其原理是SpringBoot内嵌了tomcat（当然可以换成其他servlet容器，如jetty），能够以java -jar形式就能跑起来。
所以针对每个springboot服务，我们需要对tomcat的一些参数进行优化，以下是楼主项目组优化的tomcat参数配置，供大家参考。
tomcat参数说明：
maxThreads，acceptCount参数应用场景
场景一
场景二
场景三
maxThreads调优
一般说服务器性能要从两个方面说起：
1、cpu计算型指标
2、io密集型指标
所以大部分情况下，tomcat处理io型请求比较多，比如常见的连数据库查询数据进行接口调用。
另外，要考虑tomcat的并发请求量大的情况下，对于服务器系统参数优化，如虚拟机内存设置和linux的open file限制。
maxThreads设置多大合适？
我们知道线程过多，会导致cpu在线程切换时消耗的时间随着线程数量的增加越来越大；线程太少，服务器的请求响应吞吐量会急剧下降，所以maxThreads的配置绝对不是越大越好。
实际情况是设置maxThreads大小没有最优解，要根据具体的服务器配置，实际的应用场景不断的调整和优化。
acceptCount设置多大合适？
尽量与maxThreads的大小保持一致 ， 这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。
当使用URL进行路由时，则需要对zuul.host.connect-timeout-millis和zuul.host.socket-timeout-millis参数控制超时时间。
请求连接的超时时间
请求处理的超时时间
对所有操作请求都进行重试
对当前实例的重试次数，针对同一个服务实例，最大重试次数（不包括首次调用）
对下个实例的重试次数，针同其它的服务实例，最大重试次数（不包括首次server）
注意Hystrix断路器的超时时间需要大于ribbon的超时时间，不然不会触发重试
Feign和Ribbon在整合了Hystrix后，首次调用失败的问题？
目前楼主的强烈做法是： 禁用Hystrix的超时时间，设为false
还有一种是官方提倡的是 设置超时时间。
在实际的项目中亲测，这种方式也有不好的地方， 如请求时间超过5s会出现请求数据时有时无的情况 ，给用户的感觉是 系统不稳定，要求整改 。
另外，禁用hystrix，官方不推荐 。
hystrix超时设置原则
问题：一个http请求，如果feign和ribbon都配置了重试机制，异常情况下一共会请求多少次？
请求总次数 n 为feignClient和ribbon配置参数的笛卡尔积：
n(请求总次数) = feign(默认5次) * (MaxAutoRetries+1) * (MaxAutoRetriesNextServer+1)
其中+1是代表ribbon本身默认的请求。
其实二者的重试机制相互独立，并无联系。但是因为用了feign肯定会用到ribbon，所以feign的重试机制相对来说比较鸡肋，一般会关闭该功能。ribbon的重试机制默认配置为0，也就是默认是去除重试机制的，建议不要修改。
SpringCloud系列-2Ribbon简介与应用
负载均衡：建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡说白了其实就是伴随着微服务架构的诞生的产物；过去的单体架构，前端页面发起请求，然后后台接收请求直接处理，这个时候不存在什么负载均衡；但是随着单体架构向微服务架构的演变，每个后台服务可能会部署在多台服务器上面，这个时候页面请求进来，到底该由哪台服务器进行处理呢？所以得有一个选择，而这个过程就是负载均衡；同时选择的方案有很多种，例如随机挑选一台或者一台一台轮着来，这就是负载均衡算法。
也可以通过例子来帮助自己记忆，就好比古代皇帝翻牌子，最开始皇帝只有一个妃子，那不存在翻牌子这回事，再怎么翻也只能是这一个妃子侍寝。但是随着妃子多了，就得有选择了，不能同时让所有妃子一起侍寝。
工作原理图如下：
HTTP重定向服务器是一台普通的应用服务器，其唯一个功能就是根据用户的HTTP请求计算出一台真实的服务器地址，并将该服务器地址写入HTTP重定向响应中返回给用户浏览器。用户浏览器在获取到响应之后，根据返回的信息，重新发送一个请求到真实的服务器上。DNS服务器解析到IP地址为192.168.8.74，即HTTP重定向服务器的IP地址。重定向服务器计根据某种负载均衡算法算出真实的服务器地址为192.168.8.77并返回给用户浏览器，用户浏览器得到返回后重新对192.168.8.77发起了请求，最后完成访问。
这种负载均衡方案的优点是比较简单，缺点是浏览器需要两次请求服务器才能完成一次访问，性能较差；同时，重定向服务器本身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；因此实践中很少使用这种负载均衡方案来部署。
DNS（Domain Name System）是因特网的一项服务，它作为域名和IP地址相互映射的一个分布式数据库，能够使人更方便的访问互联网。人们在通过浏览器访问网站时只需要记住网站的域名即可，而不需要记住那些不太容易理解的IP地址。在DNS系统中有一个比较重要的的资源类型叫做主机记录也称为A记录，A记录是用于名称解析的重要记录，它将特定的主机名映射到对应主机的IP地址上。如果你有一个自己的域名，那么要想别人能访问到你的网站，你需要到特定的DNS解析服务商的服务器上填写A记录，过一段时间后，别人就能通过你的域名访问你的网站了。DNS除了能解析域名之外还具有负载均衡的功能，下面是利用DNS工作原理处理负载均衡的工作原理图：
由上图可以看出，在DNS服务器中应该配置了多个A记录，如：
IN A 192.168.8.75;
IN A 192.168.8.76;
IN A 192.168.8.77;
因此，每次域名解析请求都会根据对应的负载均衡算法计算出一个不同的IP地址并返回，这样A记录中配置多个服务器就可以构成一个集群，并可以实现负载均衡。上图中，用户请求，DNS根据A记录和负载均衡算法计算得到一个IP地址192.168.8.77，并返回给浏览器，浏览器根据该IP地址，访问真实的物理服务器192.168.8.77。所有这些操作对用户来说都是透明的，用户可能只知道这个域名。
DNS域名解析负载均衡有如下优点：
同时，DNS域名解析也存在如下缺点：
请求过程：
用户发来的请求都首先要经过反向代理服务器，服务器根据用户的请求要么直接将结果返回给用户，要么将请求交给后端服务器处理，再返回给用户。
反向代理负载均衡
优点：
缺点：
代码实现
由于不同的服务器配置不同，因此它们处理请求的能力也不同，给配置高的服务器配置相对较高的权重，让其处理更多的请求，给配置较低的机器配置较低的权重减轻期负载压力。加权轮询可以较好地解决这个问题。
1.思路
根据权重的大小让其获得相应被轮询到的机会。
可以根据权重我们在内存中创建一个这样的数组{s1,s2,s2,s3,s3,s3}，然后再按照轮询的方式选择相应的服务器。
2.缺点：请求被分配到三台服务器上机会不够平滑。前3次请求都不会落在server3上。
Nginx实现了一种平滑的加权轮询算法，可以将请求平滑（均匀）的分配到各个节点上。
代码实现
代码实现
思路：这里我们是利用区间的思想，通过一个小于在此区间范围内的一个随机数，选中对应的区间（服务器），区间越大被选中的概率就越大。
已知：
s1：[0,1] s2：(1,3] s3 （3,6]
代码实现
代码实现
REST（Representational State Transfer）表象化状态转变（表述性状态转变），基于HTTP、URI、XML、JSON等标准和协议，支持轻量级、跨平台、跨语言的架构设计。是Web服务的一种新的架构风格（一种思想）。
符合上述REST原则的架构方式称为RESTful
在Restful之前的操作：
GET 根据用户id查询用户数据
POST 新增用户
POST 修改用户信息
GET/POST 删除用户信息
RESTful用法：
GET 根据用户id查询用户数据
POST 新增用户
PUT 修改用户信息
DELETE 删除用户信息
之前的操作是没有问题的,大神认为是有问题的,有什么问题呢?你每次请求的接口或者地址,都在做描述,例如查询的时候用了query,新增的时候用了save,其实完全没有这个必要,我使用了get请求,就是查询.使用post请求,就是新增的请求,我的意图很明显,完全没有必要做描述,这就是为什么有了restful.
幂等性：对同一REST接口的多次访问，得到的资源状态是相同的。
安全性：对该REST接口访问，不会使用服务器端资源的状态发生改变。
SpringMVC原生态的支持了REST风格的架构设计
所涉及到的注解:
---@RequestMapping
---@PathVariable
---@ResponseBody
传统情况下在java代码里访问restful服务，一般使用Apache的HttpClient。不过此种方法使用起来太过繁琐。spring提供了一种简单便捷的模板类来进行操作，这就是RestTemplate。
定义一个简单的restful接口
使用RestTemplate访问该服务
从这个例子可以看出，使用restTemplate访问restful接口非常的 简单粗暴无脑 。(url, requestMap, ResponseBean.class)这三个参数分别代表 请求地址、请求参数、HTTP响应转换被转换成的对象类型。
RestTemplate方法的名称遵循命名约定，第一部分指出正在调用什么HTTP方法，第二部分指示返回的内容。本例中调用了restTemplate.postForObject方法，post指调用了HTTP的post方法，Object指将HTTP响应转换为您选择的 对象类型 。
RestTemplate定义了36个与REST资源交互的方法，其中的大多数都对应于HTTP的方法。其实，这里面只有11个独立的方法，其中有十个有三种重载形式，而第十一个则重载了六次，这样一共形成了36个方法。
实际上,由于Post 操作的非幂等性,它几乎可以代替其他的CRUD操作.
目前主流的负载方案分为以下两种：
Ribbon 是一个基于 HTTP和TCP的客户端负载均衡工具。通过 Spring Cloud 的封装，可以让我们轻松地将面向服务的 REST 模版请求自动转换成客户端负载均衡的服务调用。
Spring Cloud Ribbon 虽然只是一个工具类框架，它不像服务注册中心、配置中心、API 网关那样需要独立部署，但是它几乎存在于每一个 Spring Cloud 构建的微服务和基础设施中。因为微服务间的调用，API 网关的请求转发等内容，实际上都是通过 Ribbon 来实现的（）。
Ribbon主要提供：
Ribbon模块介绍：
与Nginx的对比
应用场景的区别：
1.先创建两个服务，用于负载均衡
Server 1 和Server2 的端口号要不同，不然起不来
Server 1接口如下：
Server 2接口如下：
启动类都是一样的，如下：
2.创建一个调用方来请求这个接口
引依赖包
配置启动类，并注入 RestTemplate
配置一下 application.properties,如下：
3.验证
再创建一个 测试方法来验证是否生效，放在test 目录下面，代码如下：
先启动 两个server ,然后在 测试 测试类 ，结果如下：
从结果可以看出实现了负载均衡，默认是 轮询策略，Client1和 clien2 依次调用。
Ribbon 中有两种和时间相关的设置，分别是请求连接的超时时间和请求处理的超时时间，设置规则如下：
Ribbon可以通过下面的配置项，来限制httpclient连接池的最大连接数量、以及针对不同host的最大连接数量。
负载均衡的核心，是通过负载均衡算法来实现对目标服务请求的分发。Ribbion中默认提供了7种负载均衡算法：
验证方法：
1.在BaseLoadBalancer.chooseServer()方法中加断点
2.在RandomRule.choose()方法增加断点，观察请求是否进入。
自定义负载均衡的实现主要分几个步骤：
ILoadBalancer 接口实现类做了以下的一些事情：
修改application.properties文件
在ribbon负载均衡器中，提供了ping机制，每隔一段时间，就会去ping服务器，由 com.netflix.loadbalancer.IPing 接口去实现。
单独使用ribbon，不会激活ping机制，默认采用DummyPing（在RibbonClientConfiguration中实例化），isAlive()方法直接返回true。
ribbon和eureka集成，默认采用NIWSDiscoveryPing（在EurekaRibbonClientConfiguration中实例化的），只有服务器列表的实例状态为up的时候才会为Alive。
IPing中默认内置了一些实现方法如下。
在网络通信中，有可能会存在由网络问题或者目标服务异常导致通信失败，这种情况下我们一般会做容错设计，也就是再次发起请求进行重试。
Ribbon提供了一种重试的负载策略：RetryRule，可以通过下面这个配置项来实现
由于在单独使用Ribbon的机制下，并没有开启Ping机制，所以所有服务默认是认为正常的，则这里并不会发起重试。如果需要演示重试机制，需要增加PING的判断。
1.引入依赖包
2.创建一个心跳检查的类
3.修改mall-portal中application.properties文件，添加自定义心跳检查实现，以及心跳检查间隔时间。
4.在goods-service这个模块中，增加一个心跳检查的接口
5.测试服务启动+停止，对于请求的影响变化。
LoadBalancer 是Spring Cloud自研的组件，支持WebFlux。
由于Ribbon停止更新进入维护状态，所以Spring Cloud不得不研发一套新的Loadbalancer机制进行替代。
1.引入Loadbalancer相关jar包
2.定义一个配置类，这个配置类通过硬编码的方式写死了goods-service这个服务的实例列表，代码如下
3.创建一个配置类，注入一个LoadBalancerClient
4.修改测试类
5.为了更好的看到效果，修改goods-service模块，打印每个服务的端口号码。