认识微服务
单体架构
将业务的所有功能集中在一个项目中开发,打成一个包部署。
优点:
- 架构简单
- 部署成本低
缺点:
- 耦合度高
分布式架构
根据业务功能对系统进行拆分,每个业务模块作为独立项目开发,称为一个服务。
优点:
- 降低服务耦合
- 有利于服务升级拓展
分布式架构的要考虑的问题:
- 服务拆分粒度如何?
- 服务集群地址如何维护?
- 服务之间如何实现远程调用?
- 服务健康状态如何感知?
微服务
微服务是一种经过良好架构设计的分布式架构方案,微服务架构特征:
- 单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单
一职责,避免重复业务开发 - 面向服务:微服务对外暴露业务接口
- 自治:团队独立、技术独立、数据独立、部署独立
- 隔离性强:服务调用做好隔离、容错、降级,避免出现级联问题
微服务结构
微服务这种方案需要技术框架来落地,全球的互联网公司都在积极尝试自己的微服务落地技术。在国内最知名的就是SpringCloud和阿里巴巴的Dubbo。
微服务技术对比
Dubbo | Springcloud | SpringcloudAlibaba | |
---|---|---|---|
注册中心 | zookeeper、Redis | Eureka、Consul | Nacos、Eureka |
服务远程调用 | Dubbo协议 | Feign (http协议) | Dubbo、Feign |
配置中心 | 无 | SpringcloudConfig | SpringCloudConfig、Nacos |
服务网关 | 无 | SpringCloudGateway、Zuul | SpringCloudGateway、Zuul |
服务监控和保护 | dubbo-admin,功能弱 | Hystrix | Sentinel |
企业需求
SpringCloud + Feign
- 使用SpringCloud技术栈
- 使用SpringCloudAlibaba技术栈
- 服务接口采用Restful风格
SpringCloudAlibaba+Feign
使用SpringCloudAlibaba技术栈
服务接口采用Restful风格
服务调用采用Feign方式
SpringCloudAlibaba+Dubbo
- 使用SpringCloudAlibaba技术栈
- 服务接口采用Dubbo协议标准
- 服务调用采用Dubbo方式
Dubbo原始模式
- 基于Dubbo老旧技术体系
- 服务接口采用Dubbo协议标准
- 服务调用采用Dubbo方式
SpringCloud
- SpringCloud是目前国内使用最广泛的微服务框架。官网地址: https://spring.io/projects/spring-cloud。
- SpringCloud集成了各种微服务功能组件,并基于SpringBoot实现了这些组件的自动装配,从而提供了良好的开箱即用体验。
服务拆分及远程调用
服务拆分注意事项
- 不同微服务,不要重复开发相同业务
- 微服务数据独立,不要访问其它微服务的数据库
- 微服务可以将自己的业务暴露为接口,供其它微服务调用
微服务远程调用-查询订单
- 基于RestTemplate发起的http请求实现远程调用
- http请求做远程调用是与语言无关的调用,只要知道对方的ip、端口、接口路径、请求参数即可。
步骤
注册RestTemplate
在order-service的OrderApplication中注册RestTemplate
@MapperScan ("cn.itcast.order.mapper")@SpringBootApplicationpublic class OrderApplication {public static void main(String[] args) {SpringApplication.run(OrderApplication.class, args);}@Beanpublic RestTemplate restTemplate(){return new RestTemplate(;}}
服务远程调用RestTemplate
修改order-service中的OrderService的queryOrderByld方法:
@Autowiredprivate OrderMapper orderMapper;@Autowiredprivate RestTemplate restTemplate;public Order queryOrderById(Long orderId) {// 1.查询订单Order order = orderMapper.findById(orderId);// 2.利用RestTemplate发送http请求,查询用户String url = "http://localhost:8081/user/"+order.getUserId();User user = restTemplate.getForObject(url, User.class);// 3.封装User到Orderorder.setUser(user);// 4.返回return order;}
提供者与消费者
- 服务提供者:一次业务中,被其它微服务调用的服务。(提供接口给其它微服务)
- 服务消费者:一次业务中,调用其它微服务的服务。(调用其它微服务提供的接口)
提供者与消费者角色其实是相对的
一个服务可以同时是服务提供者和服务消费者
Eureka注册中心
服务调用出现的问题
- 服务消费者该如何获取服务提供者的地址信息?
- 如果有多个服务提供者,消费者该如何选择?
- 消费者如何得知服务提供者的健康状态?
eureka的作用
- 消费者该如何获取服务提供者具体信息” />搭建EurekaServer
搭建EurekaServer服务步骤如下:
创建项目,引入spring-cloud-starter-netflix-eureka-server的依赖
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-server</artifactId></dependency>
- 此处无需版本信息,父工程中的spring-cloud-dependencies已经管理好了版本
编写启动类,添加@EnableEurekaServer注解
@SpringBootApplication@EnableEurekaServerpublic class EurekaApplication {public static void main(String[] args) {SpringApplication.run(EurekaApplication.class, args);}}
添加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服务注册到EurekaServer步骤如下:
在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文件,编写下面的配置:
eureka:client:service-url: # eureka的地址信息defaultZone: http://127.0.0.1:10086/eurekaspring:application:name: userservice # user服务的服务名称
另外,我们可以将user-service多次启动,模拟多实例部署,但为了避免端口冲突,需要修改端口设置:
-D表示参数,server.port相当重写配置文件的端口号
在order-service完成服务拉取
服务拉取是基于服务名称获取服务列表,然后在对服务列表做负载均衡
修改OrderService的代码,修改访问的url路径,用服务名代替ip、端口:
String url = "http://userservice/user/"+order.getUserId();
在order-service项目的启动类OrderApplication中的RestTemplate添加负载均衡注解:
/** * 创建RestTemplate并注入Spring容器 */@Bean@LoadBalanced//负载均衡public RestTemplate restTemplate() {return new RestTemplate();}
Ribbon负载均衡
负载均衡流程
IRule接口决定了负载均衡的具体实现
Ribbon的负载均衡规则是一个叫做IRule的接口来定义的,每一个子接口都是一种规则:
负载均衡策略
通过定义IRule实现可以修改负载均衡规则,有两种方式:
代码方式:在order-service中的OrderApplication类中,定义一个新的IRule(针对所有服务):
@Beanpublic 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 # 指定对userservice这个服务饥饿加载
Nacos注册中心
认识Nacos
Nacos是阿里巴巴的产品,现在是SpringCloud中的一个组件。相比Eureka功能更加丰富,在国内受欢迎程度较高。
Nacos服务搭建
- 下载安装包
- 解压
- 在bin目录下运行指令:
startup.cmd -m standalone
服务注册到Nacos
在cloud-demo父工程中添加spring-cloud-alilbaba的管理依赖:
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-alibaba-dependencies</artifactId><version>2.2.5.RELEASE</version><type>pom</type><scope>import</scope></dependency>
注释掉order-service和user-service中原有的eureka依赖。
添加nacos的客户端依赖:
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency>
修改user-service&order-service中的application.yml文件,注释eureka地址,添加nacos地址:
spring:cloud:nacos:server-addr: localhost:8848 # nacos服务地址
启动并测试:
Nacos服务分级存储模型
服务跨集群调用问题
服务调用尽可能选择本地集群的服务,跨集群调用延迟较高本地集群不可访问时,再去访问其它集群
一级是服务,例如userservice
二级是集群,例如杭州或上海
三级是实例,例如杭州机房的某台部署了userservice的服务器
服务集群属性
修改application.yml,添加如下内容:
spring:cloud:nacos:discovery:cluster-name: HZ # 配置集群名称,也就是机房位置,例如:HZ,杭州
在Nacos控制台可以看到集群变化:
根据集群负载均衡
修改order-service中的application.yml,设置集群为HZ:
spring:cloud:nacos:server-addr: localhost:8848 # nacos服务地址discovery:cluster-name: HZ
然后在order-service中设置负载均衡的IRule为NacosRule,这个规则优先会寻找与自己同集群的服务:
userservice: # 给某个微服务配置负载均衡规则,这里是userservice服务ribbon:NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则:按集群
注意将user-service的权重都设置为1
- NacosRule负载均衡策略
- 优先选择同集群服务实例列表
- 本地集群找不到提供者,才去其它集群寻找,并且会
报警告 - 确定了可用实例列表后,再采用随机负载均衡挑选实
例
根据权重负载均衡
实际部署中会出现这样的场景:
- 服务器设备性能有差异,部分实例所在机器性能较好,另一些较差,我们希望性能好的机器承担更多的用户请求
Nacos提供了权重配置来控制访问频率,权重越大则访问频率越高
- 在Nacos控制台可以设置实例的权重值,首先选中实例后面的编辑按钮
- 将权重设置为0.1,测试可以发现8081被访问到的频率大大降低
- 实例的权重控制
- Nacos控制台可以设置实例的权重值,0~1之间
- 同集群内的多个实例,权重越高被访问的频率越高
- 权重设置为0则完全不会被访问
环境隔离-namespace
Nacos中服务存储和数据存储的最外层都是一个名为namespace的东西,用来做最外层隔离
Nacos环境隔离:
- namespace用来做环境隔离
- 每个namespace都有唯一id
- 不同namespace下的服务不可见
在Nacos控制台可以创建namespace,用来隔离不同环境
然后填写一个新的命名空间信息
保存后会在控制台看到这个命名空间的id
修改order-service的application.yml,添加namespace:
spring:cloud:nacos:server-addr: localhost:8848 # nacos服务地址discovery:cluster-name: HZnamespace: c9627b99-a0b6-450e-bf6f-5dfa54c23e75
此时访问order-service,因为namespace不同,会导致找不到userservice,控制
台会报错
Nacos注册中心原理
nacos注册中心细节分析
临时实例和非临时实例
服务注册到Nacos时,可以选择注册为临时或非临时实例,通过下面的配置来设置:
spring:cloud:nacos:discovery:ephemeral: false # 是否是临时实例
- Nacos与eureka的共同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
- Nacos与Eureka的区别
- Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测模式
- 临时实例心跳不正常会被剔除,非临时实例则不会被剔除
- Nacos支持服务列表变更的消息推送模式,服务列表更新更及时
- Nacos集群默认采用AP方式,当集群中存在非临时实例时,采用CP模式;Eureka采用AP方式
CAP理论/特性
C:Consistance:一致性;A:Availability:可用性;P:Partion Tolerance分区容错性