8.如何自己设计一个类似 Dubbo 的 RPC 框架?

作者:中华石杉

面试题

如何自己设计一个类似 Dubbo 的 RPC 框架?

面试官心理分析

说实话,就这问题,其实就跟问你如何自己设计一个 MQ 一样的道理,就考两个:

  • 你有没有对某个 rpc 框架原理有非常深入的理解。
  • 你能不能从整体上来思考一下,如何设计一个 rpc 框架,考考你的系统设计能力。

面试题剖析

其实问到你这问题,你起码不能认怂,因为是知识的扫盲,那我不可能给你深入讲解什么 kafka 源码剖析,dubbo 源码剖析,何况我就算讲了,你要真的消化理解和吸收,起码个把月以后了。

所以我给大家一个建议,遇到这类问题,起码从你了解的类似框架的原理入手,自己说说参照 dubbo 的原理,你来设计一下,举个例子,dubbo 不是有那么多分层么?而且每个分层是干啥的,你大概是不是知道?那就按照这个思路大致说一下吧,起码你不能懵逼,要比那些上来就懵,啥也说不出来的人要好一些。

举个栗子,我给大家说个最简单的回答思路:

  • 上来你的服务就得去注册中心注册吧,你是不是得有个注册中心,保留各个服务的信息,可以用 zookeeper 来做,对吧。
  • 然后你的消费者需要去注册中心拿对应的服务信息吧,对吧,而且每个服务可能会存在于多台机器上。
  • 接着你就该发起一次请求了,咋发起?当然是基于动态代理了,你面向接口获取到一个动态代理,这个动态代理就是接口在本地的一个代理,然后这个代理会找到服务对应的机器地址。
  • 然后找哪个机器发送请求?那肯定得有个负载均衡算法了,比如最简单的可以随机轮询是不是。
  • 接着找到一台机器,就可以跟它发送请求了,第一个问题咋发送?你可以说用 netty 了,nio 方式;第二个问题发送啥格式数据?你可以说用 hessian 序列化协议了,或者是别的,对吧。然后请求过去了。
  • 服务器那边一样的,需要针对你自己的服务生成一个动态代理,监听某个网络端口了,然后代理你本地的服务代码。接收到请求的时候,就调用对应的服务代码,对吧。

这就是一个最最基本的 rpc 框架的思路,先不说你有多牛逼的技术功底,哪怕这个最简单的思路你先给出来行不行?

原文地址:https://www.cnblogs.com/morganlin/p/11986450.html

时间: 2024-10-13 01:43:35

8.如何自己设计一个类似 Dubbo 的 RPC 框架?的相关文章

如何设计一个易用的MVC框架

导言 把一件简单的事情做复杂很容易,把一件复杂的事情做简单却不易.在计算机的世界里, 冯.诺依曼把复杂的电脑简化为:存储器,控制器,运算器和I/O设备; 丹尼斯·里奇把晦涩的汇编语言简化为258页的<C程序设计语言>; 詹姆斯高斯林把繁琐的跨平台编码简化为256条字节码指令: 对我们大部分人而言,把简单的事情做简单就足够了. 关于框架 框架是对某一类共通业务的封装,框架设计应该遵循几个基本的原则:1 易用性 2 稳定性3 扩展性,框架从来都是给别人用 的,框架的学习成本与他的复杂度成正比,如果

Gora是一个类似Hibernate的ORM框架

Gora是一个类似Hibernate的ORM框架,但是不只是支持关系数据库,更重要支持NoSQL之类大数据的存储. 支持NoSQL之类大数据的存储 Apache Gora是一个开源的ORM(Object/Relation Mapping,对象关系映射)框架,主要为大数据提供内存数据模型与数据的持久化.目前Gora支持对于列数据.key-value数据,文档数据与RDBMS数据的存储,还支持使用Apache Hadoop来对对大数据进行分析 虽然目前市面上有很多不错的关系数据库的ORM框架,但是基

Apache thrift - 使用,内部实现及构建一个可扩展的RPC框架

本文首先介绍了什么是Apache Thrift,接着介绍了Thrift的安装部署及如何利用Thrift来实现一个简单的RPC应用,并简单的探究了一下Thrift的内部实现原理,最后给出一个基于Thrift的可扩展的分布式RPC调用框架,在中小型项目中是一个常见的SOA实践. Thrift介绍 Apache Thrift是Facebook 开发的远程服务调用框架,它采用接口描述语言(IDL)定义并创建服务,支持可扩展的跨语言服务开发,所包含的代码生成引擎可以在多种语言中,如 C++, Java,

如何设计一个完善可用的服务框架

上一篇博客整理了一些关于服务框架基础知识的内容,这篇博客,从实际的生产需要出发,谈谈一个完善可用的服务框架,需要包含哪些功能... PS:部分内容参考自<京东基础架构建设之路> 一个完善可用的RPC服务框架,需要包含以下几点: 框架组成 具体功能说明 服务注册中心 服务框架基础知识 管理端 接口管理+配置中心 统一的RPC框架 监控中心+分布式追踪+服务治理+网关 管理端 1.接口管理 提供统一的接口管理和查询入口,比如公共wiki或者类似swagger之类的系统. 功能:定义接口,包括接口描

RPC框架之Dubbo

问题1:为什么要把系统拆分成分布式的?为啥要用dubbo? 1.为什么要将系统进行拆分? 要是不拆分系统,一个大系统几十万行代码,很多人共同维护一份代码,简直是悲剧: 拆分了以后,一个大系统拆分成很多小服务,平均每个系统也就几万行代码,每个服务部署到单独的机器 2.如何进行服务拆分? ? 大部分系统,是要进行多轮拆分的,第一次拆分就可能将原来的多个模块拆分开来. ? 但是后来可能每个系统都变得很复杂了,每个模块拆分出来的服务又要继续拆分. 3.拆分后可以不用dubbo吗? ? 当然可以,大不了各

一个轻量级分布式RPC框架--NettyRpc

1.背景 最近在搜索Netty和Zookeeper方面的文章时,看到了这篇文章<轻量级分布式 RPC 框架>,作者用Zookeeper.Netty和Spring写了一个轻量级的分布式RPC框架.花了一些时间看了下他的代码,写的干净简单,写的RPC框架可以算是一个简易版的dubbo.这个RPC框架虽小,但是麻雀虽小,五脏俱全,有兴趣的可以学习一下. 项目地址:https://github.com/luxiaoxun/NettyRpc 自己花了点时间整理了下代码,并修改一些问题,以下是自己学习的一

一个简单RPC框架是如何炼成的(I)——开局篇

开场白,这是一个关于RPC的相关概念的普及篇系列,主要是通过一步步的调整,提炼出一个相对完整的RPC框架. RPC(Remote Procedure Call Protocol)--远程过程调用协议,基于C/S模型.网络上有一篇文章写得不错,可以去了解一下相关概念深入浅出RPC 这里,直接使用一下上面作者的一个示意图 总结下来就是有4块核心内容 RPC数据的传输.如上面的RPCConnector,RPCChannel.它们主要负责数据传输这一块, 具体客户端与服务器之间的连接是不是socket连

Dubbo入门---搭建一个最简单的Demo框架

Dubbo背景和简介 Dubbo开始于电商系统,因此在这里先从电商系统的演变讲起. 单一应用框架(ORM) 当网站流量很小时,只需一个应用,将所有功能如下单支付等都部署在一起,以减少部署节点和成本. 缺点:单一的系统架构,使得在开发过程中,占用的资源越来越多,而且随着流量的增加越来越难以维护 垂直应用框架(MVC) 垂直应用架构解决了单一应用架构所面临的扩容问题,流量能够分散到各个子系统当中,且系统的体积可控,一定程度上降低了开发人员之间协同以及维护的成本,提升了开发效率. 缺点:但是在垂直架构

模拟MMU设计一个将IPv4地址索引化的路由表,不同于DxR

我不知道有没有人这么玩过,也许有,也许没有.时间和空间永远都在厚此薄彼,只因为设施不全,在资源匮乏的年代,只能取舍.但是如果资源丰盈,鱼 与熊掌,完全可以兼得!对于路由查找而言,紧凑的数据结构占用了很小的空间,难道它就要为此付出时间的代价吗?如果我们考虑MMU设施,就会发现,紧凑的 数据结构不但节省了空间,还提高了速度.       我们长期受到的教育就是取义一定要舍身这样的教育,如果不舍身,取到的不会是义,也可能会被讹诈,不怪自己被讹,只因自己没死.其实仔细想想,即便在资源 不那么丰盈,甚至资