标签：invoke 临时 复杂 压力 业务员 模式 官方 和我 目标
首先这篇文章是要带大家来实现一个框架，听到框架大家可能会觉得非常高大上，其实这和我们平时写业务员代码没什么区别，但是框架是要给别人使用的，所以我们要换位思考，怎么才能让别人用着舒服，怎么样才能让我们的框架性能优异。通过自己写一个框架，我们能学到的有很多，能让我们脱离 CURD，在更高的层面上去思考。
写这个框架最主要的目的是要让大家了解整个框架的设计思想和用到的技术，并不是让大家关注代码，当然我实现的代码一定不是完美的，还有很多需要改进的地方，希望大家不吝赐教，一起进步。
如果把所有细节给大家讲清楚，那完全可以出一本书了。我们的文章当然也会将细节，不过希望大家有一些知识储备，这样我们才能重点去关注设计思想，了解如何去设计这个 RPC 框架，把自己想不通的地方给想明白了。
这个框架到底解决了什么问题？我们在什么场景下需要使用这个框架那？我们先来了解一个概念。
微服务架构
微服务架构旨在将原来传统的单体的 web 程序进行解耦，按功能进行划分，将原来的大应用拆分成一个一个小的服务。这样很大程度上提高了整个系统的可伸缩行，可以高效的应对各种各样的并发和数据压力。
来看官方定义：
1、一些由独立的服务共同组成系统
2、单独部署，跑在自己的进程中
3、每个服务为独立的业务开发
4、分布式管理
5、非常强调隔离性
微服务已经成为目前互联网公司的标配了，使用微服务时我们需要思考一个问题，原来是在一个程序内，现在被拆分成不同的程序，而且很有可能部署在不同的服务器上。那么服务之间如何通信那？
RPC
RPC 是一种远程调用协议，他可以高效准确的完成服务之间的相互调用，而且最重要的是用户不需要关心 RPC 协议的底层实现，网络传输使用 Http，Netty，还是 Socket 都可以。
有人可能会有疑问，我用 http 请求，里面写上目标的 ip，端口，加上参数不是也能调用服务并且返回数据吗？为什么要引入 RPC 这个概念那？
如果你能思考到这，说明你已经很厉害了，懂得在使用工具时思考为什么。
对于直接使用 http 请求来说，适合接口较少，服务之间相互调用不多的情况，而且需要指定地址，端口等等信息。优点就是简单直接，但是无法应对高并发以及复杂服务交互的情况。
RPC 就是为了解决上面的问题而生的，首先用户只需要调用服务即可，连接和发送数据交给底层协议去完成，另外对于高并发支持非常好，另外提供服务治理，注册中心等功能。适合大型网站，服务复杂，高并发的情况。
从一个点看 RPC 的架构
使用过 Dubbo 等 RPC 框架的应该知道，我们可以像调用本地方法一样调用另一个服务器上的服务，有的人可能不明白这句话时什么意思，代码演示一下。
UserService 是另一个服务器上的服务，我们可以像调用本地方法一样调用，不用管底层协议，不够用管 UserService 在哪个服务器上。
UserService userService = ProxyFactory.getProxy(UserService.class);
User user = userService.get("11112");那么我们是如何把在另外一个服务器上的服务拿到我们本地来的那？有人看上面的 ProxyFactory 可能就已经猜出来了，使用的是动态代理，我们在本地获取到了接口的代理类，在 invoke 方法中将参数传给对应的服务，服务端在接收到数据后，使用反射调用对应的实现类，完成处理后将结果返回给调用端。
如果你不明白上面的解释，我们用一张图来解释这个过程：
简单点说，RPC 帮我们把对应的请求发过去，服务端有一个服务器一直接收这种请求，收到数据后调用服务对应的处理方法处理后返回给调用端。
带你手写基于 Spring 的可插拔式 RPC 框架（一）介绍
标签：invoke 临时 复杂 压力 业务员 模式 官方 和我 目标
原文地址：https://www.cnblogs.com/paulwang92115/p/11116923.html
