微服务架构——SpringCloud快速入门

已于 2024-01-20 11:16:52 修改
阅读量977 收藏 4
点赞数
分类专栏： SpringCloud 文章标签： 微服务 spring cloud java 分布式
于 2023-04-09 21:04:28 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_44320429/article/details/130047814
版权

认识微服务

随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构。这些架构之间有怎样的差别呢？

单体架构

将业务的所有功能集中在一个项目中开发，打成一个包部署。

优点：

  • 架构简单
  • 部署成本低

缺点：

  • 耦合度高（维护困难、升级困难）

image-20230409205110718

分布式架构

根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。

优点：

  • 降低服务耦合
  • 有利于服务升级和拓展

缺点：

  • 服务调用关系错综复杂

image-20230409205208391

分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：

  • 服务拆分的粒度如何界定？
  • 服务之间如何调用？
  • 服务的调用关系如何管理？

人们需要制定一套行之有效的标准来约束分布式架构。

微服务

微服务的架构特征：

  • 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
  • 自治：团队独立、技术独立、数据独立，独立部署和交付
  • 面向服务：服务提供统一标准的接口，与语言和技术无关
  • 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

image-20230409205508172

微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。

因此，可以认为微服务是一种经过良好架构设计的分布式架构方案 。

但方案该怎么落地？选用什么样的技术栈？全球的互联网公司都在积极尝试自己的微服务落地方案。在国内最知名的就是SpringCloud和阿里巴巴的Dubbo。

微服务技术对比

image-20230409205721461

SpringCloud

  • SpringCloud是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud。

  • SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验：

image-20230401151147123

服务拆分的及远程调用

服务拆分

  1. 单一职责：不同微服务，不要重复开发相同业务

  2. 数据独立：不要访问其它微服务的数据库，不同微服务都应该有自己独立的数据库

  3. 面向服务：将自己的业务暴露为接口，供其它微服务调用

image-20230401151433292

微服务远程调用方式

案例：根据订单id查询订单功能

需求：根据订单id查询订单的同时，把订单所属的用户信息一起返回

image-20230401141120420

远程调用方式分析：

当我们使用浏览器请求数据时，可以直接发起http请求获取到对应的数据。同理，当我们在一个服务中想要获取另一个服务的某些数据，那我们可以用代码来实现发起一个对应的http请求到目标服务获取我们想要的数据。

image-20230401151659266

  • 基于RestTemplate发起的http请求实现远程调用

  • http请求做远程调用是与语言无关的调用，只要知道对方的ip、端口、接口路径、请求参数即可。

可以在order-service中使用RestTemplate发起HTTP请求，调用user-servise中获取用户信息的接口

@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {

    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }

    /**
     * 创建RestTemplate 并注入Spring容器
     * @return 
     */
    @Bean
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
}

@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;
    
    @Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) {
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        // 2.发起http请求，查询用户
        String url = "http://localhost:8081/user/" + order.getUserId();
        User user = restTemplate.getForObject(url, User.class);
        // 3.封装user到order
        order.setUser(user);
        // 4.返回
        return order;
    }
}

Eureka注册中心

服务调用存在的问题

  • 服务消费者该如何获取服务提供者的地址信息？

  • 如果有多个服务提供者，消费者该如何选择？

  • 消费者如何得知服务提供者的健康状态？

Eureka的作用

针对上面几个问题，eureka给出了答案：

  • 服务消费者该如何获取服务提供者的地址信息？

    1. 服务提供者启动时向eureka注册自己的信息
    2. eureka保存这些信息
    3. 消费者根据服务名称向eureka拉取提供者信息

  • 如果有多个服务提供者，消费者该如何选择？

    • 服务消费者利用负载均衡算法，从服务列表中挑选一个

  • 消费者如何得知服务提供者的健康状态？

    1. 服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态
    2. eureka会更新记录服务列表信息，心跳不正常会被剔除
    3. 消费者就可以拉取到最新的信息

image-20230401152300914

在Eureka架构中，微服务角色有两类：

  • EurekaServer：服务端，注册中心

    • 记录服务信息
    • 心跳监控

  • EurekaClient：客户端

    • Provider：服务提供者，例如案例中的 user-service

      • 注册自己的信息到EurekaServer

      • 每隔30秒向EurekaServer发送心跳

    • consumer：服务消费者，例如案例中的 order-service

      • 根据服务名称从EurekaServer拉取服务列表

      • 基于服务列表做负载均衡，选中一个微服务后发起远程调用

使用Eureka

image-20230401152907330

搭建EurekaServer

搭建EurekaServer服务步骤如下：

  1. 创建项目，引入spring-cloud-starter-netflix-eureka-server的依赖

    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

  2. 在启动类添加@EnableEurekaServer注解

  3. 添加application.yml文件，编写下面的配置：

    server:
  port: 10086   #服务端口
spring:
  application:
    name: eureka-server   #服务名称
eureka:
  client:
    service-url:  # eureka自己的地址信息，之后如果做eureka集群需要用到
      defaultZone: http://127.0.0.1:10086/eureka/
注册user-service

将user-service服务注册到EurekaServer步骤如下：

  1. 在user-service项目引入spring-cloud-starter-netflix-eureka-client的依赖

    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

  2. 在application.yml文件，编写下面的配置：

    spring:
  application:
    name: user-service   #服务名称
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka/

我们可以将user-service多次启动， 模拟多实例部署，但为了避免端口冲突，需要修改端口设置：

image-20230401154208457

order-service完成服务注册

order-service虽然是消费者，但与user-service一样都是eureka的client端，同样可以实现服务注册：

  1. 在order-service项目引入spring-cloud-starter-netflix-eureka-client的依赖

  2. 在application.yml文件，编写下面的配置：

    spring:
  application:
    name: order-service   #服务名称
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka/
在order-service完成服务拉取

服务拉取是基于服务名称获取服务列表，然后在对服务列表做负载均衡

  1. 修改OrderService的代码，修改访问的url路径，用服务名代替ip、端口：

    // 2.发起http请求，查询用户
// String url = "http://localhost:8081/user/" + order.getUserId();
String url = "http://user-service/user/" + order.getUserId();

  2. 在order-service项目的启动类OrderApplication中的RestTemplate添加负载均衡注解：

    @Bean
@LoadBalanced   // 负载均衡
public RestTemplate restTemplate(){
    return new RestTemplate();
}

Ribbon负载均衡

ribbon实现负载均衡的基本流程：当order-service发起请求后，ribbon会拦截处理请求（到eureka-server根据服务名称获取服务列表，根据负载均衡策略选择出一个服务），对选择出的服务发起请求。

负载均衡原理

image-20230401160636789

负载均衡策略

Ribbon的负载均衡规则是一个叫做IRule的接口来定义的，每一个子接口都是一种规则，默认实现是ZoneAvoidanceRule，根据zone选择服务列表，然后轮询

image-20230401160836823

image-20230401160905614

通过定义IRule实现可以修改负载均衡规则，有两种方式：

  1. 代码发布方式：在order-service中的OrderApplication类中，定义一个新的IRule：

    /**
 * @return 配置负载均衡的方式为随机
 */
@Bean
public IRule RandomRule(){
    return new RandomRule();
}

    通过这种方式配置的负载均衡规则会作用于全体，即order-service访问任何微服务都将采用这种规则。这种方式配置灵活，但修改时需要重新打包发布

  2. 配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：

    user-service:	#指定服务名称
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule  #负载均衡规则

    配置文件方式配置的规则则只会作用于指定的微服务。这种方式直观，方便，无需重新打包发布，但是无法做全局配置。

懒加载与饥饿加载

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，所以会导致第一次请求时间很长。

而饥饿加载则会在项目启动时创建LoadBalanceClient，降低第一次访问的耗时，可以通过下面配置开启饥饿加载：

ribbon:
  eager-load:
    clients: 	#指定对user-service这个服务饥饿加载，可以指定多个service
      - user-service
      - xx-service
    enabled: true	#开启饥饿加载

Nacos注册中心

Nacos是阿里巴巴的产品，现在是SpringCloud中的一个组件。相比Eureka功能更加丰富，在国内受欢迎程度较高。

服务注册到Nacos

  1. 在cloud-demo父工程中添加spring-cloud-alilbaba的管理依赖：

    <!--nacos的管理依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.9.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

  2. 注释掉order-service和user-service中原有的eureka依赖。

  3. 添加nacos的客户端依赖：

    <dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

  4. 修改user-service&order-service中的application.yml文件，注释eureka地址，添加nacos地址：

    spring: 
  cloud:
    nacos:
      server-addr: localhost:8848   #nacos服务地址

  5. 启动并测试

    image-20230405120413735

Nacos服务分级存储模型

Nacos服务分级存储模型

  1. 一级是服务，例如user-service
  2. 二级是集群，例如杭州或上海
  3. 三级是实例，例如杭州机房的某台部署了user-service的服务器

image-20230405120825637

服务跨集群调用问题

如果杭州集群的order-service想要访问user-service，那么他可以选择访问杭州的user-service或者上海的user-service，显然访问同一集群的访问效率会更高。

所以服务调用应该尽可能选择本地集群的服务，跨越集群调用的延迟较高。当本地集群不可用时，再去访问其他集群。

image-20230405121410263

服务集群属性配置

修改application.yml文件，添加spring.cloud.nacos.discovery.cluster-name属性：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848   #nacos服务地址
      discovery:
        cluster-name: HZ  #配置集群名称，也就是机房位置，例如：HZ，杭州

我们将user-service和order-service的集群分别设置为SH和HZ，可以在nacos的管理页面看到以下信息：

image-20230405122059814

image-20230405122124852

根据集群负载均衡

NacosRule负载均衡策略
  1. 优先选择同集群服务实例列表
  2. 本地集群找不到提供者，才去其它集群寻找，并且会报警告
  3. 确定了可用实例列表后，再采用随机负载均衡挑选实例

在服务中设置负载均衡的IRule为NacosRule，优先寻找与自己同集群的服务：

user-service: #指定服务名称
  ribbon:
#    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule  #负载均衡规则
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule  #Nacos负载均衡规则
根据权重负载均衡

实际部署中会出现这样的场景：

服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高：

实例的权重控制

  1. Nacos控制台可以设置实例的权重值，0~1之间
  2. 同集群内的多个实例，权重越高被访问的频率越高
  3. 权重设置为0则完全不会被访问（比如线上版本更新的时候就可以用到）

image-20230405142239985

环境隔离——namespace

Nacos中服务存储和数据存储的最外层都是一个名为namespace的东西，用来做最外层隔离。比如我们开发、测试、生产就应该是不同的namepace，而一些业务相关度比较高的就可以放在一个group。

  • 每个namespace都有唯一id
  • 服务设置namespace时要写id而不是名称
  • 不同namespace下的服务互相不可见

image-20230405142747526

nacos默认是一个名为public的命名空间，现在我们在这里新建一个dve开发环境：

image-20230405143151076

image-20230405143520606

修改order-service的application.yml，添加namespace：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848   #nacos服务地址
      discovery:
        cluster-name: HZ  #配置集群名称，也就是机房位置，例如：HZ，杭州
        namespace: f15cf64a-74e6-4f4e-9e23-1d6ba3047c8f		#命名空间的ID

重启order-service之后就可以在服务列表的dev环境看到order-service:

image-20230405143812943

此时访问order-service，因为namespace不同，会导致找不到user-service，控制台会报错。

Nacos注册中心细节分析

Nacos与eureka的共同点
  • 都支持服务注册和服务拉取
  • 都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
  • Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
  • 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
  • Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
  • Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式。（A：可用性，C：一致性，P：分区容错性）

image-20230405144415238

临时实例和非临时实例

服务注册到Nacos时，可以选择注册为临时或非临时实例，通过下面的配置来设置：

spring.cloud.nacos.discovery.ephemeral: false  #设置为非临时实例

临时实例宕机时，会从nacos的服务列表中剔除，而非临时实例则不会

Nacos配置管理

当微服务部署的实例越来越多，达到数十、数百时，逐个修改微服务配置就会让人抓狂，而且很容易出错。我们需要一种统一配置管理方案，可以集中管理所有实例的配置。

image-20230405162327807

Nacos一方面可以将配置集中管理，另一方可以在配置变更时，及时通知微服务，实现配置的热更新。

统一配置管理
在Nacos中添加配置文件

注意：不是所有的配置都适合放到配置中心，维护起来比较麻烦，一般来讲只有项目的核心配置、需要热更新的配置才有放到nacos管理的必要。基本不会变更的一些配置还是保存在微服务本地比较好。

image-20230405161811771

image-20230407214625796

微服务拉取配置

微服务要拉取nacos中管理的配置，并且与本地的application.yml配置合并，才能完成项目启动。但如果尚未读取application.yml，又如何得知nacos地址呢？

因此spring引入了一种新的配置文件：bootstrap.yaml文件，会在application.yml之前被读取，流程如下：

image-20230405162930388

  1. 引入Nacos的配置管理客户端依赖：

    在user-service服务中，引入nacos-config的客户端依赖：

    <!--nacos配置管理依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-nacos-config</artifactId>
    <version>2.1.1.RELEASE</version>
</dependency>

  2. 添加bootstrap.yaml：

    在user-service中添加一个bootstrap.yaml文件，内容如下：

    spring:
  application:
    name: user-service # 服务名称
  profiles:
    active: dev #开发环境，这里是dev 
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
      config:
        file-extension: yaml # 文件后缀名
        namespace: f15cf64a-74e6-4f4e-9e23-1d6ba3047c8f	#这里注意，因为我们的的config是放在dev这个命名空间下的，所以这里要指定config的命名空间，不然会拉取不到

    这里会根据spring.cloud.nacos.server-addr获取nacos地址，再根据

    spring.application.name,spring.profiles.active,spring.cloud.nacos.config.file-extension作为文件id，来读取配置。

  3. 读取nacos配置

    在user-service中的UserController中添加业务逻辑，读取pattern.dateformat配置：

    @Slf4j
@RestController
@RequestMapping("/user")
public class UserController {

    @Value("${pattern.dateformat}")
    private String dateFormat;
    
    @GetMapping("/now")
    public String getTime(){
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dateFormat));
    }
}

    访问页面可以看到效果：

    image-20230407214927346

总结下来将配置交给Nacos管理的步骤：

  1. 在Nacos中添加配置文件
  2. 在微服务中引入nacos的config依赖
  3. 在微服务中添加bootstrap.yml，配置nacos地址、当前环境、服务名称、文件后缀名。这些决定了程序启动时去nacos读取哪个文件
配置热更新

所谓的配置热更新，也就是修改nacos中的配置后，微服务中无需重启即可让配置生效。

有以下两种配置方式可以实现热更新：

@RefreshScope

通过@Value注解注入配置，结合@RefreshScope注解来刷新配置，在@Value注入变量的类上使用注解@RefreshScope:

@Slf4j
@RestController
@RefreshScope
@RequestMapping("/user")
public class UserController {

    @Value("${pattern.dateformat}")
    private String dateFormat;
    
    @GetMapping("/now")
    public String getTime(){
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dateFormat));
    }
}
@ConfigurationProperties

使用@ConfigurationProperties注解代替@Value注解实现自动刷新，在user-service服务中，添加一个类，用来读取patterrn.dateformat属性：

@Component
@Data
@ConfigurationProperties(prefix = "pattern")
public class PatternProperties {
    private String dateformat;
}

在UserController中使用PatternProperties这个类来获取属性：

@Slf4j
@RestController
// @RefreshScope
@RequestMapping("/user")
public class UserController {

    @Autowired
    private UserService userService;

    // @Value("${pattern.dateformat}")
    // private String dateFormat;

    @Autowired
    private PatternProperties patternProperties;

    @GetMapping("/now")
    public String getTime(){
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(patternProperties.getDateformat()));
    }
}
配置共享
多环境共享

微服务启动时会从nacos读取前缀为服务名的多个配置文件：

  1. [服务名]-[spring.profile.active].yaml，环境配置，如user-service-dev.yaml
  2. [服务名].yaml，默认配置，多环境共享，如user-serviceyaml，一些与运行环境无关的通用配置不需要在每一个配置文件中都写一遍，就可以写在这里

image-20230407224435735

新建的user-service.yaml配置文件中的内容：

pattern:
  envSharedValue: 共享属性值

在PatternProperties类中获取属性envSharedValue:

@Component
@Data
@ConfigurationProperties(prefix = "pattern")
public class PatternProperties {
    private String dateformat;
    private String envSharedValue;
}

UserController中新增一个prop接口，用来测试属性值的获取：

@GetMapping("/prop")
public PatternProperties getProp(){
    return patternProperties;
}

现在我们在8081和8082端口分别启动一个user-service，其中8081的环境为dev,8082的环境为sit，调用/user/prop分别可以看到以下返回情况：

image-20230407224809289

image-20230407224831324

我们可以看到环境为dev的user-service同时获取到了user-service-dev.yaml和user-service.yaml配置文件中的内容，而环境为sit的user-service只获取到了user-service.yaml配置文件的内容。显然user-service.yaml是被user-service服务在不同环境下所共享的。

当同一个属性出现在多个配置文件中的时候，配置属性的优先级为：[服务名]-[环境].yaml >[服务名].yaml > 本地配置

image-20230407223510132

多服务共享配置

通过以上的例子我们知道了一个服务在多环境下可以共享配置文件，其实nacos中不同为服务之间也可以共享配置文件，主要可以通过配置ext-config或shared-dataids这两种方式实现：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
      config:
        file-extension: yaml # 文件后缀名
        namespace: f15cf64a-74e6-4f4e-9e23-1d6ba3047c8f
        ext-config:	#多微服务间共享的配置列表
          - data-id: extend.yaml	#要共享的配置文件id
        shared-dataids:	#多微服务间共享的配置列表
          common.yaml	#要共享的配置文件id

我们在nacos在新增extend.yaml和common.yaml这两个配置文件，并且在bootstrap.yaml中完成以上两个配置后，启动user-service，在控制台可以看到：

image-20230407231202730

说明user-service服务成功读取到了新增的两个配置文件，跟上面的多环境配置不同的是，这两个文件的读取和服务名称是无关的，只需要在bootstrap.yaml中指定他的id就能读取到，所以我们在其他的微服务中也可以通过配置ext-config或shared-dataids属性指定要读取的配置文件即可，从而实现了多服务共享配置。

多种配置的优先级：环境配置 >服务名.yaml > ext-config > shared-datdaids > 本地配置

image-20230407232039317

搭建Nacos集群
集群结构图

nacos官方给出的Nacos集群搭建图：

image-20210409210621117

其中包含3个nacos节点，一个负载均衡器（SLB）代理3个Nacos，这里负载均衡器可以使用nginx。

image-20210409211355037

准备三个nacos节点的地址：

节点ipport
nacos1127.0.0.18845
nacos2127.0.0.18846
nacos3127.0.0.18847
集群搭建步骤
  1. 搭建数据库，初始化数据库表结构
  2. 配置nacos
  3. 启动nacos集群
  4. nginx反向代理
初始化数据库

在本地新建一个nacos-config的数据库，将nacos安装目录下conf文件夹下的mysql-schema.sql在新建的数据库中运行一下

image-20230407233536380

运行之后的会得到以下这样几张表：

image-20230407233618142

将conf目录下的cluster.conf.example，重命名为cluster.conf，并添加我们nacos的ip地址：

#
# Copyright 1999-2021 Alibaba Group Holding Ltd.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#

#it is ip
#example
127.0.0.1:8845
127.0.0.1.8846
127.0.0.1.8847
配置nacos

然后在application.properties文件中添加数据库配置，一般文件里都是有这一部分内容的，只不过是被注释掉了，找到改成自己的数据库配置就好了。

image-20230408101513784

启动

将nacos文件夹赋三份，分别命名为nacos1，nacos2，nacos3，分别修改三个文件夹的application.properties：

#nacos1
server.port=8845

#nacos2
server.port=8846

#nacos3
server.port=8847

然后分别启动三个nacos节点。

nginx反向代理

修改nginx安装目录下的conf/nginx.conf文件

image-20230408130711757

添加如下配置：

upstream nacos-cluster {
    server 127.0.0.1:8845;
	server 127.0.0.1:8846;
	server 127.0.0.1:8847;
}

server {
    listen       80;
    server_name  localhost;

    location /nacos {
        proxy_pass http://nacos-cluster;
    }
}

而后在浏览器访问：http://localhost/nacos即可。再把application.yml文件的nacos地址改为localhost:80，启动服务就能在nacos的服务列表找到新启动的服务了。

  • 实际部署时，需要给做反向代理的nginx服务器设置一个域名，这样后续如果有服务器迁移nacos的客户端也无需更改配置.

  • Nacos的各个节点应该部署到多个不同服务器，做好容灾和隔离

Feign远程调用

Feign替代RestTemplate

RestTemplate方式调用存在的问题

先来看我们以前利用RestTemplate发起远程调用的代码：

String url = "http://user-service/user/" + order.getUserId();
User user = restTemplate.getForObject(url, User.class);

存在问题：

  • 代码可读性差，编程体验不统一

  • 参数复杂URL难以维护

Feign介绍

Feign是一个声明式的http客户端，官方地址：https://github.com/OpenFeign/feign，其作用就是帮助我们优雅的实现http请求的发送，解决上面提到的问题，并且Feign集成了Ribbon自动实现负载均衡。

image-20230408131758231

定义和使用Feign客户端

  1. 引入依赖

    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

  2. 在order-service的启动类添加@EnableFeignClients注解开启Feign的功能：

  3. 编写FeignClient接口

    @FeignClient("user-service")
public interface UserClient {
    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}

    UserClient主要是基于SpringMVC的注解来声明远程调用的信息：

    • 服务名称：user-service
    • 请求方式：GET
    • 请求路径：/user/{id}
    • 请求参数：Long id
    • 返回值类型：User

    这样，Feign就可以帮助我们发送http请求，无需自己使用RestTemplate来发送了。

  4. 用FeignClient中定义的方法代替RestTemplate

    @Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;

    // @Autowired
    // private RestTemplate restTemplate;
    
    @Autowired
    private UserClient userClient;

    public Order queryOrderById(Long orderId) {
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        // 2.发起http请求，查询用户
        // String url = "http://localhost:8081/user/" + order.getUserId();
        //使用RestTemplate发起远程调用：
        // String url = "http://user-service/user/" + order.getUserId();
        // User user = restTemplate.getForObject(url, User.class);
        //使用Feign远程调用：
        User user = userClient.findById(orderId);
        // 3.封装user到order
        order.setUser(user);
        // 4.返回
        return order;
    }
}

测试可以成功获取到数据：

image-20230408212506007

自定义配置

SpringBoot帮我们实现了自动装配，但是也允许Feign运行自定义配置来覆盖默认配置，可以修改的配置如下：

类型作用说明
feign.Logger.Level修改日志级别包含四种不同的级别：NONE、BASIC、HEADERS、FULL
feign.codec.Decoder响应结果的解析器http远程调用的结果做解析，例如解析json字符串为java对象
feign.codec.Encoder请求参数编码将请求参数编码，便于通过http请求发送
feign. Contract支持的注解格式默认是SpringMVC的注解
feign. Retryer失败重试机制请求失败的重试机制，默认是没有，不过会使用Ribbon的重试

一般情况下，默认值就能满足我们使用，如果要自定义时，只需要创建自定义的@Bean覆盖默认的Bean即可。下面以日志为例来演示如何自定义配置。

日志的级别分为四种：

  • NONE：不记录任何日志信息，这是默认值。
  • BASIC：仅记录请求的方法，URL以及响应状态码和执行时间
  • HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息
  • FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据。

配置Feign日志有两种方式：

方式一：配置文件方式
feign:
  client:
    config:
      default: #用default就是全局配置
#     user-service: 这里写服务名称就是对某个指定的微服务生效
        loggerLevel: FULL #日志级别

方式二：Java代码方式

先声明一个类，然后声明一个Logger.Level的对象：

public class DefaultFeignConfig {
    @Bean
    public Logger.Level feignLogLevel(){
        return Logger.Level.BASIC; // 日志级别为BASIC
    }
}

如果要全局生效，将其放到启动类的@EnableFeignClients这个注解中：

@EnableFeignClients(defaultConfiguration = DefaultFeignConfig.class)

如果是局部生效，则把它放到指定的@FeignClient这个注解中：

@FeignClient(value = "user-service", configuration = DefaultFeignConfig.class)

Feign优化配置

Feign底层的客户端实现：

  • URLConnection：默认实现，不支持连接池
  • Apache HttpClient ：支持连接池
  • OKHttp：支持连接池

因此优化Feign的性能主要包括：

  1. 使用连接池代替默认的URLConnection
  2. 日志级别，最好用basic或none
连接池配置

例：Feign添加HttpClient的支持。

引入依赖：

<!--httpClient依赖-->
<dependency>
    <groupId>io.github.openfeign</groupId>
    <artifactId>feign-httpclient</artifactId>
</dependency>

配置连接池：

feign:
  httpclient:
    enabled: true   #支持httpClient
    max-connections: 200  #最大连接数
    max-connections-per-route: 50   #单个路径的最大连接数

最佳实践

观察我们之前的代码可以发现，Feign的客户端与服务提供者的controller代码非常相似：

@FeignClient(value = "user-service", configuration = DefaultFeignConfig.class)
public interface UserClient {
    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}

@GetMapping("/user/{id}")
public User queryById(@PathVariable("id") Long id) {
    return userService.queryById(id);
}

都包含接口请求方式、请求路径、请求参数这三部分。那么有什么办法可以把这部分抽取出来呢？

方式一（继承）

给消费者的FeignClient和提供者的controller定义统一的父接口作为标准。

image-20230409103129193

不过一般我们不推荐这种客户端和服务端之间共享接口的方式，主要有以下两点原因：

  • 服务紧耦合
  • 父接口参数列表中的映射不会被继承，因此Controller中必须再次声明方法、参数列表、注解
方式二（抽取）

方式二（抽取）：将FeignClient抽取为独立模块，并且把接口有关的POJO、默认的Feign配置都放到这个模块中，提供给所有消费者使用

image-20230409103917386

步骤如下：

  1. 首先创建一个module，命名为feign-api，然后引入feign的starter依赖

  2. 将order-service中编写的UserClient、User、DefaultFeignConfiguration都复制到feign-api项目中

    image-20230409110417135

  3. 在order-service中引入feign-api的依赖

    <!--引入我们自己写的feign-api-->
<dependency>
    <groupId>cn.itcast.demo</groupId>
    <artifactId>feign-api</artifactId>
    <version>1.0</version>
</dependency>

  4. 修改order-service中的所有与上述三个组件有关的import部分，改成导入feign-api中的包

  5. 重启测试…然后重启失败

    image-20230409110618605

    原因是当定义的FeignClient不在SpringBootApplication的扫描包范围时，这些FeignClient无法使用。有两种方式解决：

    方式一：指定FeignClient所在包，这种方法会把指定包下面的所有Client都加载进来

    @EnableFeignClients(basePackages = "cn.itcast.demo.client")

    方式二：指定FeignClient字节码，这种方法只会加载指定的Client

    @EnableFeignClients(clients = {UserClient.class})

Gateway网关

Spring Cloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等响应式编程和事件流技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。

为什么需要网关？

最简单的例子，有的时候我们不希望一些没有权限的请求访问到我们的微服务，这个时候就可以用网关来进行身份认证。Gateway网关是我们服务的守门神，所有微服务的统一入口。

网关的核心功能特性：

  • 请求路由：将用户请求路由到微服务，并实现负载均衡
  • 权限控制：对用户请求做身份认证、权限校验
  • 限流：控制流量

image-20230409131942514

权限控制：网关作为微服务入口，需要校验用户是是否有请求资格，如果没有则进行拦截。

路由和负载均衡：一切请求都必须先经过gateway，但网关不处理业务，而是根据某种规则，把请求转发到某个微服务，这个过程叫做路由。当然路由的目标服务有多个时，还需要做负载均衡。

限流：当请求流量过高时，在网关中按照下流的微服务能够接受的速度来放行请求，避免服务压力过大。

网关技术的实现

在SpringCloud中网关的实现包括两种：

  • gateway
  • zuul

Zuul是基于Servlet的实现，属于阻塞式编程。而SpringCloud Gateway则是基于Spring5中提供的WebFlux，属于响应式编程的实现，具备更好的性能。

Gateway网关快速入门

下面，我们就看一下网关的基本路由功能。基本步骤如下：

  1. 创建SpringBoot工程gateway，引入网关依赖

    <!--网关-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<!--nacos服务发现依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

  2. 编写GatewayApplication.java启动类

  3. 编写application.yml基础配置和路由规则

    路由配置包括：

    1. 路由id：路由的唯一标示

    2. 路由目标（uri）：路由的目标地址，http代表固定地址，lb代表根据服务名负载均衡

    3. 路由断言（predicates）：判断路由的规则，如果请求不符合这个规则会404

    4. 路由过滤器（filters）：对请求或响应做处理

    server:
  port: 10010 # 网关端口
spring:
  application: 
    name: gateway # 服务名称
  cloud:
    nacos:
      server-addr: localhost:8848 # nacos地址
    gateway:
      routes: # 网关路由配置
        - id: user-service # 路由id，自定义，只要唯一即可
          # uri: http://127.0.0.1:8081 # 路由的目标地址 http就是固定地址
          uri: lb://user-service # 路由的目标地址 lb就是负载均衡，后面跟服务名称
          predicates: # 路由断言，也就是判断请求是否符合路由规则的条件
            - Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求

  4. 启动网关服务进行测试

    直接访问10010端口即可访问到user-service服务：

    image-20230409140840990

整个访问的流程如下：

image-20230409141041964

断言工厂Route Predicate Factory

我们在配置文件中写的断言规则只是字符串，这些字符串会被Predicate Factory读取并处理，转变为路由判断的条件。例如Path=/user/**是按照路径匹配，这个规则是由org.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactory类来处理的，像这样的断言工厂在SpringCloud Gateway还有十几个。

名称说明示例
After是某个时间点后的请求- After=2037-01-20T17:42:47.789-07:00[America/Denver]
Before是某个时间点之前的请求- Before=2031-04-13T15:14:47.433+08:00[Asia/Shanghai]
Between是某两个时间点之前的请求- Between=2037-01-20T17:42:47.789-07:00[America/Denver], 2037-01-21T17:42:47.789-07:00[America/Denver]
Cookie请求必须包含某些cookie- Cookie=chocolate, ch.p
Header请求必须包含某些header- Header=X-Request-Id, \d+
Host请求必须是访问某个host（域名）- Host=.somehost.org,.anotherhost.org
Method请求方式必须是指定方式- Method=GET,POST
Path请求路径必须符合指定规则- Path=/red/{segment},/blue/**
Query请求参数必须包含指定参数- Query=name, Jack或者- Query=name
RemoteAddr请求者的ip必须是指定范围- RemoteAddr=192.168.1.1/24
Weight权重处理

当我们需要用到这些Predicate Factory的时候可以直接去查看官方文档：https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#gateway-request-predicates-factories

image-20230409145807204

过滤器工厂

过滤器的作用是什么？

  1. 对路由的请求或响应做加工处理，比如添加请求头
  2. 配置在路由下的过滤器只对当前路由的请求生效

GatewayFilter是网关中提供的一种过滤器，可以对进入网关的请求和微服务返回的响应做处理：

image-20230409150053855

Spring提供了31种不同的路由过滤器工厂。例如：

名称说明
AddRequestHeader给当前请求添加一个请求头
RemoveRequestHeader移除请求中的一个请求头
AddResponseHeader给响应结果中添加一个响应头
RemoveResponseHeader从响应结果中移除有一个响应头
RequestRateLimiter限制请求的流量

下面我们以AddRequestHeader 为例来讲解。

需求：给所有进入user-service的请求添加一个请求头：Truth=itcast is freaking awesome!

实现方式：在gateway中修改application.yml文件，给user-service的路由添加过滤器：

spring:
  cloud:
    gateway:
      routes:
      - id: user-service 
        uri: lb://user-service 
        predicates: 
        - Path=/user/** 
        filters: #过滤器
        - AddRequestHeader=Hello Gateway! #添加请求头

当前过滤器写在user-service路由下，因此仅仅对访问user-service的请求有效。

如果要对所有的路由都生效，则可以将过滤器工厂写到default-filters下：

spring:
  cloud:
    gateway:
      routes: # 网关路由配置
        - id: user-service
          uri: lb://user-service
          predicates:
            - Path=/user/** 
#          filters: #过滤器
#            - AddRequestHeader=Truth, Hello Gateway! #添加请求头
        - id: order-service
          uri: lb://order-service
          predicates:
            - Path=/order/**
      default-filters:
        - AddRequestHeader=Hello Gateway!
全局过滤器GlobalFilter

上面学习的过滤器，网关提供了31种，但每一种过滤器的作用都是固定的。如果我们希望拦截请求，做自己的业务逻辑则没办法实现。

全局过滤器的作用也是处理一切进入网关的请求和微服务响应，与GatewayFilter的作用一样。区别在于GatewayFilter通过配置定义，处理逻辑是固定的；而GlobalFilter的逻辑需要自己写代码实现。定义方式是实现GlobalFilter接口。

public interface GlobalFilter {
    /**
     *  处理当前请求，有必要的话通过{@link GatewayFilterChain}将请求交给下一个过滤器处理
     *
     * @param exchange 请求上下文，里面可以获取Request、Response等信息
     * @param chain 用来把请求委托给下一个过滤器 
     * @return {@code Mono<Void>} 返回标示当前过滤器业务结束
     */
    Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
}

在filter中编写自定义逻辑，可以实现下列功能：

  • 登录状态判断
  • 权限校验
  • 请求限流等

案例：定义全局过滤器，拦截请求，判断请求的参数是否满足下面条件：

  1. 参数中是否有authorization
  2. authorization参数值是否为admin

如果同时满足则放行，否则拦截

package com.itcast.gateway.filter;

import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.Ordered;
import org.springframework.core.annotation.Order;
import org.springframework.http.HttpStatus;
import org.springframework.http.server.reactive.ServerHttpRequest;
import org.springframework.http.server.reactive.ServerHttpResponse;
import org.springframework.stereotype.Component;
import org.springframework.util.MultiValueMap;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

/**
 * @title: AuthorizeFilter
 * @Author 
 * @Date: 2023/4/9 19:46
 * @Version 1.0
 */
@Component
// @Order(-1)  // order的值越小，优先级越高，也可以通过实现Ordered接口来设置优先级
public class AuthorizeFilter implements GlobalFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 1.获取请求参数
        ServerHttpRequest request = exchange.getRequest();
        MultiValueMap<String, String> queryParams = request.getQueryParams();
        // 2.获取authorization参数
        String authorization = queryParams.getFirst("authorization");
        // 3.判断参数值是否等于admin
        if ("admin".equals(authorization)) {
            // 4.是，放行
            return chain.filter(exchange);
        }
        // 5.否，拦截
        ServerHttpResponse response = exchange.getResponse();
        response.setStatusCode(HttpStatus.UNAUTHORIZED);
        return response.setComplete();
    }

    @Override
    public int getOrder() {
        return -1;
    }
}

测试：

image-20230409201106718

过滤器的执行顺序

请求进入网关会碰到三类过滤器：当前路由的过滤器、DefaultFilter、GlobalFilter。请求路由后，会将当前路由过滤器和DefaultFilter、GlobalFilter，合并到一个过滤器链（集合）中，排序后依次执行每个过滤器。

image-20230409203357937

排序的规则是什么呢？

  • 每一个过滤器都必须指定一个int类型的order值，order值越小，优先级越高，执行顺序越靠前。
  • GlobalFilter通过实现Ordered接口，或者添加@Order注解来指定order值，由我们自己指定
  • 路由过滤器和defaultFilter的order由Spring指定，默认是按照声明顺序从1递增。
  • 当过滤器的order值一样时，会按照 defaultFilter > 路由过滤器 > GlobalFilter的顺序执行。

详细内容，可以查看源码：

org.springframework.cloud.gateway.route.RouteDefinitionRouteLocator#getFilters()方法是先加载defaultFilters，然后再加载某个route的filters，然后合并。org.springframework.cloud.gateway.handler.FilteringWebHandler#handle()方法会加载全局过滤器，与前面的过滤器合并后根据order排序，组织过滤器链。

跨域问题
什么是跨域问题？

跨域：域名不一致就是跨域，主要包括：

  • 域名不同： www.taobao.com 和 www.taobao.org 和 www.jd.com 和 miaosha.jd.com

  • 域名相同，端口不同：localhost:8080和localhost8081

跨域问题：浏览器禁止请求的发起者与服务端发生跨域ajax请求，请求被浏览器拦截的问题。

解决方案：CORS

跨域问题处理

在gateway服务的application.yml文件中，添加下面的配置：

spring:
  cloud:
    gateway:
      globalcors: # 全局的跨域处理
        add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
        corsConfigurations:
          '[/**]':
            allowedOrigins: # 允许哪些网站的跨域请求 
              - "http://localhost:8090"
            allowedMethods: # 允许的跨域ajax的请求方式
              - "GET"
              - "POST"
              - "DELETE"
              - "PUT"
              - "OPTIONS"
            allowedHeaders: "*" # 允许在请求中携带的头信息
            allowCredentials: true # 是否允许携带cookie
            maxAge: 360000 # 这次跨域检测的有效期
周八营业的代码人
关注
  • 0
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
详解利用SpringCloud搭建一个最简单的微服务框架
08-28
主要介绍了详解利用SpringCloud搭建一个最简单的微服务框架，小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
微服务介绍(史上最全)
热门推荐
weixin_45203607的博客
12-12 7万+
1、微服务简介 简而言之，微服务架构风格是一种将单个应用程序开发为“一套小型服务”的方法，每个服务“运行在自己的进程中”，并通过轻量级机制(通常是HTTP资源API)进行通信。这些服务“围绕业务功能构建”，并通过全自动部署机制“独立部署”。“这些服务只有最低限度的集中管理”，可能是用不同的编程语言编写的，并使用不同的数据存储技术。 微服务是一种架构，这种架构是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露a
【微服务-SpringCloud】详细介绍，搭建一套微服务项目
最新发布
分享学习
06-06 1592
微服务（Microservices）是一种软件架构风格，它将一个大型的应用程序分解成一系列小的、自治的服务单元。每个服务单元都围绕着特定的业务能力构建，可以独立部署、运行和扩展，它们之间通过API（通常采用HTTP RESTful API）进行轻量级通信。这种架构风格强调服务的松耦合、高内聚和业务领域的边界清晰。Spring Cloud是Spring家族中的一个项目，它为开发人员提供了一套全面的工具和框架，用于快速构建分布式系统和微服务架构。
spring cloud搭建教程
ANGEL CITY
04-26 4万+
Spring cloud是一个基于Spring Boot实现的服务治理工具包,在微服务架构中用于管理和协调服务的微服务:就是把一个单体项目,拆分为多个微服务,每个微服务可以独立技术选型,独立开发,独立部署,独立运维.并且多个服务相互协调,相互配合,最终完成用户的价值. Spring Cloud是一系列框架的有序集合。其主要的设施有，服务发现与注册，配置中心，消息总线，负载均衡，断路器，数据监控等，通过Spring Boot的方式，可以实现一键启动，和部署。
从零开始搭建一个springCloud项目
m0_67266585的博客
08-27 7669
springCloud,相信大家已经听过很多次了，现在各种大大小小的公司都在使用的微服务框架，包括我正在上班公司的项目里面使用到的就是springCloud,此文仅对于刚入行不久的小白，大佬们可以指出里面的不足之处，废话不多说，开搞！1.首先搭建一个springCloud项目,我们需要建一个父工程,为什么要这样呢？...
手把手带你搭建第一个SpringCloud项目（一）
weixin_47025166的博客
07-02 8051
随着数据时代的发展，高访问量、高并发量越来越常见，数据量趋于海量，传统的单体应用架构有着难以理解和维护、开发效率低等缺点无法满足新时代的需求，为了更好地面对高并发海量数据的问题，便产生了微服务架构、分布式系统来面对海量的数据访问处理。 在这样的背景下，SpringCloud应运而生。对于中小型互联网公司来说，它们往往没有实力或者没有足够的资金投入去开发自己的分布式系统基础设施，而使用SpringCloud一站式解决方案能在从容应对业务发展的同时大大减少开发成本。因此，SpringCloud迅速拓宽市场面，
SpringCloud - 项目搭建
m0_66689823的博客
11-20 1808
3.创建RestFul 服务器 创建两个微服务子模块，一个订单模块，一个支付模块创建第一个模块：支付模块修改支付模块的POM文件 3.1.3 写YML 3.1.4 主启动 3.1.5 业务类 查看具体git：https://gitee.com/jm1107/cloud2022 3.2.3 写YML 3.2.4 主启动 3.2.5 业务类 查看具体git：https://gitee.com/jm1107/cloud2022问题:系统中存在重复部分创建一个公共使用的子模块，将通用的实体类、工具类，以及第
SpringCloud微服务架构笔记（四
03-18
【Spring Cloud微服务架构笔记（四）】 在微服务架构中，Spring Cloud Stream是一个关键组件，它为企业级...在实际开发中，结合Spring Cloud Stream，我们可以快速构建出具备高性能、高可用、可伸缩特性的微服务架构。
一个springCloud搭建微服务的入门样例 Eurake服务的java样例——亲测可用
06-17
通过这个样例，你可以了解到如何在SpringCloud环境中使用Eureka进行服务的注册和发现，以及微服务架构中的基本操作。实际应用中，还需要结合其他SpringCloud组件，如Zuul、Hystrix、Config等，构建更加完善的微服务...
springcloud基于微服务架构的乐居租房网的设计与实现.zip
12-26
本项目——"乐居租房网"，便是以SpringCloud为核心，构建了一个高度模块化、可扩展的微服务架构，旨在提供高效、稳定且易维护的在线租房服务。下面将详细介绍这个项目的实现细节和技术要点。 首先，SpringCloud作为...
Sring Cloud入门（一）注册中心 Eureka
10-19
在微服务架构中，Spring Cloud是一个非常重要的框架集合，它为开发者提供了构建分布式系统所需的工具。本篇文章将重点介绍Spring Cloud中的一个关键组件——Eureka，它是Spring Cloud的注册中心，用于服务发现和服务...
springCloud入门基本代码（基础篇）
12-01
在本压缩包“SpringCloud入门基本代码（基础篇）”中，我们将会探索Spring Cloud的基础概念和实践。Spring Cloud是一个微服务开发工具集，它为开发者提供了在分布式系统（如配置管理、服务发现、断路器、智能路由、...
SpringCloud(一)微服务项目搭建
m0_64393446的博客
07-17 2352
SpringCloud是Spring提供的一套分布式解决方案，集合了一些大型互联网公司的开源产品，包括诸多组件，共同组成SpringCloud框架。并且，它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、熔断机制、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
SpringCloud 项目搭建过程
apmvn的博客
04-25 2445
spring cloud基本的环境搭建教程。
手把手教你搭建SpringCloud项目（一）图文详解
zhaoshuangjian
07-17 5383
手把手教你搭建SpringCloud项目（一）图文详解
SpringCloud微服务第1章
iijik55的博客
07-28 651
微服务(microservice)一词最早由MartinFowler与JamesLewis于2014年共同提出来的，它是一种新的软件架构风格，就是把一个大型应用程序分割成可以独立部署的小型服务，每个服务之间都是松耦合的，通过RPC或者是Rest协议来进行通信，可以按照业务领域来划分成独立的单元，比如一个电商系统可以分割成会员、订单、商品、积分、优惠券等不同的小型服务，有自动化运维、容错、快速演进的特点，它能够解决传统单体架构系统的痛点，同时也能满足越来越复杂的业务需求。组件的集合。启动器是基于。...
SpringCloud微服务项目实战(一)---搭建SpringBoot项目
xiaobai178的博客
06-28 4439
问题：新建子模块后，pom文件的图标是xml文件标识，而不是m标识，而且目录结构是com-xxx-xxx这样一层一层的，而不是package包名一起的解决：idea工作台左侧右键pom文件，点击Add As Maven Project，如下图问题：删除子模块后，再新增同样名称的子模块，pom文件不生效且出现了删除线。解决：File–Settings–Build–Maven–IgnoredFiles中将对勾取消，如下图。
【迎五一】超大福利来啦，众多精美课程、礼品等你来领
CSDN能力认证官方博客
04-27 3559
C认证助力程序员，五一特惠活动来啦！！ 单人报名可免费获得【电子书月卡】一份 组团报名皆可获得技术图书一本+无限次补考机会 带新用户报名皆可获得技术图书一本+精品网课 活动时间：4月26日-5月15日 心动不如行动，点击文末卡片立即了解 CSDN云原生能力认证介绍 2022年3月31日，中国专业IT开发者社区CSDN（以下简称C站）正式推出“C站云原生工程师能力认证”，旨在帮助考生快速掌握云原生开发技能，重点考核容器、DevOps、微服务应用等技术。此标准下，CSDN将为千行百业贡献更多云..

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值