mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-08-01 16:28:03 +08:00
[docs add]RPC基础常见知识点&面试题总结
This commit is contained in:
parent
ed9c7e74b2
commit
1330f3fc29
@ -243,7 +243,6 @@ RPC makes calling remote service calls as easy as calling local methods.
|
||||
Dubbo is a home-grown RPC framework , open source by Ali . Related reading.
|
||||
|
||||
- [Dubbo FAQ Summary](docs/distributed-system/rpc/dubbo.md)
|
||||
- [Why don't we use RPC instead of HTTP directly for calls between services?](docs/distributed-system/rpc/why-use-rpc.md)
|
||||
|
||||
### API gateway
|
||||
|
||||
|
@ -289,8 +289,8 @@ RPC 让调用远程服务调用像调用本地方法那样简单。
|
||||
|
||||
Dubbo 是一款国产的 RPC 框架,由阿里开源。相关阅读:
|
||||
|
||||
* [Dubbo 常见问题总结](docs/distributed-system/rpc/dubbo.md)
|
||||
* [服务之间的调用为啥不直接用 HTTP 而用 RPC?](docs/distributed-system/rpc/why-use-rpc.md)
|
||||
* [RPC 基础常见知识点&面试题总结](docs/distributed-system/rpc/rpc-intro.md)
|
||||
* [Dubbo 常见知识点&面试题总结](docs/distributed-system/rpc/dubbo.md)
|
||||
|
||||
### API 网关
|
||||
|
||||
|
@ -364,7 +364,7 @@ export const sidebarConfig = defineSidebarConfig({
|
||||
text: "RPC",
|
||||
prefix: "rpc/",
|
||||
collapsable: true,
|
||||
children: ["dubbo", "why-use-rpc"],
|
||||
children: ["rpc-intro", "dubbo"],
|
||||
},
|
||||
"distributed-transaction",
|
||||
{
|
||||
|
@ -1,53 +1,14 @@
|
||||
# Dubbo知识点&面试题总结
|
||||
---
|
||||
title: Dubbo常见知识点&面试题总结
|
||||
category: 分布式
|
||||
tag:
|
||||
- rpc
|
||||
---
|
||||
|
||||
> 说明: Dubbo3 已经发布,这篇文章是基于 Dubbo2 写的。Dubbo3 基于 Dubbo2 演进而来,在保持原有核心功能特性的同时, Dubbo3 在易用性、超大规模微服务实践、云原生基础设施适配、安全设计等几大方向上进行了全面升级。
|
||||
|
||||
这篇文章是我根据官方文档以及自己平时的使用情况,对 Dubbo 所做的一个总结。欢迎补充!
|
||||
|
||||
## RPC基础
|
||||
|
||||
### 何为 RPC?
|
||||
|
||||
**RPC(Remote Procedure Call)** 即远程过程调用,通过名字我们就能看出 RPC 关注的是远程调用而非本地调用。
|
||||
|
||||
**为什么要 RPC ?** 因为,两个不同的服务器上的服务提供的方法不在一个内存空间,所以,需要通过网络编程才能传递方法调用所需要的参数。并且,方法调用的结果也需要通过网络编程来接收。但是,如果我们自己手动网络编程来实现这个调用过程的话工作量是非常大的,因为,我们需要考虑底层传输方式(TCP还是UDP)、序列化方式等等方面。
|
||||
|
||||
|
||||
**RPC 能帮助我们做什么呢?** 简单来说,通过 RPC 可以帮助我们调用远程计算机上某个服务的方法,这个过程就像调用本地方法一样简单。并且!我们不需要了解底层网络编程的具体细节。
|
||||
|
||||
|
||||
举个例子:两个不同的服务 A、B 部署在两台不同的机器上,服务 A 如果想要调用服务 B 中的某个方法的话就可以通过 RPC 来做。
|
||||
|
||||
一言蔽之:**RPC 的出现就是为了让你调用远程方法像调用本地方法一样简单。**
|
||||
|
||||
### RPC 的原理是什么?
|
||||
|
||||
为了能够帮助小伙伴们理解 RPC 原理,我们可以将整个 RPC的 核心功能看作是下面👇 6 个部分实现的:
|
||||
|
||||
|
||||
1. **客户端(服务消费端)** :调用远程方法的一端。
|
||||
1. **客户端 Stub(桩)** : 这其实就是一代理类。代理类主要做的事情很简单,就是把你调用方法、类、方法参数等信息传递到服务端。
|
||||
1. **网络传输** : 网络传输就是你要把你调用的方法的信息比如说参数啊这些东西传输到服务端,然后服务端执行完之后再把返回结果通过网络传输给你传输回来。网络传输的实现方式有很多种比如最近基本的 Socket或者性能以及封装更加优秀的 Netty(推荐)。
|
||||
1. **服务端 Stub(桩)** :这个桩就不是代理类了。我觉得理解为桩实际不太好,大家注意一下就好。这里的服务端 Stub 实际指的就是接收到客户端执行方法的请求后,去指定对应的方法然后返回结果给客户端的类。
|
||||
1. **服务端(服务提供端)** :提供远程方法的一端。
|
||||
|
||||
具体原理图如下,后面我会串起来将整个RPC的过程给大家说一下。
|
||||
|
||||
|
||||

|
||||
|
||||
1. 服务消费端(client)以本地调用的方式调用远程服务;
|
||||
1. 客户端 Stub(client stub) 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体(序列化):`RpcRequest`;
|
||||
1. 客户端 Stub(client stub) 找到远程服务的地址,并将消息发送到服务提供端;
|
||||
1. 服务端 Stub(桩)收到消息将消息反序列化为Java对象: `RpcRequest`;
|
||||
1. 服务端 Stub(桩)根据`RpcRequest`中的类、方法、方法参数等信息调用本地的方法;
|
||||
1. 服务端 Stub(桩)得到方法执行结果并将组装成能够进行网络传输的消息体:`RpcResponse`(序列化)发送至消费方;
|
||||
1. 客户端 Stub(client stub)接收到消息并将消息反序列化为Java对象:`RpcResponse` ,这样也就得到了最终结果。over!
|
||||
|
||||
相信小伙伴们看完上面的讲解之后,已经了解了 RPC 的原理。
|
||||
|
||||
虽然篇幅不多,但是基本把 RPC 框架的核心原理讲清楚了!另外,对于上面的技术细节,我会在后面的章节介绍到。
|
||||
|
||||
**最后,对于 RPC 的原理,希望小伙伴不单单要理解,还要能够自己画出来并且能够给别人讲出来。因为,在面试中这个问题在面试官问到 RPC 相关内容的时候基本都会碰到。**
|
||||
|
||||
## Dubbo基础
|
||||
|
||||
### 什么是 Dubbo?
|
||||
|
139
docs/distributed-system/rpc/rpc-intro.md
Normal file
139
docs/distributed-system/rpc/rpc-intro.md
Normal file
@ -0,0 +1,139 @@
|
||||
---
|
||||
title: RPC基础常见知识点&面试题总结
|
||||
category: 分布式
|
||||
tag:
|
||||
- rpc
|
||||
---
|
||||
|
||||
简单介绍一下 RPC 相关的基础概念。
|
||||
|
||||
## 何为 RPC?
|
||||
|
||||
**RPC(Remote Procedure Call)** 即远程过程调用,通过名字我们就能看出 RPC 关注的是远程调用而非本地调用。
|
||||
|
||||
**为什么要 RPC ?** 因为,两个不同的服务器上的服务提供的方法不在一个内存空间,所以,需要通过网络编程才能传递方法调用所需要的参数。并且,方法调用的结果也需要通过网络编程来接收。但是,如果我们自己手动网络编程来实现这个调用过程的话工作量是非常大的,因为,我们需要考虑底层传输方式(TCP还是UDP)、序列化方式等等方面。
|
||||
|
||||
|
||||
**RPC 能帮助我们做什么呢?** 简单来说,通过 RPC 可以帮助我们调用远程计算机上某个服务的方法,这个过程就像调用本地方法一样简单。并且!我们不需要了解底层网络编程的具体细节。
|
||||
|
||||
|
||||
举个例子:两个不同的服务 A、B 部署在两台不同的机器上,服务 A 如果想要调用服务 B 中的某个方法的话就可以通过 RPC 来做。
|
||||
|
||||
一言蔽之:**RPC 的出现就是为了让你调用远程方法像调用本地方法一样简单。**
|
||||
|
||||
## RPC 的原理是什么?
|
||||
|
||||
为了能够帮助小伙伴们理解 RPC 原理,我们可以将整个 RPC的 核心功能看作是下面👇 6 个部分实现的:
|
||||
|
||||
|
||||
1. **客户端(服务消费端)** :调用远程方法的一端。
|
||||
1. **客户端 Stub(桩)** : 这其实就是一代理类。代理类主要做的事情很简单,就是把你调用方法、类、方法参数等信息传递到服务端。
|
||||
1. **网络传输** : 网络传输就是你要把你调用的方法的信息比如说参数啊这些东西传输到服务端,然后服务端执行完之后再把返回结果通过网络传输给你传输回来。网络传输的实现方式有很多种比如最近基本的 Socket或者性能以及封装更加优秀的 Netty(推荐)。
|
||||
1. **服务端 Stub(桩)** :这个桩就不是代理类了。我觉得理解为桩实际不太好,大家注意一下就好。这里的服务端 Stub 实际指的就是接收到客户端执行方法的请求后,去指定对应的方法然后返回结果给客户端的类。
|
||||
1. **服务端(服务提供端)** :提供远程方法的一端。
|
||||
|
||||
具体原理图如下,后面我会串起来将整个RPC的过程给大家说一下。
|
||||
|
||||
|
||||

|
||||
|
||||
1. 服务消费端(client)以本地调用的方式调用远程服务;
|
||||
1. 客户端 Stub(client stub) 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体(序列化):`RpcRequest`;
|
||||
1. 客户端 Stub(client stub) 找到远程服务的地址,并将消息发送到服务提供端;
|
||||
1. 服务端 Stub(桩)收到消息将消息反序列化为Java对象: `RpcRequest`;
|
||||
1. 服务端 Stub(桩)根据`RpcRequest`中的类、方法、方法参数等信息调用本地的方法;
|
||||
1. 服务端 Stub(桩)得到方法执行结果并将组装成能够进行网络传输的消息体:`RpcResponse`(序列化)发送至消费方;
|
||||
1. 客户端 Stub(client stub)接收到消息并将消息反序列化为Java对象:`RpcResponse` ,这样也就得到了最终结果。over!
|
||||
|
||||
相信小伙伴们看完上面的讲解之后,已经了解了 RPC 的原理。
|
||||
|
||||
虽然篇幅不多,但是基本把 RPC 框架的核心原理讲清楚了!另外,对于上面的技术细节,我会在后面的章节介绍到。
|
||||
|
||||
**最后,对于 RPC 的原理,希望小伙伴不单单要理解,还要能够自己画出来并且能够给别人讲出来。因为,在面试中这个问题在面试官问到 RPC 相关内容的时候基本都会碰到。**
|
||||
|
||||
## 有哪些常见的 RPC 框架?
|
||||
|
||||
我们这里说的 RPC 框架指的是可以让客户端直接调用服务端方法,就像调用本地方法一样简单的框架,比如我下面介绍的 Dubbo、Motan、gRPC这些。 如果需要和 HTTP 协议打交道,解析和封装 HTTP 请求和响应。这类框架并不能算是“RPC 框架”,比如Feign。
|
||||
|
||||
### Dubbo
|
||||
|
||||

|
||||
|
||||
Apache Dubbo 是一款微服务框架,为大规模微服务实践提供高性能 RPC 通信、流量治理、可观测性等解决方案,
|
||||
涵盖 Java、Golang 等多种语言 SDK 实现。
|
||||
|
||||
Dubbo 提供了从服务定义、服务发现、服务通信到流量管控等几乎所有的服务治理能力,支持 Triple 协议(基于 HTTP/2 之上定义的下一代 RPC 通信协议)、应用级服务发现、Dubbo Mesh (Dubbo3 赋予了很多云原生友好的新特性)等特性。
|
||||
|
||||

|
||||
|
||||
Dubbo 是由阿里开源,后来加入了 Apache 。正式由于 Dubbo 的出现,才使得越来越多的公司开始使用以及接受分布式架构。
|
||||
|
||||
Dubbo 算的是比较优秀的国产开源项目了,它的源码也是非常值得学习和阅读的!
|
||||
|
||||
- Github :[https://github.com/apache/incubator-dubbo](https://github.com/apache/incubator-dubbo "https://github.com/apache/incubator-dubbo")
|
||||
- 官网:https://dubbo.apache.org/zh/
|
||||
|
||||
### Motan
|
||||
|
||||
Motan 是新浪微博开源的一款 RPC 框架,据说在新浪微博正支撑着千亿次调用。不过笔者倒是很少看到有公司使用,而且网上的资料也比较少。
|
||||
|
||||
很多人喜欢拿 Motan 和 Dubbo 作比较,毕竟都是国内大公司开源的。笔者在查阅了很多资料,以及简单查看了其源码之后发现:**Motan 更像是一个精简版的 Dubbo,可能是借鉴了 Dubbo 的思想,Motan 的设计更加精简,功能更加纯粹。**
|
||||
|
||||
不过,我不推荐你在实际项目中使用 Motan。如果你要是公司实际使用的话,还是推荐 Dubbo ,其社区活跃度以及生态都要好很多。
|
||||
|
||||
- 从 Motan 看 RPC 框架设计:[http://kriszhang.com/motan-rpc-impl/](http://kriszhang.com/motan-rpc-impl/ "http://kriszhang.com/motan-rpc-impl/")
|
||||
- Motan 中文文档:[https://github.com/weibocom/motan/wiki/zh_overview](https://github.com/weibocom/motan/wiki/zh_overview "https://github.com/weibocom/motan/wiki/zh_overview")
|
||||
|
||||
### gRPC
|
||||
|
||||

|
||||
|
||||
gRPC 是 Google 开源的一个高性能、通用的开源 RPC 框架。其由主要面向移动应用开发并基于 HTTP/2 协议标准而设计(支持双向流、消息头压缩等功能,更加节省带宽),基于 ProtoBuf 序列化协议开发,并且支持众多开发语言。
|
||||
|
||||
**何谓 ProtoBuf?** [ProtoBuf( Protocol Buffer)](https://github.com/protocolbuffers/protobuf) 是一种更加灵活、高效的数据格式,可用于通讯协议、数据存储等领域,基本支持所有主流编程语言且与平台无关。不过,通过 ProtoBuf 定义接口和数据类型还挺繁琐的,这是一个小问题。
|
||||
|
||||

|
||||
|
||||
不得不说,gRPC 的通信层的设计还是非常优秀的,[Dubbo-go 3.0](https://dubbogo.github.io/) 的通信层改进主要借鉴了 gRPC。
|
||||
|
||||
不过,gRPC 的设计导致其几乎没有服务治理能力。如果你想要解决这个问题的话,就需要依赖其他组件比如腾讯的 PolarisMesh(北极星)了。
|
||||
|
||||
- Github:[https://github.com/grpc/grpc](https://github.com/grpc/grpc "https://github.com/grpc/grpc")
|
||||
- 官网:[https://grpc.io/](https://grpc.io/ "https://grpc.io/")
|
||||
|
||||
### Thrift
|
||||
|
||||
Apache Thrift 是 Facebook 开源的跨语言的 RPC 通信框架,目前已经捐献给 Apache 基金会管理,由于其跨语言特性和出色的性能,在很多互联网公司得到应用,有能力的公司甚至会基于 thrift 研发一套分布式服务框架,增加诸如服务注册、服务发现等功能。
|
||||
|
||||
`Thrift`支持多种不同的**编程语言**,包括`C++`、`Java`、`Python`、`PHP`、`Ruby`等(相比于 gRPC 支持的语言更多 )。
|
||||
|
||||
- 官网:[https://thrift.apache.org/](https://thrift.apache.org/ "https://thrift.apache.org/")
|
||||
- Thrift 简单介绍:[https://www.jianshu.com/p/8f25d057a5a9](https://www.jianshu.com/p/8f25d057a5a9 "https://www.jianshu.com/p/8f25d057a5a9")
|
||||
|
||||
### 总结
|
||||
|
||||
gRPC 和 Thrift 虽然支持跨语言的 RPC 调用,但是它们只提供了最基本的 RPC 框架功能,缺乏一系列配套的服务化组件和服务治理功能的支撑。
|
||||
|
||||
Dubbo 不论是从功能完善程度、生态系统还是社区活跃度来说都是最优秀的。而且,Dubbo在国内有很多成功的案例比如当当网、滴滴等等,是一款经得起生产考验的成熟稳定的 RPC 框架。最重要的是你还能找到非常多的 Dubbo 参考资料,学习成本相对也较低。
|
||||
|
||||
下图展示了 Dubbo 的生态系统。
|
||||
|
||||

|
||||
|
||||
Dubbo 也是 Spring Cloud Alibaba 里面的一个组件。
|
||||
|
||||

|
||||
|
||||
但是,Dubbo 和 Motan 主要是给 Java 语言使用。虽然,Dubbo 和 Motan 目前也能兼容部分语言,但是不太推荐。如果需要跨多种语言调用的话,可以考虑使用 gRPC。
|
||||
|
||||
综上,如果是 Java 后端技术栈,并且你在纠结选择哪一种 RPC 框架的话,我推荐你考虑一下 Dubbo。
|
||||
|
||||
## 如何设计并实现一个 RPC 框架?
|
||||
|
||||
**《手写 RPC 框架》** 是我的[知识星球](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc)的一个内部小册,我写了 12 篇文章来讲解如何从零开始基于 Netty+Kyro+Zookeeper 实现一个简易的 RPC 框架。
|
||||
|
||||
麻雀虽小五脏俱全,项目代码注释详细,结构清晰,并且集成了 Check Style 规范代码结构,非常适合阅读和学习。
|
||||
|
||||
**内容概览** :
|
||||
|
||||

|
@ -1,75 +0,0 @@
|
||||
# 服务之间的调用为啥不直接用 HTTP 而用 RPC?
|
||||
|
||||
## 什么是 RPC?RPC原理是什么?
|
||||
|
||||
### **什么是 RPC?**
|
||||
|
||||
RPC(Remote Procedure Call)—远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。比如两个不同的服务 A、B 部署在两台不同的机器上,那么服务 A 如果想要调用服务 B 中的某个方法该怎么办呢?使用 HTTP请求 当然可以,但是可能会比较慢而且一些优化做的并不好。 RPC 的出现就是为了解决这个问题。
|
||||
|
||||
### **RPC原理是什么?**
|
||||
|
||||

|
||||
|
||||
1. 服务消费端(client)以本地调用的方式调用远程服务;
|
||||
2. 客户端 Stub(client stub) 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体(序列化):`RpcRequest`;
|
||||
3. 客户端 Stub(client stub) 找到远程服务的地址,并将消息发送到服务提供端;
|
||||
4. 服务端 Stub(桩)收到消息将消息反序列化为Java对象: `RpcRequest`;
|
||||
5. 服务端 Stub(桩)根据`RpcRequest`中的类、方法、方法参数等信息调用本地的方法;
|
||||
6. 服务端 Stub(桩)得到方法执行结果并将组装成能够进行网络传输的消息体:`RpcResponse`(序列化)发送至消费方;
|
||||
7. 客户端 Stub(client stub)接收到消息并将消息反序列化为Java对象:`RpcResponse` ,这样也就得到了最终结果。
|
||||
|
||||
下面再贴一个网上的时序图,辅助理解:
|
||||
|
||||

|
||||
|
||||
### RPC 解决了什么问题?
|
||||
|
||||
从上面对 RPC 介绍的内容中,概括来讲RPC 主要解决了:**让分布式或者微服务系统中不同服务之间的调用像本地调用一样简单。**
|
||||
|
||||
### 常见的 RPC 框架总结?
|
||||
|
||||
- **RMI(JDK自带):** JDK自带的RPC,有很多局限性,不推荐使用。
|
||||
- **Dubbo:** Dubbo是 阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring框架无缝集成。目前 Dubbo 已经成为 Spring Cloud Alibaba 中的官方组件。
|
||||
- **gRPC** :gRPC是可以在任何环境中运行的现代开源高性能RPC框架。它可以通过可插拔的支持来有效地连接数据中心内和跨数据中心的服务,以实现负载平衡,跟踪,运行状况检查和身份验证。它也适用于分布式计算的最后一英里,以将设备,移动应用程序和浏览器连接到后端服务。
|
||||
- **Hessian:** Hessian是一个轻量级的remoting on http工具,使用简单的方法提供了RMI的功能。 相比WebService,Hessian更简单、快捷。采用的是二进制RPC协议,因为采用的是二进制协议,所以它很适合于发送二进制数据。
|
||||
- **Thrift:** Apache Thrift是Facebook开源的跨语言的RPC通信框架,目前已经捐献给Apache基金会管理,由于其跨语言特性和出色的性能,在很多互联网公司得到应用,有能力的公司甚至会基于thrift研发一套分布式服务框架,增加诸如服务注册、服务发现等功能。
|
||||
|
||||
### RPC学习材料
|
||||
|
||||
- [跟着 Guide 哥造轮子](https://github.com/Snailclimb/guide-rpc-framework)
|
||||
|
||||
## 既有 HTTP ,为啥用 RPC 进行服务调用?
|
||||
|
||||
### RPC 只是一种设计而已
|
||||
|
||||
RPC 只是一种概念、一种设计,就是为了解决 **不同服务之间的调用问题**, 它一般会包含有 **传输协议** 和 **序列化协议** 这两个。
|
||||
|
||||
但是,HTTP 是一种协议,RPC框架可以使用 HTTP协议作为传输协议或者直接使用TCP作为传输协议,使用不同的协议一般也是为了适应不同的场景。
|
||||
|
||||
### HTTP 和 TCP
|
||||
|
||||
**可能现在很多对计算机网络不太熟悉的朋友已经被搞蒙了,要想真正搞懂,还需要来简单复习一下计算机网络基础知识:**
|
||||
|
||||
> 我们通常谈计算机网络的五层协议的体系结构是指:应用层、传输层、网络层、数据链路层、物理层。
|
||||
>
|
||||
> **应用层(application-layer)的任务是通过应用进程间的交互来完成特定网络应用。** HTTP 属于应用层协议,它会基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)。HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过 URL 向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后,向客户端发送响应信息。HTTP协议建立在 TCP 协议之上。
|
||||
>
|
||||
> **传输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务**。TCP是传输层协议,主要解决数据如何在网络中传输。相比于UDP,**TCP** 提供的是**面向连接**的,**可靠的**数据传输服务。
|
||||
|
||||
### RPC框架功能更齐全
|
||||
|
||||
成熟的 RPC框架还提供好了“服务自动注册与发现”、"智能负载均衡"、“可视化的服务治理和运维”、“运行期流量调度”等等功能,这些也算是选择
|
||||
RPC 进行服务注册和发现的一方面原因吧!
|
||||
|
||||
**相关阅读:**
|
||||
|
||||
- http://www.ruanyifeng.com/blog/2016/08/http.html (HTTP 协议入门- 阮一峰)
|
||||
|
||||
### 一个常见的错误观点
|
||||
|
||||
很多文章中还会提到说 HTTP 协议相较于自定义 TCP 报文协议,增加的开销在于连接的建立与断开,但是这个观点已经被否认,下面截取自知乎中一个回答,原回答地址:https://www.zhihu.com/question/41609070/answer/191965937 。
|
||||
|
||||
>首先要否认一点 HTTP 协议相较于自定义 TCP 报文协议,增加的开销在于连接的建立与断开。HTTP 协议是支持连接池复用的,也就是建立一定数量的连接不断开,并不会频繁的创建和销毁连接。二一要说的是 HTTP 也可以使用 Protobuf 这种二进制编码协议对内容进行编码,因此二者最大的区别还是在传输协议上。
|
||||
|
||||
|
||||
|
@ -5,7 +5,7 @@ category: 知识星球
|
||||
|
||||
## 介绍
|
||||
|
||||
**《手写 RPC 框架》** 是我的[知识星球](../about-the-author/zhishixingqiu-two-years.md)的一个内部小册,我写了 12 篇文章来讲解如何从零开始基于 Netty+Kyro+Zookeeper 实现一个简易的 RPC 框架。
|
||||
**《手写 RPC 框架》** 是我的[知识星球](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc)的一个内部小册,我写了 12 篇文章来讲解如何从零开始基于 Netty+Kyro+Zookeeper 实现一个简易的 RPC 框架。
|
||||
|
||||
麻雀虽小五脏俱全,项目代码注释详细,结构清晰,并且集成了 Check Style 规范代码结构,非常适合阅读和学习。
|
||||
|
||||
|
@ -18,7 +18,7 @@ star: 5
|
||||
|
||||
## 介绍
|
||||
|
||||
**《Java 面试指北》** 是我的[知识星球](../about-the-author/zhishixingqiu-two-years.md)的一个内部小册,和 [JavaGuide 开源版](https://javaguide.cn/)的内容互补。相比于开源版本来说,《Java 面试指北》添加了下面这些内容(不仅仅是这些内容):
|
||||
**《Java 面试指北》** 是我的[知识星球](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc)的一个内部小册,和 [JavaGuide 开源版](https://javaguide.cn/)的内容互补。相比于开源版本来说,《Java 面试指北》添加了下面这些内容(不仅仅是这些内容):
|
||||
|
||||
- 10+ 篇文章手把手教你如何准备面试。
|
||||
- 更全面的八股文面试题(系统设计、常见框架、分布式、高并发 ......)。
|
||||
@ -56,7 +56,7 @@ star: 5
|
||||
|
||||

|
||||
|
||||
并且,[知识星球](../about-the-author/zhishixingqiu-two-years.md)还有专门分享面经和面试题的专题,里面会分享很多优质的面经和面试题。
|
||||
并且,[知识星球](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc)还有专门分享面经和面试题的专题,里面会分享很多优质的面经和面试题。
|
||||
|
||||

|
||||
|
||||
|
@ -6,7 +6,7 @@ star: true
|
||||
|
||||
## 介绍
|
||||
|
||||
**《Java 必读源码系列》** 是我的[知识星球](../about-the-author/zhishixingqiu-two-years.md)的一个内部小册,目前已经整理了 Dubbo 2.6.x 、Netty 4.x、SpringBoot 2.1 等框架/中间件的源码。
|
||||
**《Java 必读源码系列》** 是我的[知识星球](https://www.yuque.com/docs/share/8a30ffb5-83f3-40f9-baf9-38de68b906dc)的一个内部小册,目前已经整理了 Dubbo 2.6.x 、Netty 4.x、SpringBoot 2.1 等框架/中间件的源码。
|
||||
|
||||
结构清晰,内容详细,非常适合想要深入学习框架/中间件源码的同学阅读。
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user