RPC概述什么是RPC
远程过程调用。
首先，介绍本地方法调用。 假设在main方法中调用本地方法multiply (同一进程中的方法调用)。 我只是做了存储器寻址和一些堆栈操作。
假设main方法和multiply方法不在同一个进程中，两者用RPC方式进行调用(通信)。 因为是网络间通信，所以有必要考虑如何将方法调用和参数转换为可以在网络上传送的二进制流()涉及参数和结果的序列化、反序列化、套接字网络的编程等详细内容)。 这就是RPC框架的含义，它屏蔽了开发者的网络编程和网络传输细节，帮助开发者调用远程方法，使其调用本地方法。
请注意是RPC并不是一种具体的技术框架，而不是技术思想。
广义地，用于经由网络远程调用另一进程的方法的技术可以被称为RPC。
RPC不是新概念，也不是与微服务同一时代的概念。
在微服务之前，就有很多可以称为RPC的技术理念。 例如RMI、web服务。
RMI
远程方法调用。 比较老。 是EJB的通信基础，是实现RPC的一组Java Api，由于依赖于JVM，所以需要调用Java Api之间的方法，不能实现跨语言调用
web服务
语言之间、平台之间。 web服务的基础依赖于HTTP和XML，因此它们都与语言无关。
RPC有什么具体例子
随着时代的发展，越来越多优秀的RPC框架进入了我们的视野。 例如
RPC :谷歌开源高性能RPC框架。 基于HTTP2协议，将protobuf作为序列化协议。 具有很好的跨平台特性。 dubbo :蚂蚁开源的RPC框架是在RPC中引入了ApacheFinagle:twitter的RPC框架Thrift:Facebook的RPC框架Tars :腾讯的RPC框架
引入了RPC框架，使整个系统实现了微服务化。 如下所示。
提高系统可扩展性(优点)
提高了系统的可维护性(优点)
系统变得复杂(缺点)
引入新组件将使调试代码和维护系统时更加复杂
通过网络调用可能会增加性能开销(请参阅)
因此，引入RPC框架对系统进行微服务化时，必须综合考虑可扩展性、可维护性、复杂性、成本、性能等多方面。 必须慎重慎重。
RPC的基本原理RPC主要用于解决服务的远程调用问题，即客户端和服务器之间的通信问题。 设计RPC框架时，主要需要考虑以下几点
通信协议序列化IO模型RPC调用的通信过程是什么？
首先，客户端和服务器必须约定通信协议。 按照这样的协议组织数据时，序列化的数据必须是二进制流才能通过网络发送和接收数据。 然后，客户端整理方法名称和参数等数据，将二进制流经由网络发送到服务器端后，按照3通信协议分析数据，生成二进制流http://www .
通信协议需要注意TCP数据包的问题。 解决方案通常都有
发送和接收固定长度的数据(浪费网络带宽)的分组加上长度信息并携带)需要固定的空间来传输长度信息(将特定的magic number用作数据分段)，无法确定是否传输了某些分组
序列化是将反序列化和数据相互转换的方式。
每次RPC调用都涉及两次序列化和两次反序列化过程(共四次)。
因此，选择二进制流时要小心，以免序列化成为整个RPC通信的性能瓶颈。 选择序列化方案时，请注意以下事项：
序列化方式
(相反)执行序列化需要时间
序列化软件包的大小
由于网络带宽是恒定的，因此性能选择更高的串行化方案可以减少高并发RPC通信的带宽消耗
易读性
类似于json、xml，是一种可读性很好的序列化方式，序列化后的结果均为压缩比可读性好，主要便于调试和问题排除。
需要在这三者之间进行取舍和权衡。
文本
java serializable (不得跨越语言) json，xml )可读性强、通用性强，但体
积较大）hessian，protobuf，thrift（二进制的序列化，性能高，序列化后的包体积小） IO模型常见的IO模型，如下
阻塞IO非阻塞IO多路复用IO（对应Java的NIO）信号驱动IO异步IO（Java的AIO）通常使用较多的是多路复用IO。异步IO还不够成熟
服务治理目前业界开源的RPC框架中，更多的都是属于服务框架，而不是单纯的RPC框架。
服务框架和RPC框架的区别在于：RPC框架只是简单的解决通信问题，而服务框架，除了解决通信问题，还需要解决服务管理的问题。
所以我们需要了解，服务治理需要解决什么问题，以及它是如何解决的。
服务治理有哪些方面？
服务注册与发现服务追踪（分布式追踪）配置管理服务熔断，降级，分流服务负载均衡服务监控 注册中心过程
服务启动时向注册中心注册服务节点地址客户端从注册中心获取服务的地址列表有新的服务注册上来后，客户端可以得到通知有服务出现故障或者关闭时，客户端也可以得到通知服务节点间隔固定时间向注册中心发送心跳，表明健康状况优点
客户端无需重启就能感知服务节点的动态变化可以通过为服务节点增加权重，来辅助负载均衡选型
分布式一致性协调系统
zookeeper，etcd，consul
可以当作注册中心使用，但可能功能不是很齐全，比如无法对服务做健康检测
开源的，专门的注册中心
nacos（阿里开源），eureka（springCloud），vintage（微博使用）
功能比较完善
服务追踪分布式追踪系统，主要是用于解决分布式环境下的问题排查的问题。
当我们把一个系统，拆成多个微服务之后，一次来自客户端的请求，可能会引发微服务之间的十几次，甚至几十次请求，才能得到最终的结果。
比如系统的响应时间变慢了，或者系统出了一些问题，那么我们需要知道是具体哪个微服务导致的，这就需要对整个调用链进行追踪。
分布式追踪的基本原理是：
一次来自客户端的调用，对应一个唯一的traceId，用这个traceId来标识整个完整的调用链路
用另外一个spanId来标识一次微服务的调用。通过spanId来标识微服务之间的层级关系。
比如微服务A被调用，产生一个spanId为2，A又调用了另外2个微服务B和C，产生的spanId分别为2.1和2.2。这样就能清晰的知道微服务之间调用的层级关系
对这些调用日志进行收集，进行简单的聚合操作后， 写入到NoSQL数据库中
使用traceId就可以从NoSQL数据库中跟踪整个请求的链路，并得到各个链路的耗时
注意：由于一次客户端调用会导致很多次的微服务之间的调用，所以调用日志的量是巨大的。我们可以在收集调用日志后，进行一些简单的聚合操作，来减少日志量，或者通过采样的方式，只采样1%的调用日志。
配置管理项目所使用的一些配置文件的管理。
将配置做成文件，这样是静态的配置。将配置放到一个服务上，这样可以实现动态的配置管理和更新。
配置主要分为两种：
静态配置：比较固定的，不会经常发生变动的配置。比如数据库地址动态配置之：可能会经常发生变动的配置。比如超时时间。静态配置通常放在项目的配置文件中即可，而动态的配置则通常放到配置服务中。
选型
zookeeper，etcd，consulapollo（携程），diamond（淘宝），disconf（百度），都是以mysql为存储vintage（微博），以redis为存储 服务容错一个系统拆成了多个服务。原本只有1个可能出现问题的点，现在变成了多个。
当系统出现未知问题，或者系统流量超出极限时，要如何应对？常见方式如下
熔断：当下游服务不可用时，暂时屏蔽下游服务，以保障整体服务可用的方法降级：当流量激增时，对于某些页面或者服务，暂时屏蔽，以减轻服务器压力的方法限流：限制瞬时大流量以保护整体服务的方法选型
hystrixsentinel（阿里）dubbo 负载均衡为了应对大流量，通常对于一个服务会部署多台节点。那么此时就需要将流量分配到多个服务节点。
常见负载均衡算法
一致性哈希随机轮询（加权轮询）最少连接（选择当前连接数最少的节点） 服务监控从运维上对服务进行监控。
通常关注2个方面：需要监控什么？怎么监控？
服务监控的指标：
请求量：接口请求量，缓存请求量，数据库请求量响应时间：接口响应时间，缓存响应时间错误率：调用第三方服务错误率监控系统构成
数据采集：flume，filebeat数据处理：storm，spark数据存储：mysql，hbase，influxDB数据展示：grafana RPC实例分析以dubbo为例，进行分析
dubbo的微内核架构是如何设计的dubbo是如何调用服务的dubbo内嵌的服务治理策略是怎样的 dubbo介绍 dubbot是一款高性能的服务框架在2021年由阿里开源2018年，阿里将dubbo捐赠给Apache借鉴dubbo的RPC框架还有dubbox（当当），motan（微博） dubbo架构特点 微内核+扩展点架构微内核负责组装扩展点，实现整体逻辑扩展点可以让功能点被用户自定义实现dubbo的扩展点是通过SPI（Service Provider Interface）机制实现的（借鉴了JDK的SPI机制）。dubbo会从以下目录加载实现类
META-INF/services/*META-INF/dubbo/*META-INF/dubbo/internal/*格式：key=实现类的全限定名
在代码中即可通过这个key来加载某个接口的某个特定的实现类
dubbo的服务调用略