springcloud-笔记

webservice 第一代应用服务整合（XML+SOAP）

优点：是可跨平台的技术

缺点：处理速度慢、如果要使用远程接口调用则要生成很多的工具类代码

SOA（服务总线的形式调用）

        

PRC技术-远程过程调用（比较流行的有阿里的double及REST-因为json的广泛使用）

使用rest实现RPC可以更快

REST（springcloud核心架构）

我简单的理解为http（理解不够深，如果错误后续修改）

------------------------

springcloud

1、每个微服务都应该有熔断处理机制；

2、微服务尽量将session设为无状态，如果用户量大会有内存问题；（通过其他方式保存session、session共享）

springsecrity-安全认证组件

        1、依赖

        2、pom文件添加服务的认证账号、密码、授权角色等（参照图1），相当于给这个服务设置了账号密码，保证服务的安全性

        3、进行完2中账号配置后再浏览器接口服务时，需要输入账号才能访问，或者再url中带有账号密码才能访问（参照图2），但使用rest接口访问时则没办法直接添加账号密码访问；

        4、（可以声明一个header的bean来配置，后续通过该bean进行配置）rest服务调用方需要在header中配置账号密码，并对其进行base64加密；（Basic+一个空格+账号密码密文）（参照图3）

        5、使用形式可以使用单独的模块编写secrity类（继承响应的接口），其他服务如果要使用安全认证则直接pom文件引用该模块就可以；--记得引用服务不需要安全认证的任何配置（解决大量服务都需要安全认证的需要，一个单独的地方进行维护和引用）

图1

 图2

图3

Eureka发现服务

        服务启动的发现，下线的服务清理（心跳）

和zookeeper类似，但zookeeper速度没有Eureka块，且Eureka是以java程序的形式提供服务，比较方便；

        1、依赖 （Eureka服务端）

        2、启动类注解

        3、需要注册的服务pom添加依赖（Eureka客户端、springcloud-config依赖），yml添加Eureka注册的地址（参照图1），启动类添加客户端注解；

        4、需要注册的服务设置应用名称，这样注册到Eureka的服务才会显示名称，后续的调用和负载都会使用这个名称；并设置服务地址信息，ip或者域名(Ribbon并不是通过这个地址找到的服务)（参考图2），以及设置服务地址所链接的地址（参照图3）

        5、如果要看微服务的详细信息，需要在‘需要注册的服务’pom文件中追加监控配置（参照图4），并在父pom中追加插件及资源项（参照图5）

        6、需要注册的服务yml文件修改，追加info显示的配置信息（参照图6）

        7、设置Eureka服务清理的间隔时间（心跳），修改Eureka主服务的yml文件，添加清理间隔，单位为毫秒，默认为60x1000毫秒（一般不建议修改，直接使用60s）；并进行自我注册（注册服务本身也需要注册进去）（参照图7）

        8、Eureka默认会有保护模式配置，服务不可用是会出现红字提示，不能被Eureka清理掉，同时在配置文件中可以对该保护模式进行关闭保护模式（参照图8）；理论上是只有关闭了保护模式才会被清理掉，但实际的现象是无效服务可以被清理掉；（不建议对保护模式做变更）

        9、Eureka和服务之间的关系靠心跳保持联系，服务断也可以对心跳进行配置（一般不需要配置）（参照图9）

        10、注册到Eureka中的服务，可以通过Eureka来获取服务的信息，即通过这些信息来做的服务列表（参照图10）

        11、Eureka也需要添加安全认证，和服务端的配置是一致的（1、依赖添加；2、yml修改（参照图11）3、修改微服务端yml配置文件）

        12、HA机制的搭建，选择两台或以上的主机完成，并使用相互注册的方式（此时就不需要再注册自己了），方式为修改yml配置文件，注册多个发现服务使用逗号分割（参照图12）；测试在访问发现服务时，会出现相互注册的副本；同理微服务的注册也需要把服务同时注册到多台发现服务上；

        13、服务做集群时要保证服务的名称是一致的，不然会显示不同的服务，没办法负载均衡（相同的名称只会显示一个服务，可以具体显示该服务的数量）

图1

 

 图2

 图3

图4

图5

图6

图7

 图8

 图9

图10

注入，编写接口 

启动主类添加注解

 图11

Eureka端

 微服务端一样，修改注册的路径添加账号密码

图12

Ribbon服务调用组件

        客户端实现负载均衡处理的组件（服务器端如果做负载均衡的话可以用nginx等）

        调用方

        1、pom引入Ribbon、Eureka相关依赖

        2、rest参数中添加负载均衡注解（参照图1）、

        3、修改yml文件，追加Eureka注册地址（注意因为是调用方，而不是注册到Eureka中所以是否注册参数必须为false）（参照图2）

        4、修改项目启动类，Eureka客户端注解（参照图3）

        5、（注意注册到Eureka中的服务名称都是全大写）修改控制类，调用地址直接使用服务名称+具体接口的url（参照图4）

        6、‘@loadbalanced’注解负载均衡是有策略的默认轮询，且当服务不可用后还是会有请求到不可用的服务上，但一定次数的失败后或者一定时间后请求就不会再到这个不可用的服务上了；

        7、当然负载均衡的策略也可以自定义（在客户端自定义），首先需要在一个spring扫描不到的包中创建一个自定义策略类来声明策略（参照图5），然后在启动主类中添加Ribbon注解并指定自定义策略类（参照图6）

        ------------------------------------------------------------------------------------------------------------------------

        8、Ribbon也可以脱离开Eureka来使用，首先不需要yml的Eureka的相关配置并添加Ribbon负载需要的信息（参照图7），然后去掉template上的‘@loadBalanced’注解，3、将主类上的Ribbon配置注解拿到具体的Controller类中(参照图8)，其中name要和图7中配置文件中的的名称一致；然后具体的访问形式参照图9；

        注：这种形式可以使用Ribbon进行负载均衡，但不标准，只是为了说明Ribbon有这项功能；

        

图1

图2

 图3

 图4

图5

 图6

 图7

 图8

 图9

Feign接口调用服务

        将rest的方式转换成接口        

        自带负载均衡

        通常RPC的调用过程中都是使用rest的形式来进行接口调用，是需要自己去声明restTemplate去别写程序发送请求，并且针对于返回的数据（一般都是JSON）进行转换然后再进行使用，跟我们平时的开发习惯是很不相同的，我们的喜欢是调用接口来实现功能；

        那么他就来了，F是将Rest调用实现成了一个接口，通过接口调用来进行交互；

        1、需要在调用端进行相关配置，首先需要引入依赖（Feign依赖是包含有Ribbon包的），yml添加Eureka配置；

        2、此时通过Feign进行rest远程调用，需要进行安全认证（之前通过Template的形式是自定义的处理类，Feign调用的话需要自己认证），认证的方式springcloud已经整合过，可以直接通过编写配置类来进行配置（参照图1）

        3、编写接口并添加Feign相关注解（参照图2）

        4、注入接口直接使用（参照图3）

        5、启动主类中添加注解（3中定义的接口没有声明spring相关注解所以不能直接被扫描到，需要添加Feign相关注解让spring扫描到）（参照图4）

        6、如果在调用的过程中，接口参数过大，可以对指定阈值进行压缩，修改yml文件（参照图5）

        7、可以修改yml信息来开启打印Feign调用的日志信息（默认不开启）（参照图5），并修改Feign的配置文件（参照图6），通过日志可以看到，Feign发送消息，是发送给Eureka的，还可以看到负载均衡相关信息，会有负载的服务列表等信息；所以可以通过看这个日志来推Feign是怎么工作的；

总结：Feign = RestTemplate + httHeader + Ribbon + Eureka = 业务接口的自动实例化；

图1

图2、注解中value为服务名称，configuration为配置加密的配置类

 图3

图4

 图5

 图6

hystrix熔断机制

        当服务不可用时，按照设置的返回信息返回，而不是返回错误信息；

       一、fallback

                当服务中方法抛出异常/错误时，会判断为方法不可用，会默认使用配置好的回调方法；

                注意：此时的服务可用，只是某些方法返回了错误/异常；

        服务端修改

        1、添加pom依赖

        2、申明一个和调用方法同入参出参参数的方法，这个方法当做调用主方法错误后调用的方法，所以声明的这个方法可以自定义一个错误的返回（参照图1）；

        3、服务程序主类添加启动熔断注解（参照图2）；

        二、服务降级

                其实就是客户端的fallback

                当调用的服务不可用时，服务不会出现异常，而是返回一个本地的操作调用；

                服务降级是客户端实现的，跟被调用的服务器端没有关系

        三、hystrixDashBoard

                监控，可以针对某一项服务提供监控并查看接口的调用情况；

        四、turbine

                

                

        客户端服务

        1、创建fallbackFactory类并实现接口（参照图3）

        2、在Feign接口调用处添加fallback类（参照图4）；

        3、在yml文件中配置开启Hystrix启动（有些版本不用设置）（ 参照图5）

图1

 图2

 图3

图4

 图5

zuul-路由 代理

        实现的就是一个代理功能，（代理就是不让用户看到真实的操作，比如url）

        此服务也需要注册到Eureka中

        1、添加pom依赖

        2、yml配置端口，注册地址、服务名称等

        3、启动类添加启动zuul代理注解（参考图1）

        4、不需要其他配置直接通过zuul的ip+端口+要访问的服务名称+服务路径来访问，可以看到是直接可以代理的；可以查看zuul的日志可出，zuul代理了所有的服务；

        5、在4中可以看到代理服务的访问还是需要用到注册到Eureka中的服务名称来访问，这种访问形式没有起到代理的作用，所以需要在zuul服务的yml配置文件中添加zuul配置，用来声明用哪个路径来代替Eureka中服务名的路径（参照图2），这样通过访问替代的url来访问具体的服务；

        6、5中虽然可以起到使用别名来访问具体服务的代理，但还是可以通过真实的服务名称来访问；此时需要再zuul服务的yml配置文件中添加忽略配置，参考图3

        7、6中是忽略单个服务，如果微服务有很多个可以使用通配符（需要加引号）的形式将所有的服务都忽略掉；参照图4，

        8、图2中‘服务名称’与‘映射名称’可以有另外一个中写法，参照图5，其中‘company’单词是逻辑名称，客户使用其他名称替换，主要是为了和应用服务的名称有个关联关系；这样显示更易读；

        9、以上方式都是通过Eureka的方式来访问，当然zuul可以直接代理具体的微服务（参照图6）；此方式不建议直接绑定ip，因为这样就没办法负载等；

        10、zuul的访问路径可以添加前缀，所有服务的访问都必须带有前缀，参照图7；

        11、以上的访问是没有添加认证的，如果代理了需要认证的服务则需要在zuul服务中添加filter并实现zuulFilter接口；（参照图8），此时这个filter不能被spring扫描为bean，需要创建一个配置文件来声明这个filter为spring的bean；（zuul代理的服务需要认证，自己的服务也是需要认证的，参照其他项目来添加zuul项目的认证配置，yml、依赖）

        12、整理完zuul之后，在使用feign来接口调用的时候也是需要使用zuul代理的形式来访问，修改feign调用的配置，服务名称应为zuul在Eureka中的名称，接口路径为代理的路径、认证信息为zuul的认证信息；参照图9

        13、如果zuul中某个filter不想使用了，可以通过yam配置中将某个filter禁用掉，参照图10；

如果项目中有多个filter的时候可以通过配置文件来实现哪些需要使用哪些需要禁止；

       14、 zuul服务降级

                和hystrix的服务降级是一个概念，还是推荐使用hystrix中的服务降级；

                如果被代理的服务挂掉的话，使用代理地址访问的响应信息是一个错误页面；

                

                1、添加一个filter并实现接口

                2、实现方法（注明代理服务的名称，服务的返回信息等）参照图11

图1

 图2

 图3

 图4

 图5

 图6

图7

 图8

 

 图9

 图10

 图11

 

 

  

问题：

        1、Ribbon负载均衡是客户端负载，但首先要负载Eureka服务，Eureka再负载具体的服务，同时通过Ribbon进行的吗？怎样进行的呢？

        ：负载访问的时候不访问Eureka服务器，直接负载具体的微服务，而且是在‘客户端’（访问端）根据Ribbon的策略就已经确定了访问的哪台服务器；

        2、如果在不同的主机上去向Eureka注册，Eureka是怎样调用到具体的服务的呢？是服务注册到Eureka中的时候把访问地址提供给了Eureka吗？

       ：是否是通过Eureka介绍中的2中配置的服务地址找的呢？todo，如果是docker形式部署应该怎样找呢？

        3、zuul的服务降级和hystrix的服务降级都存在的时候，如果没有zuul的服务降级可以直接返回hystrix的降级信息吗？还是zuul的调用如果遇到hystrix的降级信息会认为是返回了错误，直接返回错误信息呢？