1.微服务架构
进程级别的隔离
将整个项目分为不同的服务,每一个服务都是一个应用程序,都可以独立运行,按照单一职责实现特定功能,因此具有一些优点1插拔式2容易维护,3CI/CD4.容错
API网关
客户端 --> 后端应用
CDN:Content Delivery Network 静态资源 ,内容分发网络
对外揭露请求,对内路由
2.Dubbo
从一个运行的进程中调用另一个进程里的方法
去这取得接口实现类
Dubbo原理
提供者启动spring容器
容器中:1.实现了真正对外暴露的接口功能的对象
2.供外界调用的服务对象
端口,与协议
服务端:socket发送请求
是如何调用到方法:(通过暴露的全限定类名为key找到实现类value,通过url发送socket(动态代理,接收到返回值)从而远程调用)
提供者:实现类加入容器,提交给服务,协议端口()(提交给服务,接口和实现类) (在boot中这会接口与实现类会被Service注解代替,填写的就是端口号协议以及注册中心了)
BOOT:提供者:1.注解(service)2.配置文件(提供)
消费者:1.注解 2.配置文件
消费者:把接口(来自依赖)加入容器:reference标签,接口,端口号和协议,所以从容器拿出来就知道是dubbo的,之后调用方法,执行的时候就是动态代理(告诉容器实现类的来源,来自dubbo)
提供者中有一个Map<String,服务对象>
Key:接口的全类名, ->服务对象 服务对象是实现了接口的对象
消费者中也有一个spring容器:
1.服务引用对象(DemoService)
一个代理对象(远程代理promoProxy什么的,传过去全限定类名和参数,对方接收解析之后,从Map里的全限定类名,从容器中取得这个类,之后执行方法返回返回值dubbo协议)
当代理对象(代理对象实现了同样的接口JDK远程动态代理)被调用时,说明用户想调用DemoService接口的功能
当对应方法被调用的时候,就表明了调用的对应方法
(思考一下两个容器的问题)没什么问题,一个是装着接口,然后reference指向治理中心的实现类
一个容器就是提供给治理中心的
考虑提供者的集群模式
引入服务注册中心
配置文件:去掉url
服务的注册与自动发现;
SpringBoot
负载均衡策略
在消费者中设置负载均衡策略
单体架构的优点: 功能简单,快速构建
单体架构的弊端: 耦合复杂,业务发展,业务复杂
====>微服务架构: 功能特征:单一职责 运行特征: 独立运行部署对外服务
模块化角度对比区别 :微服务架构下的模块化,模块之间调用需要特殊手段(减少的耦合),模块化之间存在了清晰的边界
什么是微服务架构:将原本的单体应用拆分为服务的架构风格
微服务架构的优缺点:
微服务项目的架构图->API网关(对外接受请求,对内实现请求路由),CDN
落地微服务项目所面临的问题: 服务的调用 , 服务的治理 ==>引出了Dubbo框架
RPC实现原理 b.服务注册中心
-->Dubbo与SpringBoot整合 a.@Service注解 与@Reference注解 b.服务提供者集群 ->服务调用的负载均衡问题(Reference注解中设置
)
