单体架构:将业务全部功能集中到一个项目中,打成一个war包存储,部署在一台服务器中,只有一个数据库
优点 :架构简单,部署成本低。适合小型项目
问题:高并发性能问题,开发时代码耦合问题,部署升级时停服的问题
垂直架构:拆分模块,每个模块使用自己的数据库,如果有模块需要其他模块数据时需要自己查对方模块数据库
问题:大量代码冗余,系统难以维护,性能问题,部署问题
分布式架构:根据业务功能对系统做拆分,每个业务功能作为独立项目开发,称为一个服务
服务之间相互调用,分布式多节点部署
优点:降低耦合,有利于服务升级和拓展 适合大型互联网项目
缺点:服务调用关系错综复杂
在进行服务拆分的时候要考虑很多问题:服务拆分的粒度如何界定,服务之后如何调用,服务的调用关系如何管理,需要指定一套有效的标准来约束分布架构
微服务
架构特点:1.单一职责,每一个服务对应唯一的业务能力,做到单一职责
2.自治,团队独立,技术独立,数据独立,独立部署和交付
3.面向服务,服务提供统一的接口,与语言技术无关
4.隔离性强,服务调用做好隔离,容错,降级避免出现级联问题(级联故障是由于正反馈循环并且随着时间的增加所产生的故障。典型表现:最初由单个节点或子系统故障触发的连锁反应)
微服务的上述特点给分布式架构制定啦一个标准,进一步降低服务之间的耦合,提供服务的独立性和灵活性。微服务是一种经过良好架构设计的分布式架构方案
微服务技术的对比
SpringCloud微服务框架
官网地址:Spring Cloud
开发springcloud组件的组织:spring社区,alibaba,netflix
springCloud集成了各种微服务功能组件,基于SpringBoot实现组件的自动装配
常见的组件:服务注册发现(Eureka,nacos,consul),服务远程调用(OpenFeign,Dubbo),服务链路监控(Zipkin,Sleuth),统一配置管理(SpringCloudConfig,nacos),统一网关路由(SpringCloudGateway,zuul),流控降级保护(Hystix,Sentinel)
SpringCloud底层是依赖于SpringBoot的,并且有版本兼容关系
服务拆分原则:1.不同微服务不用重复开发相同业务
2.微服务数据独立,有自己的数据库
3.微服务可以将自己的业务暴露为接口,供其他微服务使用
远程调用
微服务的调用方式:基于RestTemplate发起的http请求实现远程调用,http请求做远程调用只要知道ip,端口,接口路径,请求参数即可。
步骤:1.注册RestTemplate的实例到Spring容器
2.修改消费者order-service服务中的OrderService类中的queryOrderById方法,根据Order对象中的userId查询User
3.将查询到的User填到Order对象
1.
#在order-service服务中的OrderApplication启动类中,注册RestTemplate实例
@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class, args);
}
@Bean
public RestTemplate restTemplate() {
return new RestTemplate();
}
}
2.
#修改order-service服务中的OrderService类中的queryOrderById方法
@Service
public class OrderService {
@Autowired
private OrderMapper orderMapper;
@Autowired
private RestTemplate restTemplate;
public Order queryOrderById(Long orderId) {
// 1.查询订单
Order order = orderMapper.findById(orderId);
//2查询用户
String url="http://userservice/user/"+order.getUserId();
User user = restTemplate.getForObject(url, User.class);
// 3封装user信息
order.setUser(user);
// 4.返回
return order;
}
}
在服务调用关系中,会有两个不同的角色,这两个角色是相对的
服务提供者Provider:一次业务中,被其他微服务调用的服务,提供接口给其他服务
服务消费者consumer:一次业务中,调用其他微服务的服务,调用其他微服务提供的接口
注册中心
解决问题:服务注册与发现(服务治理问题)
Eureka注册中心
EurekaServer:服务端,注册中心
EurekaClient:客户端
服务注册:提供者启动之后将自己的信息注册到eureka-server(Eureka服务端)
eureka-server保存服务名称到服务实例地址列表的映射关系
服务拉取:消费者根据服务名称拉取实例地址列表(注册表)并缓存到本地
消费者根据负载均衡算法选中一个实例地址,发起远程调用
健康检查:提供者每隔一段时间(默认30秒)向eureka-server发起请求,报告自己状态。称为心跳
当超过一段时间(90秒)没有发送心跳,eureka-server认为微服务实例故障,将该实例从列表中剔除,拉取服务时,该故障实例排除
搭建eureka-server
1.引入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
2.编写启动类
@SpringBootApplication
@EnableEurekaServer //开启eureka的注册中心功能
public class EurekaApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaApplication.class, args);
}
}
3.编写配置文件application.yml
server:
port: 10086
spring:
application:
name: eureka-server
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
启动成功
服务注册
引入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
配置文件
spring:
application:
name: orderservice
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
可以将user-service多次启动,模拟多实例部署,注意修改端口设置 -Dserver.port=自定义的端口号
如果没有service选项【IDEA】idea打开新项目,左下角的工作栏中没有显示Services解决办法 - Angel挤一挤 - 博客园
在order-service完成服务拉取,修改OrderService的代码,修改访问路径
在order-service项目的启动类OrderApplication中RestTemplate添加负载均衡诸界
@Bean
@LoadBalanced //负载均衡注解
public RestTemplate restTemplate(){
return new RestTemplate();
}
负载均衡
SpringCloud底层利用Ribbon的组件,实现负载均衡。服务调用者动态调用服务提供者的多个节点
Ribbon内部就是集成了LoadBalancerClient负载均衡,通过@LoadBalance注解开启负载均衡器。
基本流程:RibbonLoadBalanceClient从请求url中获取服务名称,DynamicServerListLoadBalancer根据服务名称到eureka拉取服务列表eureka返回服务列表,IRule利用内置的负载均衡规则从列表中选择一个服务,返回给RibbonLoadBalanceClient
Ribbon的负载均衡规则时一个叫IRule的接口来定义的,每一个接口就是一种规则
内置的负载均衡规则:
RoundRobinRule 简单的轮询服务列表来选择服务器,Ribbon默认的负载均衡规则
ZoneAvoidanceRule 以区域可用的服务器为基础进行服务器的选择
默认的实现就是ZoneAvoidanceRule,是一种轮询方案(一般使用默认的负载均衡规则,不修改)
Ribbon采用默认的懒加载,第一次访问才会去创建 LoadBalanceClient,请求时间会很长。
Nacos注册中心
Nacos是阿里巴巴的产品,现在是SpringCloudAlibaba中的一个组件(SpringCloudAlibaba实现啦对SpringCloud组件进行扩展)
与Eureka的差异:依赖不同,服务地址不同
Nacos服务搭建,下载安装包,解压,在bin目录下运行startup.cmd -mstandalone
引入依赖,在父工程里面,引入
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>2.2.6.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
在服务消费者和提供者的pom文件引入nacos的依赖,注释掉eureka的依赖
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
配置nacos地址,在user-service和order-service的application.yml中添加nacos地址,不要忘了注释掉eureka的地址
spring:
cloud:
nacos:
server-addr: localhost:8848
在启动类添加注解@EnableDicoveryClient
Nacos服务分级存储模型
一个服务有多个实例,实例分布在不同的机房中,Nacos将同一机房的实例划分为一个集群
服务-集群-实例
服务调用尽可能选择本地集群的服务,跨集群调用延迟较高。(本地集群不可访问时,在访问其他集群)
给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
默认的zoneAvoidanceRule不能实现同集群有效实现负载均衡,Nacos中提供了一个NacosRule
的实现,可以优先从同集群中挑选实例。
修改负载均衡规则修改order-service的application.yml文件,修改负载均衡规则:
userservice:
ribbon:
NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则
根据权重负载均衡:在实际部署中提高权重配置来控制访问频率,权重高访问频率高
在Nacos控制台设置实例的权重值0~1之间
环境隔离namespace
Nacos中服务存储和数据存储的最外层都是一个namespace的东西,用做最外层隔离,修改order-service的application.yml文件:
spring:
cloud:
nacos:
server-addr: localhost:8848
discovery:
cluster-name: HZ
namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间,填ID
Nacos的服务实例分为两种类型:
临时实例:如果实例宕机超过一段时间,会从服务列表中剔除,默认的类型
非临时实例:如果实例宕机,不会从服务列表中剔除,也叫永久实例
Nacos和Eureka的区别:
相同点:都支持服务注册和服务拉取,都支持服务提供者心跳方式做健康检测
区别:1.Nacos支持服务端主动检测提供者状态:临时实例采用心跳检测,非临时实例nacos主动询问
2.临时实例心跳不正常被剔除,非临时实例则不会剔除
3.Nacos支持服务礼包变更的消息推送模式,服务列表更新更及时
4.Nacos集群默认采用AP方式,集群中存在非实例时采用CP模式;Eureka采用AP模式
CAP定理:布鲁尔定理
指出对于一个分布式计算机来说,不可能同时满足三点,最多同时满足两点:
一致性(Consistency)系统中所有数据备份,在同一时刻同样的值
可用性(Availability)保证每次请求不管成功失败都有响应
分区容错性(Partition tolerance)系统中任意信息的丢失或失败不会影响系统的继续运作
配置中心
配置统一管理和配置隔离问题
nacos=SpringCloud eureka注册中心+SpringCloud config配置中心
项目的核心配置,需要热更新的配置才有放到nacos管理的必要。基本不会变更的一些配置还是保存在微服务本地比较好。(热加载:不重启一个项目,使得部分代码更新,通过java类加载器实现)
保证项目中有bootstrap.yml
微服务要拉取nacos中管理的配置,并且与本地的application.yml配置合并,才能完成项目启动
在bootstrap.yml中提那就配置中心相关内容:环境相关spring.profiles.active
配置中心地址,配置文件后缀
配置加载顺序:先加载共享配置文件,再加载环境相关配置文件,在加载application.yml
在idea中的使用
导入依赖
<!--nacos配置管理依赖-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
添加bootstrap.yaml
spring:
application:
name: userservice # 服务名称
profiles:
active: dev #开发环境,这里是dev
cloud:
nacos:
server-addr: localhost:8848 # Nacos地址
config:
file-extension: yaml # 文件后缀名
配置热更新
最终目的,是修改nacos中的配置后,微服务无需重启就可以让配置生效(配置热更新)
使用两种方式:
一:@Value注入的变量所在类上添加注解@RefreshScope:
二: 在controller中使用@ConfigurationProperties注解代替@Value注解。