假设我们开发一个rpc远程调用框架
那么这个框架需要怎么去写
1、首先有远程配置中心config
2、有服务代理层【包装业务上的服务做一个代理】
3、有服务注册中心【代理了服务之后 向该注册中心注册服务代理】
4、有路由【远程调用先走路由获取服务代理实例、集群必备的东西】
5、有远程调用层【发起服务调用】
6、有网络传输层、有信息交换层【这个是一个传输协议的实现层】
7、有序列化层【针对网络IO信息编码方式的统一、传输协议最基本的东西】
8、服务监控【不属于RPC、但是服务监控必不可少】
总结：
核心配置：服务注册中心、服务代理和服务调用
优化配置：配置中心、服务监控、
基石配置：网络传输以及协议、序列化方式的定制
dubbo-framework.jpg
简单用自己的语言描述这个图
1、左上角 Dubbo Framework
2、左上角往右简单标识 每个颜色代表什么意思、更好理解图中数据流向
消费者、提供者、开始、接口、类、继承关系、调用链方向、依赖方向
3、左侧一竖列、黑体字 service\config、等等
服务接口【service】、配置层【config】、服务代理层【proxy】、注册中心【registry】、
路由【cluster】、监控中心【monitor】、远程调用【protocol】、
信息交换【exchange】、网络传输【transport】、数据序列化【serialize】
结合自己所想做一个分类
核心配置：服务代理层【proxy】、注册中心【registry】、远程调用【protocol】
优化配置：配置层【config】、路由【cluster】、监控中心【monitor】
基石配置：信息交换【exchange】、网络传输【transport】、数据序列化【serialize】
简单猜想一下dubbo这么设计的代码架构
service：对外暴露接口 API与SPI分离
config：核心referenceConfig、ServiceConfig
serviceConfig----获取远程仓库配置、获取文件配置、貌似还可以获取环境变量【实质上跟修改本地host一个道理、规定了一个locahost代理 然后操作系统去解析这个配置】
referenceConfig--是消费端配置、其应该是从服务端获取配置信息
proxy：不由想到代理模式、原业务逻辑bean不变、新建bean来实现原bean的代理【也算是一种封装】
registry：注册中心、看过eureka、底层内存中维护了 一个双map结构数据列表、维护服务实例、服务地址、以及代理service等
cluster：路由器、想到最简单的就是url转发、当然肯定没这么简单、应该还会有、实时获取服务列表、负载均衡算法等等
monitor：监控中心、这个web服务把各路信息提上来做一个展示、应该没啥、最多维护一个硬盘文件
protocol：远程调用、怎么调用--不太清楚--再看看
exchange：信息交换、request、response封装
transport：网络传输、大名鼎鼎的netty就在这吧~~
seriallize：数据序列化、提供多重序列化方式、hessian【本地存根方式】、rmi等等吧
网友评论