微服务技术栈导学
认识微服务
单体架构:
优点:简单方便,高度耦合,扩展性差,适合小型项目.
分布式架构:根据业务功能对系统进行拆分,每个业务模块作为独立项目开发,称为一个服务.
优点:
- 降低服务耦合
- 有利于服务升级拓展
Q:
- 服务拆分力度如何?
- 服务集群地址如何维护?
- 服务之间如何实现远程调用?
- 服务健康状况如何感知?
微服务:微服务是一种经过良好架构设计的分布式架构方案,特征:
- 单一职责:拆分力度更小,每个服务对应唯一业务能力,单一职责,避免重复开发
- 面向服务:对外暴露接口
- 自治:团队独立,技术独立,数据独立,部署独立
- 隔离性强:服务调用做好隔离,容错,降级,避免出现级联问题
服务拆分及远程调用
拆分注意事项:
- 不同微服务,不重复开发相同业务
- 微服务数据独立,不访问其他微服务的数据库
- 将自己的业务暴露为接口,供其他微服务调用
步骤
- 注册RestTemplate
- 服务远程调用RestTemplate
Eukera
服务调用关系
- 提供者
- 消费者
Eukera作用
在Eureka架构中，微服务角色有两类：
EurekaServer：服务端，注册中心记录服务信息心跳监控
EurekaClient：客户端
Provider：服务提供者，例如案例中的 user-service注册自己的信息到EurekaServer每隔30秒向EurekaServer发送心跳
consumer：服务消费者，例如案例中的 order-service根据服务名称从EurekaServer拉取服务列表基于服务列表做负载均衡，选中一个微服务后发起远程调用
搭建eureka服务
- 引入依赖
- 使用注解
- 配置地址信息
服务注册
- 引入依赖
- 配置地址信息
服务发现
- 引入依赖
- 配置地址信息
- 给RestTemplate添加@LoadBalanced注解
- 用服务提供者的服务名称远程调用
Ribbon负载均衡
工作流程
负载均衡策略
根据一个IRule的接口定义，每一个子接口是一种规则
通过定义IRule实现可修改负载均衡规则，两种方式
代码方式：在oder-service的OrderApplication类中，定义一个新的IRule
@
配置文件方式：在application.yml中，添加新的配置
懒加载
饥饿加载
- 开启饥饿加载
- 指定饥饿加载的微服务名称
Nacos注册中心
Nacos入门
Nacos是阿里巴巴的产品，现在是SpringCloud中的一个组件。相比Eureka功能更加丰富，国内受欢迎程度较高。
Nacos服务搭建
- 下载安装包Nacos安装指南.md
- 解压
- 在bin目录输入:startup.cmd -m standalone
Nacos服务注册或发现
- 引入nacos.discovery依赖
- 配置nacos地址spring.cloud.nacos.server-addr
Nacos服务多级存储模型
- 一级是服务，例如userservice
- 二级是集群，例如杭州或上海
- 三级是实例，例如杭州机房的某台部署了userservice的服务器
如何设置实例集群属性
- 修改application.yml文件，添加spring.cloud.nacos.discover.cluster-name属性
NacosRule负载均衡
userservice:
ribbon:
NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则
- NacosRule 优先选择本地集群
- 本地集群找不到提供者，才去其它集群寻找，并且会报警告
- 确定了可用实例列表后，再采用随机负载均衡挑选实例
Nacos服务实例权重设置
- 每个namespace都有唯一id
- 服务设置namespace时要写id而不是名称
- 不同namespace下的服务互相不可见
Nacos和Eureka对比
临时和非临时实例
Nacos与eureka的共同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
- Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
临时实例心跳不正常会被剔除，非临时实例则不会被剔除
- Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
- Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式
若有收获，就点个赞吧
0 人点赞
