springcloud前后端分离(springcloud前后端不分离)

SpringCloud之Eureka Feign简介

1、Eureka注册中心

现在公司项目大多采用前后端分没拆敏离架构，服务层被拆分成了很多的微服务，为方便管理Spring Cloud给我们提供了服务注册中心来管理微服务。枯枝

1.1、Eureka简介

Spring Cloud Eureka 是对Netflix公司的Eureka的二次封装，它实现了服务治理的功能，Spring Cloud Eureka提

供服务端与客户端，服务端即是Eureka服务注册中心，客户端完成微服务向Eureka服务的注册与发现。服务端和

客户端均采用Java语言编写。下图显示了Eureka Server与Eureka Client的关系：

Eureka Server是服务端，负责管理各各微服务结点的信息和状态。

在微服务上部署Eureka Client程序，远程御如访问Eureka Server将自己注册在Eureka Server。

微服务需要调用另一个微服务时从Eureka Server中获取服务调用地址，进行远程调用。

1.2、Eureka Server搭建

1.2.1、单机环境搭建

1、父工程引入Maven依赖：

org.springframework.cloud

spring‐cloud‐dependencies

Finchley.SR1

pom

import

2、在Eureka Server工程添加：

org.springframework.cloud

spring‐cloud‐starter‐netflix‐eureka‐server

3、在SpringBoot启动类添加@EnableEurekaServer注解，标识这是一个Eureka服务：

@EnableEurekaServer//标识这是一个Eureka服务

@SpringBootApplication

publicclassGovernCenterApplication{

publicstaticvoidmain(String[] args){

SpringApplication.run(GovernCenterApplication.class, args);

}

4、在application.yml中配置Rureka：

server:

port:50101#服务端口

spring:

application:

name:xc‐govern‐center#指定服务名

eureka:

client:

registerWithEureka:false#服务注册，是否将自己注册到Eureka服务中

fetchRegistry:false#服务发现，是否从Eureka中获取注册信息

serviceUrl:#Eureka客户端与Eureka服务端的交互地址，高可用状态配置对方的地址，单机状态配置自己（如果不配置则默认本机8761端口）

defaultZone:

server:

enable‐self‐preservation:false#是否开启自我保护模式，开发模式建议关闭

eviction‐interval‐timer‐in‐ms:60000#服务注册表清理间隔（单位毫秒，默认是60*1000）

5、启动Eureka Server，浏览50101端口：

上图红色提示信息：

THE SELF PRESERVATION MODE IS TURNED OFF.THIS MAY NOT PROTECT INSTANCE EXPIRY IN CASE OF

NETWORK/OTHER PROBLEMS.

自我保护模式被关闭。在网络或其他问题的情况下可能不会保护实例失效。

Eureka Server有一种自我保护模式，当微服务不再向Eureka Server上报状态，Eureka Server会从服务列表将此

服务删除，如果出现网络异常情况（微服务正常），此时Eureka server进入自保护模式，不再将微服务从服务列

表删除。

至此，Eureka服务端已经搭建完成，下面进行服务注册，将微服务注册到Eureka服务端进行管理。

1.3、服务注册

1、在需要注册的微服务中，添加依赖：

org.springframework.cloud

spring‐cloud‐starter‐netflix‐eureka‐client

2、配置application.yml:

eureka:

client:

registerWithEureka:true#服务注册开关

fetchRegistry:true#服务发现开关

serviceUrl:#Eureka客户端与Eureka服务端进行交互的地址，多个中间用逗号分隔

defaultZone:${EUREKA_SERVER:}

instance:

prefer‐ip‐address:true#将自己的ip地址注册到Eureka服务中

ip‐address:${IP_ADDRESS:127.0.0.1}

instance‐id:${spring.application.name}:${server.port}#指定实例id

3、启动类上加注解@EnableDiscoveryClient ，表示它是一个Eureka的客户端

4、刷新Eureka Server查看注册情况

同理可将需要注册的服务注册到Eureka Server。

2、Feign远程调用

服务层被拆分成了很多的微服务，服务与服务之间难免发生交互调用，这时候就需要用到远程调用，接下来带大家入门及使用

2.1Ribbon

1、简介

Ribbon是Netflix公司开源的一个负载均衡的项目（），它是一个基于HTTP、TCP的客户端负载均衡器，通过负载均衡来实现系统的高可用、集群扩容等功能。

如下图是服务端负载均衡架构图：

用户请求先到达负载均衡器（也相当于一个服务），负载均衡器根据负载均衡算法将请求转发到微服务。负载均衡算法有：轮训、随机、加权轮训、加权随机、地址哈希等方法，负载均衡器维护一份服务列表，根据负载均衡算法将请求转发到相应的微服务上，所以负载均衡可以为微服务集群分担请求，降低系统的压力。

客户端负载均衡架构图：

客户端负载均衡与服务端负载均衡的区别在于客户端要维护一份服务列表，Ribbon从Eureka Server获取服务列表，Ribbon根据负载均衡算法直接请求到具体的微服务，中间省去了负载均衡服务。

2、测试Ribbon

Spring Cloud引入Ribbon配合 restTemplate 实现客户端负载均衡。Java中远程调用的技术有很多，如：webservice、socket、rmi、Apache HttpClient、OkHttp等，互联网项目使用基于http的客户端较多，下面介绍使用的是OkHttp。

首先加入Maven依赖：

!--如果依赖了spring-cloud-starter-eureka，会自动添加spring-cloud-starter-ribbon依赖--

org.springframework.cloud

spring‐cloud‐starter‐ribbon

com.squareup.okhttp3

okhttp

在application.yml中配置Ribbon参数:

ribbon:

MaxAutoRetries:2#最大重试次数，当Eureka中可以找到服务，但是服务连不上时将会重试

MaxAutoRetriesNextServer:3#切换实例的重试次数

OkToRetryOnAllOperations:false#对所有操作请求都进行重试，如果是get则可以，如果是post，put等操作没有实现幂等的情况下是很危险的,所以设置为false

ConnectTimeout:5000#请求连接的超时时间

ReadTimeout:6000#请求处理的超时时间

负载均衡测试：

启动两个cms服务，端口要不一致

定义RestTemplate，使用@LoadBalanced注解：

@Bean

@LoadBalanced

publicRestTemplaterestTemplate(){

returnnewRestTemplate(newOkHttp3ClientHttpRequestFactory());

}

远程调用cms的查询页面接口：

//负载均衡调用

@Test

publicvoidtestRibbon(){

//服务id

String serviceId ="XC‐SERVICE‐MANAGE‐CMS";

for(inti=0;i10;i++){

//通过服务id调用

ResponseEntity forEntity = restTemplate.getForEntity("http://"+ serviceId

+"/cms/page/get/5a754adf6abb500ad05688d9", CmsPage.class);

CmsPage cmsPage = forEntity.getBody();

System.out.println(cmsPage);

}

添加@LoadBalanced注解后，restTemplate会走LoadBalancerInterceptor拦截器，此拦截器中会通过RibbonLoadBalancerClient查询服务地址，打断点观察每次调用的服务地址和端口，可以看到两个cms服务会轮流被调用。

2.2Feign

简介：

Feign是Netflix公司开源的轻量级rest客户端，使用Feign可以非常方便的实现Http 客户端。Spring Cloud引入Feign并且集成了Ribbon实现客户端负载均衡调用。

使用：

添加Maven依赖：

dependency

groupIdorg.springframework.cloud/groupId

artifactIdspring‐cloud‐starter‐openfeign/artifactId

/dependency

dependency

groupIdcom.netflix.feign/groupId

artifactIdfeign‐okhttp/artifactId

/dependency

定义FeignClient接口：

@FeignClient(value = "XC_SERVICE_MANAGE_CMS")

publicinterfaceCmsPageClient{

//微服务接口路径

@GetMapping("/cms/page/get/{id}")

publicCmsPagefindById(@PathVariable("id")String id);

}

启动类添加@EnableFeignClients注解

测试：

@RunWith(SpringRunner.class)

@SpringBootTest

publicclassFeignTest{

@Autowired

CmsPageClient cmsPageClient;//接口代理对象，由Feign生成代理对象

@Test

publicvoidtestFeign(){

//发起远程调用

CmsPage cmsPage = cmsPageClient.findById("5a754adf6abb500ad05688d9");

System.out.println(cmsPage);

}

Feign工作原理：

1、启动类添加@EnableFeignClients注解，Spring会扫描标记了@FeignClient注解的接口，并生成此接口的代理对象

2、 @FeignClient(value = XcServiceList.XC_SERVICE_MANAGE_CMS)即指定了cms的服务名称，Feign会从注册中心获取cms服务列表，并通过负载均衡算法进行服务调用。

3、在接口方法中使用注解@GetMapping("/cms/page/get/{id}")，指定调用的url，Feign将根据url进行远程调用。

Dubbo与SpringCloud的区别和优缺点

以上内容均为官方定义，截图如下：

从以上定义中我们不难看出，Apache Dubbo的目标是基于RPC调用为主，并扩展相应的功能。而SpringCloud是致力于提供分布式服务的各种工具。可以这样讲，Apache Dubbo从概念上讲只相当于SpringCloud中的feign而已。

Apache Dubbo：诞生于阿并源里巴巴的线上需求，主要是为了应对微服务场景下高并发的处理，所以Apache Dubbo的核心关注点就是解决微服务之间调用的性能。并且将包括服务注册/发现、负载均衡等微服务的核心内容进行了集成。最后在核心调用流程稳定的情况下完成了包括本地存根、Mock、版本控制等诸多特性的集成。

SpringCloud： SpringCloud是Spring家族中在微服务领域的关键组成部分，延续了Spring一贯的风格：为大家提供好用的工具，可以屏蔽底层实现，一站式完成业务开发。包括后面的SpringCloud Netflix和SpringCloud Alibaba等都是基于此完成工具的开发。我们可以大概数一数SpringCloud的工具内容，Ribbon【负载均衡】、Feign【HTTP服务】、Hystrix【熔断降级】、Gateway【网关】等等，从其中我们不难发现，SpringCloud对于微服务的调用的性能并不太关心，它更关心的是处理微服务调用以外的内容，虽然他勉为其难的搞了一个Feign，但是我们都知道，HTTP的调用是非常耗时的，它与RPC的调用效率完全不可同日而语。

综上所述：Apache Dubbo的目标是为了高效调用服务。SpringCloud的目标是一条龙解决微服务的治理问题，那么出发点都不同，比较的意义又在哪里呢。

事实上，目前我接触和了解的互联网大厂的项目里，单纯的使用SpringCloud的非常少。虽然不全是选用Apache Dubbo，还有包括Thrift、Zero等微服务框架，但是Apache Dubbo的市场占有率会相对比较高，也是很多大厂项目的首选。

但是Apache Dubbo的服务治理其实并不太好用，比如熔断降级、限流等，同时Apache Dubbo还有一个比较麻烦的问题，就运雀是没有HTTP调用的逻辑，这一点对前后端分离的项目非常不友好。

基于以上内容，其实在实际项目中， Apache Dubbo和SpringCloud相结合才是目前比较主流的使旁蔽早用方式。服务之间的调用使用Apache Dubbo。熔断、网关、限流等使用SpringCloud。尤其是在拥有了SpringCloud Alibaba以后，SpringCloud与Apache Dubbo的结合更加紧密，这才是我个人建议的使用方式。

以上内容为新媒号(sinv.com.cn)为大家提供！新媒号，坚持更新大家所需的互联网后端知识。希望您喜欢！

版权申明：新媒号所有作品（图文、音视频）均由用户自行上传分享，仅供网友学习交流，不声明或保证其内容的正确性，如发现本站有涉嫌抄袭侵权/违法违规的内容。请发送邮件至 k2#88.com(替换@) 举报，一经查实，本站将立刻删除。