什么是微服务？ – pidanxia’ s Blog

单体架构：

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

分布式架构：

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

微服务：

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

微服务结构：

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

Dubbo：

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

SpringCloud：

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

SpringCloudAlibaba：

注册中心：Nacos、Eureka
服务远程调用：Dubbo、Feign
配置中心：SpringCloudConfig、Nacos
服务网关：SpringCloudGateway、Zuul
服务监控和保护：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的版本兼容关系如下：

ReleaseTrain	BootVersion
2020.0.x aka ilford	2.4.x
Hoxton	2.2.x,2.3.x(Starting with SR3.5；SR5用2.2.x、SR5以上用2.3.x)
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x

服务拆分注意事项：

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

微服务远程调用：

基于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的作用：

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

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

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

搭建EuerkaServer：

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

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

编写启动类，添加@EnableEurekaServer注解
添加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：

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

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

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

spring:
  application:
    name: userserver # user的服务名称
eureka:
  client:
    service-url:  # user的地址信息
      defaultZone: http://127.0.0.1:10086/eureka

另外，我们可以将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();

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

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

Eureka总结：

搭建EurekaServer
1. 引入eureka-server依赖
2. 添加@EnableEurekaServer注解
3. 在application.yml中配置eureka地址
服务注册
1. 引入eureka-client依赖
2. 在application.yml中配置eureka地址
服务发现
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

负载均衡策略：

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

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

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

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

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

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

饥饿加载：

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

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

Ribbon总结：

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

皮蛋侠

一个有梦想的程序员~~

单体架构：

分布式架构：

微服务：

微服务结构：

Dubbo：

SpringCloud：

SpringCloudAlibaba：

SpringCloud：

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

服务拆分注意事项：

微服务远程调用：

1. 注册RestTemplate

2. 服务远程调用RestTemplate

提供者与消费者：

eureka的作用：

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

搭建EuerkaServer：

注册user-service：

在order-service完成服务拉取：

Eureka总结：

Ribbon负载均衡：

负载均衡流程：

负载均衡策略：

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

饥饿加载：

Ribbon总结：

发送评论编辑评论

单体架构：

分布式架构：

微服务：

微服务结构：

Dubbo：

SpringCloud：

SpringCloudAlibaba：

SpringCloud：

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

服务拆分注意事项：

微服务远程调用：

1. 注册RestTemplate

2. 服务远程调用RestTemplate

提供者与消费者：

eureka的作用：

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

搭建EuerkaServer：

注册user-service：

在order-service完成服务拉取：

Eureka总结：

Ribbon负载均衡：

负载均衡流程：

负载均衡策略：

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

饥饿加载：

Ribbon总结：

发送评论 编辑评论

推荐文章

发送评论编辑评论