1.认识微服务
单体架构:将所有的业务功能集中在一个项目中开发,打成一个包部署
多个功能耦合在一起,后期维护成本高
优点:架构简单 , 部署成本低
缺点: 耦合度高
分布式架构:根据业务功能对系统进行拆分,每个业务模块作为独立项目开发,称为一个服务。适合大型互联网项目。
优点:降低服务耦合,有利于服务升级扩展
分布式架构要考虑到的问题:
- 服务拆分粒度如何?
- 服务集群地址如何维护?
- 服务之间如何实现远程调用?
- 服务健康状态如何?
基于这些,微服务经过良好架构设计的分布式架构方案,微服务架构特征:
- 单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责,避免重复业务开发
- 面向服务:微服务对外暴露业务接口
- 自治:每个微服务就是一个个体,团队独立,技术独立(不同语言写也行),数据独立,部署独立
- 隔离性强:服务调用做好隔离,容错,降级,避免出现级联问题。
微服务这种技术方案需要技术框架来落地,比如国内知名的SpringCloud
微服务技术对比:
企业需求:
SpringCloud
- SpringCloud是目前国内使用最广泛的微服务框架。官网地址:Spring Cloud。
- SpringCloud集成了各种微服务功能组件,并基于SpringBoot实现了这些组件的自动装配,从而提供了良好的开箱即用体验。
其中常见的组件包括:
要考虑SpringCloud与springboot的版本兼容问题
2.服务拆分和远程调用
服务拆分注意事项:
单一职责:不同微服务,不用重复开发相同业务
数据独立:不要访问其他微服务的数据库
面向服务:将自己的业务暴露为接口,供其他微服务调用
1.微服务需要根据业务模块拆分,做到单一职责,不要重复开发相同业务
2.微服务可以将业务暴露为接口,供其它微服务使用
3.不同微服务都英爱有自己独立的数据库。
案例:
根据订单iD查询订单的同时,把订单所属用户信息一起返回
(1)注册RestTemplate
在order-service的OrderApplication中注册RestTemplate
(2)服务远程调用RestTemplate
微服务调用方式:
基于RestTemplate发起的http请求实现远程调用
http请求做远程调用是与语言无关的调用,只要知道对方的ip,端口,接口路径,请求参数即可。
提供者与消费者(相对的)
服务提供者:一次业务中,被其他微服务调用的服务(提供接口给其他微服务)
服务消费者:一次业务汇总,调用其他微服务的服务(调用其他微服务提供的接口)
3.Eureka注册中心
前景:服务调用出现的问题
- 服务消费者该如何获取服务提供者的地址信息
-
- 服务提供者启动时想eureka注册自己的信息
- eureka保存这些信息
- 消费者根据服务名称想eureka拉取提供者信息
- 如果有多个服务提供者,消费者该如何选择
-
- 服务消费者利用负载均衡算法,从服务列表中挑选一个
- 消费者如何得知服务者的健康状态。
-
- 服务提供者会每隔30秒向EruekaServer发送心跳请求,报告健康状态
- eureka会更新记录服务列表信息,心跳不正常会被剔除
- 消费者就可以拉取到最新的信息
某一节点宕机,经过心跳检查后会主动舍去。
eureka功能:注册,发现,状态监控
总结:
实践。
①搭建EurekaServer服务
注册中心搭建成功:
启动多个user-service实例
为了演示一个服务有多个实例的场景,我们添加一个SpringBoot的启动配置,再启动一个user-service。
首先,复制原来的user-service启动配置:
服务发现
引入依赖
之前说过,服务发现、服务注册统一都封装在eureka-client依赖,因此这一步与服务注册时一致。
在order-service的pom文件中,引入下面的eureka-client依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
配置文件
服务发现也需要知道eureka地址,因此第二步与服务注册一致,都是配置eureka信息:
在order-service中,修改application.yml文件,添加服务名称、eureka地址:
spring:
application:
name: orderservice
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
服务拉取和负载均衡
最后,我们要去eureka-server中拉取user-service服务的实例列表,并且实现负载均衡。
不过这些动作不用我们去做,只需要添加一些注解即可。
在order-service的OrderApplication中,给RestTemplate这个Bean添加一个@LoadBalanced注解:
总结:
4.Ribbon负载均衡
负载均衡策略
内置负载均衡规则类 | 规则描述 |
RoundRobinRule | 简单轮询服务列表来选择服务器。 |
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: # 给某个微服务配置负载均衡规则,这里是userservice服务
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则
注意,一般用默认的负载均衡规则,不做修改。
饥饿加载
Ribbon默认是采用懒加载,即第一次访问时才会去创建LoadBalanceClient,请求时间会很长。
而饥饿加载则会在项目启动时创建,降低第一次访问的耗时,通过下面配置开启饥饿加载:
ribbon:
eager-load:
enabled: true
clients: userservice # 指定被调用微服务饥渴加载
5.Nacos注册中心
认识和安装Nacos
Nacos是阿里巴巴产品,springcloud中的一个组件,相比于Eureka功能更加丰富。在国内受欢迎度高。
Nacos快速入门
Nacos服务分级存储模型
总结
权重配置
实际部署中会出现这样的场景:
服务器设备性能有差异,部分实例所在机器性能较好,另一些较差,我们希望性能好的机器承担更多的用户请求。
但默认情况下NacosRule是同集群内随机挑选,不会考虑机器的性能问题。
因此,Nacos提供了权重配置来控制访问频率,权重越大则访问频率越高。
在nacos控制台,找到user-service的实例列表,点击编辑,即可修改权重:
Nacos环境隔离-namespace
Nacos服务存储和数据存储的最外层都是一个名为namespace的东西,用来做最外层隔离
Nacos提供了namespace来实现环境隔离功能。
- nacos中可以有多个namespace
- namespace下可以有group、service等
- 不同namespace之间相互隔离,例如不同namespace的服务互相不可见
namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间,填ID
Nacos和Eureka区别
临时实例和非临时实例
Nacos的服务实例分为两种l类型:
- 临时实例:如果实例宕机超过一定时间,会从服务列表剔除,默认的类型。
- 非临时实例:如果实例宕机,不会从服务列表剔除,也可以叫永久实例。
- Nacos与eureka的共同点
-
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
- Nacos与Eureka的区别
-
- Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测模式
- 临时实例心跳不正常会被剔除,非临时实例则不会被剔除
- Nacos支持服务列表变更的消息推送模式,服务列表更新更及时
- Nacos集群默认采用AP方式,当集群中存在非临时实例时,采用CP模式;Eureka采用AP方式
6.CAP定理:
分布式系统有三个指标:
- Consistency 一致性 :用户访问分布式系统中的任意节点,得到的数据必须一致
- Availability 可用性:用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝。
- Partition tolerance 分区容错性:
-
- (Partition分区)因为网络故障或其它原因导致分布式系统中的部分节点与其他节点失去连接,形成独立分区,无法百分百保证数据同步
- (Tolerance容错)在集群出现分区时,整个系统也要持续对外提供服务。