第一章（微服务、服务拆分及远程调用、Eureka注册中心、Ribbon负载均衡、Nacos注册中心）

一：微服务架构演变

1.1：单体架构

1.1.1：简介

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

1.1.2：优点

• 结构简单
• 部署成本低

1.1.3：缺点

• 耦合度高

1.2：分布式架构

1.2.1：简介：

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

• 

1.2.2：优点：

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

1.2.3：缺点：

• 分布式架构要考虑的问题

  • 服务拆分粒度如何？

  • 服务集群地址如何维护？

  • 服务之间如何实现远程调用？

  • 服务健康状态如何感知？

1.3：微服务架构

1.3.1：简介：

• 微服务是一种经过良好架构设计的分布式架构方案，微服务架构特征：

• **单一职责：**微服务拆分粒度更小，每一个服务都对应唯一的业务能力，能做到单一职责，避免重复业务开发。

• **面向服务：**微服务对外暴露业务接口

• **自治：**团队独立、技术独立、数据独立、部署独立

• 

• 单体架构特点？

  • 简单方便、高度耦合、扩展性差、适合小型项目。例如：学生管理系统

• 分布式架构特点？

  • 松耦合、扩展性好、但架构复杂、难度大。适合大型互联网项目。例如：京东、淘宝。

• 微服务：一种良好的分布式架构方案。

• 优点：拆分粒度小、服务更独立、耦合度更低

• 缺点：架构非常复杂、运维、监控、部署难度提高

• 微服务架构

  • 微服务架构这种方案需要技术框架来落地，全球的互联网公司都在积极尝试自己的微服务落地技术。在国内最知名的就是SpringCloud和阿里巴巴的Dubbo。
  • 

1.3.2：微服务技术对比

• 
• 企业需求
  • SpringCloud+Feign
    • 使用SpringCloud技术栈
    • 服务接口采用Restful风格
    • 服务调用采用Feign方式
  • SpringCloudAlibaba+Feign
    • 使用SpringCloudAlibaba技术栈
    • 服务接口采用Restful风格
    • 服务调用采用Feign方式
  • SpringCloudAlibabab+Dubbo
    • 使用SpringCloudAlibaba技术栈
    • 服务接口采用Dubbo协议标准
    • 服务调用采用Dubbo方式
  • Dubbo原始模式
    • 基于Dubbo老旧技术体系
    • 服务接口采用Dubbo协议标准
    • 服务调用采用Dubbo方式
• 

1.3.3：SpringCloud

• SpringCloud
  • SpringCloud是目前国内使用最广泛的微服务框架。官网地址。
  • SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了组件的自动装配，从而提供了良好的开箱即用体验。
  • 
  • SpringCloud与SpringBoot的版本兼容关系如下：
  • 

二：服务拆分及远程调用

2.1：服务拆分

2.1.1：服务拆分注意事项

1. 不同微服务，不能重复开发相同业务。
2. 微服务数据独立，不要访问其他服务的数据库。
3. 微服务可以将自己的业务暴露为接口，供其他微服务调用。

2.1.2：案例

• 导入服务拆分Demo
  1. 导入课前资料提供的工程：cloud-demo
  2. 项目结构
     • 
  3. 将课前资料准备的SQl导入数据库中
     • cloud-user.sql
     • cloud-order.sql

2.1.3：总结

1. 微服务需要根据业务模块拆分，做到单一职责，不要重复开发相同业务
2. 微服务可以将业务暴露为接口，供其他微服务使用
3. 不同微服务都应该有自己独立的数据库

2.2：服务间调用

2.2.1：案例

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

2.2.2：流程

1. 根据订单id查询订单和用户
2. 根据用户id查询用户

• 
• 远程调用方式分析
  • 
• 步骤
  1. 注册RestTemplate
     • 在order-service的OrderApplication中注册RestTemplate
     • 
  2. 服务远程调用RestTemplate
     • 修改order-service中的OrderService的queryOrderById方法
     • 

2.2.3：总结

• 微服务调用方式
  • 基于Restemplate发起的http请求实现远程调用
  • http请求做远程调用是与语言无关的调用，只要知道对方的ip、端口、接口路径、请求参数即可。

2.3：提供者与消费者

2.3.1：服务提供者：

• 服务提供者：一次业务中，被其他微服务调用的服务。（提供接口给其他微服务）

2.3.2：服务消费者

• 服务消费者：一次业务中，调用其他微服务的服务。（调用其他微服务提供的接口）

• 

2.3.3：思考

• 服务A调用服务B，服务B调用到服务C，那么服务B是什么角色？
  • 抛开业务不谈，任何一个服务既可以是消费者也可以是提供者。

2.3.4：总结

• 服务调用关系
  • 服务提供者：暴露接口给其他服务调用
  • 服务消费者：调用其他微服务提供的接口
  • 提供者与消费者角色其实是相对的
  • 一个服务可以同时是服务提供者与消费者

三：Eureka注册中心

3.1：远程调用的问题

3.1.1：服务调用出现的问题

• 服务消费者该如何获取服务提供者的地址信息？
• 如果有多个服务提供者，消费者该如何选择？
• 消费者如何感知服务提供者的健康状态？
  • 

3.2：Eureka的作用

3.2.1：解决服务调用问题

• 

• 消费者该如何获取服务提供者具体信息？

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

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

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

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

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

3.2.2：总结：

• 在Eureka架构中，微服务角色有两类：
  • EurekaService：服务端，注册中心
    • 记录服务信息
    • 心跳监控
  • EurekaClient：客户端
    • Provider：服务提供者，例如案例中的user-service
      • 注册自己的信息到EurekaService
      • 每隔30秒向EurekaServer发送心跳
    • consumer：服务消费者，例如案例中的order-service
      • 根据服务名称从EurekaService拉取服务列表
      • 基于服务列表做负载均衡，选中一个微服务后发起远程调用

3.3：搭建EurekaServer

3.3.1：搭建流程

1. 搭建注册中心
   • 搭建EurekaServer
2. 服务注册
   • 将user-service、order-service都注册到eureka
3. 服务发现
   • 在order-service中完成服务拉取，然后通过负载均衡挑选一个服务，实现远程调用

3.3.2：搭建EurekaServer

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

   • 

2. 编写启动类，添加**@EnableEurekaServer**注解

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

   • 

• 总结：

  • 引入eureka-service依赖
  • 添加@EnableEurekaServer注解
  • 在application.yml中配置eureka地址

3.3.3：服务注册

1. 在user-service项目引入spring-cloud-starter-netflix-eureka-client的依赖
   • 
2. 在application.yml文件，编写下面的配置
   • 

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

• 

• 

• order-service完成服务注册

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

1. 在order-service项目怒中引入spring-cloud-starter-netflix-eureka-client的依赖
   • 
2. 在application.yml文件，编写下面的配置
   • 

• 总结
  • 服务注册
    • 引入eureka-client依赖
    • 在application.yml中配置eureka地址
  • 无论是消费者还是提供者，引入eureka-client依赖、知道eureka地址后，都可以完成服务注册

3.3.4：服务发现

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

1. 修改OrderService的代码，修改访问的url路径，用服务名代替ip、端口
   • 
2. 在order-service项目的启动类OrderApplication中的RestTemplate添加负载均衡注解
   • 

3.3.5：总结

1. 搭建EurekaServer
   • 引入eureka-server依赖
   • 添加@EnableEurekaServer注解
   • 在application.yml中配置eureka地址
2. 服务注册
   • 引入eureka-client依赖
   • 在application.yml中配置eureka地址
3. 服务发现
   • 引入eureka-client依赖
   • 在application.yml中配置eureka地址
   • 给RestTemplate添加@LoadBalanced注解
   • 用服务提供者的服务名称远程调用

四：Ribbon负载均衡

4.1：负载均衡流程

• 
• 

4.2：负载均衡策略

• Ribbon的负载均衡规则是一个叫做IRule的接口来定义的，每一个子接口都是一种规则

  • 

  • 内置负载均衡规则类	规则描述
    RoundRobinRule	简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。
    AvailabilityFilteringRule	对以下两种服务器进行忽略： （1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。 （2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的..ActiveConnectionsLimit属性进行配置。
    WeightedResponseTimeRule	为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。
    ZoneAvoidanceRule	以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。
    BestAvailableRule	忽略那些短路的服务器，并选择并发数较低的服务器。
    RandomRule	随机选择一个可用的服务器。
    RetryRule	重试机制的选择逻辑

4.3：自定义负载均衡策略

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

  1. 代码方式：在order-service中的OrderApplication类中，定义一个新的IRule：
  • 
  2. 配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：
  • 

4.4：饥饿加载

• Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。而饥饿加载会在项目启动时创建，降低第一次访问的耗时，通过下面配置开饥饿加载：
• 

4.5：总结

1. Ribbon负载均衡规则
   • 规则接口是IRule
   • 默认实现是ZoneAvoidanceRule，根据zone选择服务列表，然后轮询
2. 负载均衡自定义方式
   • 代码方式：配置灵活，但修改时需要重新打包发布
   • 配置方式：直观，方便，无需重新打包发布，但是无法做全局配置。
3. 饥饿加载
   • 开启饥饿加载
   • 指定饥饿加载微服务名称

五：Nacos注册中心

5.1：认识安装Nacos

5.1.1：认识Nacos

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

5.1.2：安装Nacos

1. 下载Nacos压缩包

   • 

2. 进入bin目录

   • 

3. 单机模式启动nacos

   • .\startup.cmd -m standalone
     

   • 

4. 访问Nacos

   • Nacos访问
   • 账号密码都为【nacos】
   • 

5.1.3：服务注册到Nacos

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

   • <dependency>    
         <groupId>com.alibaba.cloudgroupId>
         <artifactId>spring-cloud-alibaba-dependenciesartifactId>
         <version>2.2.6.RELEASEversion>
         <type>pomtype>
         <scope>importscope>
     dependency>
     

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

3. 添加nacos的客户端依赖

   • 
     <dependency>
         <groupId>com.alibaba.cloudgroupId>
         <artifactId>spring-cloud-starter-alibaba-nacos-discoveryartifactId>
     dependency>
     

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

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

5. 启动并测试

   • 

5.1.4：总结

• Nacos服务搭建
  1. 下载安装包
  2. 解压
  3. 在bin目录下运行指令：startup.cmd -m standalone
• Nacos服务注册和发现
  1. 引入nacos.discovery依赖
  2. 配置nacos地址spring.cloud.nacos.server-addr

5.2：Nacos服务分级存储模型

• 

5.2.1：服务跨集群问题

• 服务调用尽可能选择本地集群的服务，跨集群调用延迟较高。本地集群不可访问时，再去访问其它集群

• 

• 服务集群属性

  1. 修改application.yml 添加如下内容

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

  2. 在Nacos控制台可以看到集群变化

     • 

5.2.2：总结

• Nacos服务分级存储模型
  1. 一级时服务，例如userservice
  2. 二级是集群，例如杭州或上海
  3. 三级是实例，例如杭州机房的某台部署了userservice的服务器
• 如何设置实例的集群属性
  1. 修改application.yml文件，添加spring.cloud.nacos.discover.cluster-name属性即可。

5.3：服务集群属性

• 我们修改user-service集群属性配置，达到下面的效果

  • 

5.3.1：根据集群负载均衡

1. 修改order-service中的application.yml 设置集群为HZ

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

2. 然后在order-service中设置负载均衡的IRule为NacosRule，这个规则优先会寻找与自己同集群的服务

   • userservice:
       ribbon:
         NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则 
     

5.3.2：总结

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

5.4：根据权重负载均衡

5.4.1：遇见问题

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

1. 在Nacos控制台可用设置实例的权重值，首先选中实例后面的编辑按钮
   • 
2. 将权重设置为0.1，测试可以发现8081被访问到的频率大大降低
   • 

5.4.2：总结：

1. Nacos控制台可以设置实例的权重值，0~1之间
2. 同集群内的多个实例，权重越高被访问的频率越高
3. 权重设置为0则完全不会被访问

5.5：Nacos命名空间

5.5.1：环境隔离-namespace

• Nacos中服务存储和数据存储的最外层都是一个名为namespace的东西，用来做最外层隔离

• 

1. 在Nacos控制台可以创建namespace,用来隔离不同环境
   • 
2. 然后填写一个新的命名空间信息
   • 
3. 保存后会在控制台看到这个命名空间的id
   • 
4. 修改order-service的application.yml，添加namespace
   • 
5. 重启order-service后，再来看控制台
   • 
   • 
6. 此时访问order-service，因为namespace不同，会导致找不到user-service，控制台会报错
   • 

5.5.2：总结

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

5.6：Nacos注册中心细节分析

5.6.1：分析

• 

5.6.2：非临时实例

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

• 21

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

5.7：Nacos与Eureka

5.7.1：Nacos与Eureka的共同点

1. 都支持服务注册和服务拉取
2. 都支持服务提供者心跳方式做健康监测

5.7.2：Nacos与Eureka的区别

1. Nacos支持服务端主动监测提供者状态
   • 临时实例，采用心跳模式，非临时实例采用主动检测模式
2. 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
3. Nacos支持服务列表变更的消息推送模式，服务表更新更及时
4. Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式。

​