单体架构：

• 将业务的所有功能集中在一个项目中开发，打成一个包部署。
• 优点：架构简单，部署成本低。
• 缺点：耦合度高。

分布式架构：

• 根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，成为一个服务
• 优点：降低服务耦合，有利于服务升级拓展

微服务：

• 微服务是一种经过良好结构设计的分布式架构方案，微服务架构特征：
• 单一职责：微服务拆分力度更小，每一服务都对应唯一的业务能力，做到单一职责，避免重复业务开发
• 面向服务：微服务对外暴露业务接口
• 自治：团队独立、技术独立、数据独立、部署独立
• 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

微服务结构：

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

Dubbo：

1. 注册中心：zookeeper、Redis
2. 服务远程调用：Dubbo 协议
3. 配置中心：无
4. 服务网关：无
5. 服务监控和保护：dubbo-admin，功能弱

SpringCloud：

1. 注册中心：Eureka、Consul
2. 服务远程调用：Feign (http 协议)
3. 配置中心：SpringCloudConfig
4. 服务网关：SpringCloudGateway、Zuul
5. 服务监控和保护：Hystrix

SpringCloudAlibaba：

1. 注册中心：Nacos、Eureka
2. 服务远程调用：Dubbo、Feign
3. 配置中心：SpringCloudConfig、Nacos
4. 服务网关：SpringCloudGateway、Zuul
5. 服务监控和保护：Sentinel

SpringCloud：

是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud
SpringCloud 继承了各种微服务功能组件，并基于 SpringBoot 实现了这些组件的自动装配，从而提供了良好的开箱即用体验：
– 服务注册发现：Eureka、Nacos、Consul
– 服务远程调用：OpenFeign、Dubbo
– 服务链路监控：Zipkin、Sleuth
– 统一配置管理：SpringCloudConfig、Nacos
– 统一网关路由：SpringCloudGateway、Zuul
– 流控、降级、保护：Hystix、Sentinel

SpringCloud 与 SpringBoot 的版本兼容关系如下：

服务拆分注意事项：

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

微服务远程调用：

• 基于 RestTemplate 发起的 http 请求实现远程调用
• http 请求交作远程调用是与语言无关的调用，只要指导对方的 ip、端口、接口路径、请求参数即可

1. 注册 RestTemplate

在 order-service 的 OrderApplication 中注册 RestTemplate

OrderApplication.java
 
@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }
    /**
     * 创建RestTemplate并注入Spring容器
     */
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

				

					
				
				

					
				
				

					
				
				

					
				
			

2. 服务远程调用 RestTemplate

修改 order-service 中的 OrderService 的 queryOrderById 方法：

OrderService.java
 
@Autowired
private RestTemplate restTemplate;
 
public Order queryOrderById(Long orderId) {
    // 1.查询订单
    Order order = orderMapper.findById(orderId);
    // 2.利用RestTemplate发起http请求，查询用户
    // 2.1.url路径
    String url = "http://localhost:8081/user/" + order.getUserId();
    // 2.2.发送http请求，实现远程调用
    User user = restTemplate.getForObject(url, User.class);        //(url,返回值类型)
    // 3.封装user到Order
    order.setUser(user);
    // 4.返回
    return order;
}

				

					
				
				

					
				
				

					
				
				

					
				
			

提供者与消费者：

• 服务提供者：一次业务中，被其他微服务调用的服务 (提供接口给其他微服务)
• 服务消费者：一次业务中，调用其他微服务的服务 (调用其他微服务提供的接口)
• 提供者与消费者角色其实是相对的，一个服务可以同时是服务提供者和服务消费者

eureka 的作用：

1. 服务消费者该如何获取服务提供者的地址信息？
   • 服务提供者启动时向 eureka 注册自己的信息
   • eureka 保存这些信息
   • 消费者根据服务名称向 eureka 拉取提供者信息
2. 如果有多个服务提供者，消费者该如何选择？
   • 服务消费者利用负载均衡算法，从服务列表中挑选一个
3. 消费者如何得知服务提供者的健康状态？
   • 服务提供者会每隔 30 秒向 EurekaServer 发送心跳请求，报告健康状态
   • eureka 会更新记录服务列表信息，心跳不正常会被剔除
   • 消费者就可以拉渠道最新的信息

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

1. EurekaServer：服务端，注册中心
   • 记录服务信息
   • 心跳监控
2. EurekaClient：客户端
   • provider：服务提供者，例如案例中的 user-service
     • 注册自己的信息到 EurekaServer
     • 每隔 30 秒向 EurekaServer 发送心跳
   • consumer：服务消费者，例如案例中的 order-service
     • 根据服务名称从 EurekaServer 拉取服务列表
     • 根据服务列表作负载均衡，选一个微服务后发起远程调用

搭建 EuerkaServer：

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: eurekaserver # eureka的服务名称
eureka:
  client:
    service-url:  # eureka的地址信息
      defaultZone: http://127.0.0.1:10086/eureka

				

					
				
				

					
				
				

					
				
				

					
				
			

注册 user-service：

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: userserver # user的服务名称
eureka:
  client:
    service-url:  # user的地址信息
      defaultZone: http://127.0.0.1:10086/eureka

				

					
				
				

					
				
				

					
				
				

					
				
			

3. 另外，我们可以将 user-service 多次启动，模拟多实例部署，但为了避免端口冲突，需要修改端口设置：
   Serices窗口中，选中UserApplication右键点击Copy Configuration；修改Environment中的VM options项为：-Dserver.port=8082

在 order-service 完成服务拉取：

服务拉取是基于服务名称获取服务列表，然后在对服务列表做负载均衡
1. 修改 OrderService 的代码，修改访问的 url 路径，用服务名代替 ip、端口：
String url = "http://userservice/user/" + order.getUserId();

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

@Bean
@LoadBalanced
public RestTemplate restTemplate() {
    return new RestTemplate();
}

				

					
				
				

					
				
				

					
				
				

					
				
			

Eureka 总结：

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

Ribbon 负载均衡：

负载均衡流程：

oeder-service
        1. 发起请求：http://userservice/user/1
到RibbonLoadBanlancerclient
        2. 获取url中的服务id：userservicr
到DynamicServerListLoadBalancer
        3. 拉取userservice
        4. 返回服务列表localhost:8081、localhost8082
到DynamicServerListLoadBalancer
        5. 服务器负载均衡localhost:8081、localhost8082
到IRule
        6. 选择某个服务localhost:8081
到RibbonLoadBanlancerclient
        7. 修改url，发起请求：http://localhost:8081/user/1
        8. 请求到8081或8082
到user-service8081或user-service8082

				

					
				
				

					
				
				

					
				
				

					
				
			

负载均衡策略：

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

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

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

@Bean
public IRule randomRule(){
        return new RandomRule();
}

				

					
				
				

					
				
				

					
				
				

					
				
			

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

userservice:
  ribbon: 
    NFLoadBalancerRuleClassName:com.netflix.loadbalancer.RandomRule #负载均衡规则

				

					
				
				

					
				
				

					
				
				

					
				
			

饥饿加载：

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

ribbon:
  eager-load:
    enabled: ture # 开启饥饿加载
    clients: userservice # 指定对userservice这个服务饥饿加载

				

					
				
				

					
				
				

					
				
				

					
				
			

Ribbon 总结：

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