(三)微服务 dubbo

 

 

 

 

 

 1.微服务架构

 

 进程级别的隔离

将整个项目分为不同的服务,每一个服务都是一个应用程序,都可以独立运行,按照单一职责实现特定功能,因此具有一些优点1插拔式2容易维护,3CI/CD4.容错 

 

API网关

客户端 --> 后端应用

 

CDN:Content Delivery Network 静态资源 ,内容分发网络

 对外揭露请求,对内路由

2.Dubbo

 从一个运行的进程中调用另一个进程里的方法

 去这取得接口实现类

 Dubbo原理

提供者启动spring容器

容器中:1.实现了真正对外暴露的接口功能的对象

            2.供外界调用的服务对象

 服务暴露:serverSocket监听服务暴露的端口,与协议

服务端: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框架  

                               -->Dubbo与spring 的整合 a.RPC实现原理 b.服务注册中心 

                               -->Dubbo与SpringBoot整合 a.@Service注解 与@Reference注解 b.服务提供者集群 ->服务调用的负载均衡问题(Reference注解中设置)