SpringCloud（1）-CFANZ编程社区

SpringCloud（1）

配置注册服务中心

服务注册中心：

对于服务集群，肯定是不能直接通过用户直接访问的，一来，是因为管理麻烦（就好像你去取快递，但是顺丰只是将你的快递和别的快递杂乱的堆在一堆，你是不是顿时感到MMP了），当然顺丰也不傻，他给你提供一个快递号，然后为你提供一个存储快递的管理员或者快递货架，这样你就可以通过快递号取的你要的快递了。

服务结群的访问与之大相径庭，将所有的服务都编辑上一个唯一的服务名（也就是通过服务名找到某种服务，为什么是某种呢？因为服务也不会只有一个呀，那不得宕机了这个服务就失效了）然后提供一个货架或者管理员，方便告诉你这个服务在什么位置，你取得你要的服务嘛。所以他来了，这个货架不就是服务注册中心嘛！

当然，给你的话你也要装配一下啊，要不然就是空货架啦！

好，进入正题：

像Euerka这样的服务注册中心是直接基于springBoot做开发的。可以直接使用application.yml来配置服务注册中心。而想nacos这样使用第三方技术做服务注册的，是不是要先告诉程序这个配置中心在哪呢？而且我们会知道集群中的配置都是统一配置的，也就是存在一个配置中心，（可以支持不停机更新配置）,那有怎么知道配置改啦呢？是不是在导入application配置的时候就要先告诉application配置某些配置要怎么改，你记得改一下。。。这多么和谐！

所以，我们需要配置一下bootstrap.yml;

怎么说呢，以我的理解来说，bootstrap就是将application拆开了，并且bootstrap的配置优先级在application之前，这样也就产生了bootstrap先对application配置，在application对服务配置。有兴趣的小伙伴可以查下资料（苟富贵，勿相忘，还得请各位大佬不要忘记告诉偶一声哈），这样解释并不清晰，直接上图：

在这里插入图片描述

也就是先走了bootstrap在然后走到application。

配置的bootstrap:

spring:
	application:
		name: nacos-services-center
	cloud:
		nacos:
			config:
				server-addr: localhost:8848 #这里的8848是nacos的默认端口
				namespace: 
				group: 
				file-extension: yml
				refresh-enabled: true
				prefix: dev

对上述的参数做一下解析：

还有一点：在nacos中，如果配置的运行环境是active，这要注意他的name具体是：

在这里插入图片描述
嘿嘿，是不是配置的是配置了，但是却全是警告，如果说程序员不怕警告，那么你可以试试。所以要添加nacos的依赖哇：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
    <version>${latest.version}</version>
</dependency>
<dependency>   
	<groupId>com.alibaba.cloud</groupId>   
	<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>   
    <version>${latest.version}</version> 
</dependency>

好吧，这只是nacos服务中心，接下来进入服务配置

服务提供者和服务消费者：

服务提供者：

对于所有的服务来说：他们既是消费者又是提供者，所以，搭建服务集群也需要配置，集群集群，这肯定很多啊，所以就会有一个配置中心，而且这个配置中心也要预先告诉这些服务吧，所以bootstrap又要上场给服务加配置啦。

所以说上文应该就是介绍一下注册中心。

接下来我们看看这个服务提供者是什么？

对于一个集中式的项目，要迭代成为集群（因为单体已经无法支撑啦），所以就要将它拆分，而具体的细粒度就要根据业务需求来具体设定了，拆分好的项目应该是相互独立的，而且一会配合一个数据库，也就是独立的服务独立的数据。

但是往往一些服务就要调用另外一些服务，就比如在一个学生信息查询服务里面，调出来的学生没有成绩支持，也就是成绩会为空，这显然不是我们要看的。所以，学生信息查询服务就会去调用成绩信息查询，这样在所有的服务集群里面就会有一系列的服务链，当然，各个服务都会是集群，具体的链接也就是通过服务名，然后均衡负载去调用，均衡负载的话我们后面接着讨论。

回到服务提供者：

也就是通过一个服务(customer)调用另一个服务（provider）,而这里的provider就是这里的服务提供者，旨在为另一个服务提供一些必要的服务。

开始配置：

server:
  port: 8001
spring:
  application:
    name: server_02   # 服务名称,具体服务唯一识别，通过这个就可已找到这个服务
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: dev_02 # 集群名称

server_01: #配置负载均衡规则，这里是server_01服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则
ribbon:
  eager-load:
    enabled: true # 开启饥饿加载
    clients:
      - server_01 # 指定饥饿加载的服务名称

服务消费者：

对应的提供者，消费者就是使用提供者的服务。

而服务中的配置并没有如何去标注是提供者还是消费者。就是因为服务既是提供者也是消费者。

server:
  port: 8002
spring:
  application:
  	name: server_01   # 服务名称
  cloud:
 	nacos:
	  server-addr: localhost:8848
	  discovery:
		cluster-name: dev_01 # 集群名称

配置中心：

细想一下，这么多服务，刚开始写那没办法，那要是更新的话不得一个一个更改配置，然后一个一个重启，想想都慢，想想都累，算啦，我们都感觉麻烦，更别说企业了，所以这个配置中心就来了，主要是通过配置中心更新配置，然后实现不停机更新。对于euerka来说，需要另配一个配置中心，但是nacos不同，他是集成了配置中心的。

在这里插入图片描述

这里的server_01为自定义服务配置名

-dev表示运行的环境

.yaml表示配置文件的后缀名

好吧，这个服务的配置热部署ok了

然后要继续更改原来的程序，编写bootstrap.yml，用来先告知注册中心的位置，后面就可以通过配置中心来不停机更改一些指定配置啦

spring:
  application:
    name: server_02 # 服务名称
  profiles:
    # 环境设置：dev、test、prod
    active: dev #开发环境，这里是dev
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
#      discovery:
#        cluster-name: dev_02 # 集群名称
      config:
        file-extension: yaml # 文件后缀名