spring cloud 服务调用方式为什么使用http restful 而不是RPC
REST是一种架构风格，其核心是面向资源，REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。REST提出设计概念和准则为：1.网络上的所有事物都可以被抽象为资源(resource)2.每一个资源都有唯一的资源标识(resourceidentifier)，对资源的操作不会改变这些标识3.所有的操作都是无状态的REST简化开发，其架构遵循CRUD原则，该原则告诉我们对于资源(包括网络资源)只需要四种行为：创建，获取，更新和删除就可以完成相关的操作和处理。您可以通过统一资源标识符（UniversalResourceIdentifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过HTTP规范定义的。其核心操作只有GET,PUT,POST,DELETE。由于REST强制所有的操作都必须是stateless的，这就没有上下文的约束，如果做分布式，集群都不需要考虑上下文和会话保持的问题。极大的提高系统的可伸缩性。对于SOAPWebservice和RestfulWebservice的选择问题，首先需要理解就是SOAP偏向于面向活动，有严格的规范和标准，包括安全，事务等各个方面的内容，同时SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。而REST强调面向资源，只要我们要操作的对象可以抽象为资源即可以使用REST架构风格。RESTful应用问题是否使用REST就需要考虑资源本身的抽象和识别是否困难，如果本身就是简单的类似增删改查的业务操作，那么抽象资源就比较容易，而对于复杂的业务活动抽象资源并不是一个简单的事情。比如校验用户等级，转账，事务处理等，这些往往并不容易简单的抽象为资源。其次如果有严格的规范和标准定义要求，而且前期规范标准需要指导多个业务系统集成和开发的时候，SOAP风格由于有清晰的规范标准定义是明显有优势的。我们可以在开始和实现之前就严格定义相关的接口方法和接口传输数据。简单数据操作，无事务处理，开发和调用简单这些是使用REST架构风格的优势。而对于较为复杂的面向活动的服务，如果我们还是使用REST，很多时候都是仍然是传统的面向活动的思想通过转换工具再转换得到REST服务，这种使用方式是没有意义的。效率和易用性SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。REST被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。同时，在我看来REST还有一个很吸引开发者的就是能够很好的融合当前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml作为数据承载，还有（JSON,RSS,ATOM）等形式，这对很多网站前端开发人员来说就能够很好的mashup各种资源信息安全性技术没有好坏，只有是不是合适，一种好的技术和思想被误用了，那么就会得到反效果。REST和SOAP各自都有自己的优点，同时如果在一些场景下如果去改造REST，其实就会走向SOAP（例如安全）。REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。同时很重要一点就是不要扭曲了REST现在很多网站都跟风去开发REST风格的接口，其实都是在学其形，不知其心，最后弄得不伦不类，性能上不去，安全又保证不了。成熟度SOAP虽然发展到现在已经脱离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的webservice都能够较好的互通。由于没有类似于SOAP的权威性协议作为规范，REST实现的各种协议仅仅只能算是私有协议，当然需要遵循REST的思想，但是这样细节方面有太多没有约束的地方。REST日后的发展所走向规范也会直接影响到这部分的设计是否能够有很好的生命力。
SpringCloud入门搭建及服务调用
开发工具：idea 2020.2.3
java：1.8
maven：3.3.9
SpringBoot：2.1.3.RELEASE
SpringCloud：Greenwich.SR5 （版本和SpringBoot必须对应，对应表自行百度）
idea配置我就不细说了
然后next
finish
然后配置pom.xml:
一般在父项目配置
然后配置依赖，这里只是一个springboot项目，所以配一个springboot就行了：
然后配置pom.xml,它们俩都是独立的springboot项目了，这里也可以和父类工程做依赖继承，但是这里就没必要，更凸显服务的独立性：
controller：
power启动类：
UserController.java
在这里调用另一个服务power服务的接口，可以使用reatTeplate来实现，需要配置
reaTeplate配置文件：AppConfig.java
user服务启动类：
user服务的 application.yml
同样可以以相同方式在power服务中调用user的接口
然后在浏览器：
127.0.0.1:6060/power/getPower.do（6060是power服务的端口）
127.0.0.1:7070/user/getUser.do调用自己的接口（7070是user服务的端口）
127.0.0.1:7070/user/getPower.do调用power的接口
至此实现了不同服务之间的调用
Spring Cloud调用接口过程
Feign -----Hystrix —Ribbon —Http Client（apache http components 或者 Okhttp） 具体交互流程上
Hystrix 是一个供分布式系统使用，提供 延迟 和 容错 功能，保证复杂的分布系统在面临不可避免的失败时，仍能有其弹性。
比如系统中有很多服务，当某些服务不稳定的时候，使用这些服务的用户线程将会阻塞，如果没有隔离机制，系统随时就有可能会挂掉，从而带来很大的风险。SpringCloud使用 Hystrix组件提供断路器、资源隔离与自我修复功能 。下图表示服务B触发了断路器，阻止了级联失败
Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统中，许多依赖不可避免的会调用失败，超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，提高分布式系统的弹性
熔断机制是应对雪崩效应的一种微服务链路保户机制，当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的相应信息。当检测当该节点微服务调用响应正常后恢复调用链路，熔断机制的注解是@HystrixCommand
“熔断器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控，，某个异常条件被触发，直接熔断整个服务。，向调用方法返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出吊牌用方法无法处理的异常，就保证了服务调用方的线程不会被长时间占用，避免故障在分布式系统中蔓延，乃至雪崩。
服务降级处理是在客户端实现完成的，与服务端没有关系
整体资源快不够了，忍痛将某些服务单元先关掉，关闭后还要返回一些可处理的备选方法，待渡过难关，再开启回来。
分布式项目中，有数十个依赖关系，每个依赖关系在某些时候不可避免地失败，
服务雪崩 ：当A调用微服务B，B调C，和其他微服务，这是扇出，当扇出链路上某个微服务调用响应时间过长或者不可用，对微服务的A的调用就会占用越来越多的系统资源，导致系统崩溃，所谓的雪崩效应
服务熔断 ：一般是某个服务异常引起的，相当于“保险丝”，当某个异常条件被触发，直接熔断整个服务，不是等到此服务超时
服务降级 ：降级一般是从整体负荷考虑，当某个服务熔断之后，服务器将不再被调用，客户端可自己准备一个本地的fallback回调，返回一个缺省值，虽然服务水平下降，当能用，比直接挂掉要强
springcloud是spring，采用AOP的思想，异常处理信息，我们某个服务的功能是每个方法，我们还可以使用AOP直接在api层通过接口设置服务降级。
SpringCloud：如何使用Eureka进行服务治理？
“微服务”一词来自国外的一篇博文，网站：
如果您不能看懂英文文档，可以跳转到搜简体中文的文档
这是国人翻译的文档，可以学习参考：
引用官方文档解释：
Eureka server：创建服务注册中心
环境准备：
创建一个SpringBoot Initialize项目
pom，加上spring-cloud-starter-netflix-eureka-server
@EnableEurekaServer配置Eureka服务端：
eureka服务端配置：
启动项目，访问：
在Eureka中，服务提供者和服务消费者是Eureka client提供的，使用注解@EnableEurekaClient标明
新建SpringBoot Initializer项目
写个例子，以github用户为例：
读取github用户信息：
@EnableEurekaClient指定eureka client：
部署后，注册信息发布到eureka server：
服务注册信息打印到控制台
访问接口： ，能访问就是注册成功
提示：EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
方法：可以关了eureka的自我保护模式eureka.server.enableSelfPreservation=false
eureka也引用SpringBoot actuator监控管理
具体可以进行配置，配置成eureka server的ip，加上actuator
显示ip和实例id配置：
Spring cloud有两种最常用的服务调用方式，一种是ribbon+restTemplate，另一种是feign，所以本博客以学习为目的，简单介绍一下ribbon+restTemplate的方式，之后有时间再介绍feign的方式
ribbon+resttemplate方式，Spring Cloud Hoxton.SR6版本不需要引入spring-cloud-starter-netflix-ribbon，已经默认集成
引入web既可，主要是想调restTemplate
yaml配置：
关键点，使用SpringCloud的@LoadBalanced，才能调 ? 接口的数据，浏览器是不能直接调的
附录：
ok，本博客参考官方教程进行实践，仅仅作为入门的学习参考资料
Spring Cloud中优雅的使用Feign调用接口
1、RestTemplate来调用接口
可以直接注入对象，然后调用接口,这种方式唯一的弊端就是你需要知道服务提供者的地址，根据指定的地址来进行调用
@Autowired
private RestTemplate restTemplate;
@Override
public SubstitutionDto getSubstitutionInfo(Long sid) {
User user= this.restTemplate.getForObject("" + id, User.class);
// .......
}
2、声明式的REST客户端Feign来进行接口调用
在启动类上加 @EnableFeignClients 注解，如果你的Feign接口定义跟你的启动类不在一个包名下，还需要制定扫描的包名 @EnableFeignClients (basePackages = "com.hui.api.client")
接口的消费定义，单独抽一个项目出来，后面打成公共的jar，这样无论是哪个项目需要调用接口，引入公共的接口SDK jar即可，不用重新定义一遍了。