一、微服务入门

从架构层次原因来说:因为单体架构耦合度高(维护困难、升级困难)才会选择根据业务功能对系统进行拆分(分布式架构);但是因为服务调用关系错综复杂,才会诞生出微服务;
微服务的其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合;微服务是一种经过良好架构设计的分布式架构方案

1、架构介绍:

1.1.单体架构

单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。
单体架构的优缺点如下：
优点：

• 架构简单
• 部署成本低

缺点：

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

1.2.分布式架构

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

分布式架构的优缺点：

优点：

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

缺点：

• 服务调用关系错综复杂

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

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

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

1.3.微服务

微服务的架构特征：

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

2、SpringCloud

2.1.SpringCloud简介

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

组件包括:

服务注册发现:Enreka、Nacos、Consul
服务远程调用:OpenFeign、Dubbo
服务链路监控:Zipkin、Sleuth
统一配置管理:SrpingCloudConfig、Nacos
同一网关路由:springCloudGateway、Zuul
流控、降级、保护:Hystix、Sentinel

2.2.分布式架构和SpringCloud、SpringBoot的关系

分布式架构是架构模式,springcloud是分布式架构的实现方法.springboot是整合了springcloud用作快速部署项目

3、服务拆分和远程调用

3.1.服务拆分原则

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

3.1.实现远程调用

被调用模块与调用模块通过http请求获取数据;
调用者使用RestTemplate发送请求到被调用者;
被调用者响应数据给调用者;
调用者对响应进行封装处理

3.2.提供者和消费者

上述中的被调用者就是服务提供者;
服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）
上述中的调用者就是服务消费者
服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）

4、Eureka注册中心(注册,发现,监控)

4.1.Eureka的结构和作用

问题1：order-service如何得知user-service实例地址？

获取地址信息的流程如下：

• user-service服务实例启动后，将自己的信息注册到eureka-server（Eureka服务端）。这个叫服务注册
• eureka-server保存服务名称到服务实例地址列表的映射关系
• order-service根据服务名称，拉取实例地址列表。这个叫服务发现或服务拉取

问题2：order-service如何从多个user-service实例中选择具体的实例？

• order-service从实例列表中利用负载均衡算法选中一个实例地址
• 向该实例地址发起远程调用

问题3：order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？

• user-service会每隔一段时间（默认30秒）向eureka-server发起请求，报告自己状态，称为心跳
• 当超过一定时间没有发送心跳时，eureka-server会认为微服务实例故障，将该实例从服务列表中剔除
• order-service拉取服务时，就能将故障实例排除了

注意：一个微服务，既可以是服务提供者，又可以是服务消费者，因此eureka将服务注册、服务发现等功能统一封装到了eureka-client端

4.2.搭建eureka-server

步骤:
1、创建maven子模块
2、导入eureka依赖
org.springframework.cloud spring-cloud-starter-netflix-eureka-server
3、编写启动类idea插件自动生成;类上加@EnableEurekaServer注解
4、编写application.yml配置文件,内容如下:
server: port: 10086 spring: application: name: eureka-server eureka: client: service-url: defaultZone: http://127.0.0.1:10086/eureka
5、启动服务,浏览器访问http://localhost:8080

4.3.服务注册

步骤:
1、在服务提供者引入依赖
org.springframework.cloud spring-cloud-starter-netflix-eureka-client
2、修改服务提供者配置文件添加服务名称、eureka地址：
spring: application: name: userservice eureka: client: service-url: defaultZone: http://127.0.0.1:10086/eureka

4.4.服务发现

步骤:
1、在服务消费者的pom文件中导入依赖
org.springframework.cloud spring-cloud-starter-netflix-eureka-client
2、修改服务消费者的配置文件,添加服务名称、eureka地址
spring: application: name: orderservice eureka: client: service-url: defaultZone: http://127.0.0.1:10086/eureka

4.5.服务拉取和负载均衡

最后，我们要去eureka-server中拉取user-service服务的实例列表，并且实现负载均衡。
不过这些动作不用我们去做，只需要添加一些注解即可。
在order-service的OrderApplication中，给RestTemplate这个Bean添加一个@LoadBalanced注解：

修改restTemplate的服务名称
public Order queryOrderById(Long orderId) { // 1.查询订单 Order order = orderMapper.findById(orderId); // 2.远程查询user //服务名称 String url = “http://userservice/user/"+order.getUserId(); User user = restTemplate.getForObject(url, User.class); //设置参数 order.setUser(user); // 4.返回 return order; }

5、Ribbon负载均衡

5.1.负载均衡原理-过滤器

SpringCloud底层其实是利用了一个名为Ribbon的组件，来实现负载均衡功能的。

5.2.负载均衡策略

默认的实现就是ZoneAvoidanceRule，是一种轮询方案

5.3.自定义负载均衡策略

1.代码方式:
在order-service中的OrderApplication类中，定义一个新的IRule：
@Bean public IRule randomRule(){ return new RandomRule(); }
2.配置文件
配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：
userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务 ribbon: NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

5.4.饥饿加载

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

6、Nacos注册中心

6.1.服务注册到nacos

Nacos是SpringCloudAlibaba的组件，而SpringCloudAlibaba也遵循SpringCloud中定义的服务注册、服务发现规范。因此使用Nacos和使用Eureka对于微服务来说，并没有太大区别。

主要差异在于：

• 依赖不同
• 服务地址不同

1）引入依赖

在cloud-demo父工程的pom文件中的中引入SpringCloudAlibaba的依赖：
com.alibaba.cloud spring-cloud-alibaba-dependencies 2.2.6.RELEASE pom import
然后在user-service和order-service中的pom文件中引入nacos-discovery依赖：

注意：不要忘了注释掉eureka的依赖。

2）配置nacos地址

在user-service和order-service的application.yml中添加nacos地址：

spring: cloud: nacos: server-addr: localhost:8848

注意：不要忘了注释掉eureka的地址

6.2.给user-service配置集群

修改user-service的application.yml文件，添加集群配置：

spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: HZ # 集群名称
我们再次复制一个user-service启动配置，添加属性：

-Dserver.port=8083 -Dspring.cloud.nacos.discovery.cluster-name=SH

6.3.同集群优先的负载均衡

默认的ZoneAvoidanceRule并不能实现根据同集群优先来实现负载均衡。

因此Nacos中提供了一个NacosRule的实现，可以优先从同集群中挑选实例。

1）给order-service配置集群信息

修改order-service的application.yml文件，添加集群配置：

spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: HZ # 集群名称

2）修改负载均衡规则

修改order-service的application.yml文件，修改负载均衡规则：

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

6.4.权重配置

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

服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。

但默认情况下NacosRule是同集群内随机挑选，不会考虑机器的性能问题。

因此，Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高。

在nacos控制台，找到user-service的实例列表，点击编辑，即可修改权重：

在弹出的编辑窗口，修改权重

注意：如果权重修改为0，则该实例永远不会被访问

6.5.环境隔离

Nacos提供了namespace来实现环境隔离功能。

• nacos中可以有多个namespace
• namespace下可以有group、service等
• 不同namespace之间相互隔离，例如不同namespace的服务互相不可见

实现步骤:
1、默认情况下，所有service、data、group都在同一个namespace，名为public：

2、我们可以点击页面新增按钮，添加一个namespace：
3、填写表单
就会看到新的namespace

4、给微服务配置namespace
给微服务配置namespace只能通过修改配置来实现。
例如，修改order-service的application.yml文件：
spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: HZ namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间，填ID

7、Nacos与Eureka的区别

Nacos的服务实例分为两种l类型：

• 临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。
• 非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

配置一个服务实例为永久实例：

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

Nacos和Eureka整体结构类似，服务注册、服务拉取、心跳等待，但是也存在一些差异：

• Nacos与eureka的共同点
  • 都支持服务注册和服务拉取
  • 都支持服务提供者心跳方式做健康检测

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