Mirson - 多一些分享, 多一些进步

一、首先声明gRPC接口这里引入的是最新的gRpc-core 1.37版本， 采用的grcp-spring-boot-starter封装的版本进行实现，github地址：https://github.com/yidongnan/grpc-spring-boot-starter要实现gRpc通讯， 先定义接口以及入参出参信息syntax = "proto3";option java_multiple_files = true;option java_package = "com.grpc.s

1. 概述RPC 的主要功能目标是让构建分布式计算（应用）更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性。为实现该目标，RPC 框架需提供一种透明调用机制，让使用者不必显式的区分本地调用和远程调用。2. 优势RPC的设计让客户端对远程方法的调用是透明的，并不知道这个调用的方法是部署哪里。通过RPC能解耦服务。分布式设计部署灵活解耦服务扩展性强3. RPC框架六种主流RPC框架:Dubbo：国内最早开源的 RPC 框架，由阿里巴巴公司开发并于 2011 年末对外

1. RPC调用流程具体调用过程：服务消费者（client客户端）通过本地调用的方式调用服务。客户端存根（client stub）接收到请求后负责将方法、入参等信息序列化（组装）成能够进行网络传输的消息体。客户端存根（client stub）找到远程的服务地址，并且将消息通过网络发送给服务端。服务端存根（server stub）收到消息后进行解码（反序列化操作）。服务端存根（server stub）根据解码结果调用本地的服务进行相关处理。本地服务执行具体业务逻辑并将处理结果返回给服务端存根

RPC序列化流程序列化的作用在网络传输中，数据必须采用二进制形式， 所以在RPC调用过程中， 需要采用序列化技术，对入参对象和返回值对象进行序列化与反序列化。序列化原理自定义的二进制协议来实现序列化：一个对象是如何进行序列化? 下面以User对象例举讲解:User对象:package com.itcast;public class User { /** * 用户编号 */ private String userNo = "0001".

1. 动态代理调用流程RPC的调用对用户来讲是透明的，内部具体是如何实现呢？核心技术采用的就是动态代理，RPC 会自动给接口生成一个代理类，当我们在项目中注入初始化接口的时候，运行过程中实际绑定的是这个接口生成的代理类。在接口方法被调用的时候，它实际上是被生成代理类拦截到了，这样就可以在生成的代理类里面，加入其他调用处理逻辑。2. 为什么要加入动态代理如果没有动态代理, 服务端大量的接口将不便于管理，需要大量的if判断，如果扩展了新的接口，需要更改调用逻辑， 不利于扩展维护。动态代理可

服务注册发现的作用 在高可用的生产环境中，一般都以集群方式提供服务，集群里面的IP可能随时变化，也可能会随着维护扩充或减少节点，客户端需要能够及时感知服务端的变化，获取集群最新服务节点的连接信息。服务注册发现功能1）服务注册：在服务提供方启动的时候，将对外暴露的接口注册到注册中心内，注册中心将这个服务节点的 IP 和接口等连接信息保存下来。为了检测服务的服务端的有效状态，一般会建立双向心跳机制。2）服务订阅：在服务调用方启动的时候，客户端去注册中心查找并订阅服务提供方的 IP，然后缓存到本地，.

1. 为什么需要时间轮？在Dubbo中，为增强系统的容错能力，会有相应的监听判断处理机制。比如RPC调用的超时机制的实现，消费者判断RPC调用是否超时，如果超时会将超时结果返回给应用层。在Dubbo最开始的实现中，是将所有的返回结果（DefaultFuture）都放入一个集合中，并且通过一个定时任务，每隔一定时间间隔就扫描所有的future，逐个判断是否超时。这样的实现方式虽然比较简单，但是存在一个问题就是会有很多无意义的遍历操作开销。比如一个RPC调用的超时时间是10秒，而设置的超时判定的定时任务是

为什么要采用异步？ 影响到性能和吞吐量的根本原因是什么呢？ 其实就是RPC请求的整体耗时，如果采用同步调用， CPU 大部分的时间都在等待而没有去计算，从而导致 CPU 的利用率不够。这就好比工地里面搬砖，砌墙，捣水泥都由一个人干，其他人旁观， 那效率就十分低下。RPC 请求比较耗时的原因主要是在哪里？在大多数情况下，RPC 本身处理请求的效率是在毫秒级的。RPC 请求的耗时大部分都是业务耗时，比如业务逻辑中有访问数据库执行慢 SQL 的操作，核心是在I/O瓶颈。所以说，在大多数情况下，影响到 R.

为什么要采用路由？真实的环境中一般是以集群的方式提供服务，但对于服务调用方来说，一个接口会有多个服务提供方同时提供服务，所以 RPC 在每次发起请求的时候，都需要从多个服务节点里面选取一个用于处理请求的服务节点。每次上线应用的时候都不止运行一台服务器实例，上线就会涉及到变更，只要变更就可能导致原本正常运行的节点出现异常，尤其是发生重大变动或升级的时候，导致应用服务的不稳定因素就很多。为减少这种风险，一般会选择灰度方式发布应用实例，比如可以先发布部分实例观察是否存在异常，后续再根据使用的情况，选择发布.

为什么要进行限流？RPC 是解决分布式系统架构通讯的一大利器，而分布式系统设计需要面临高并发问题。在这样的情况下，我们提供的每个服务节点都可能由于访问量过大而引起一系列问题，比如业务处理耗时过长、CPU 飚高、频繁 Full GC 以及服务进程假死宕机等问题。在实际生产环境中，我们要保证服务的稳定性和高可用特性，就需要业务提供方能够进行自我保护，从而保证在高访问量、高并发的场景下，系统依然能够稳定，高效运行。服务端的自我保护实现 在 RPC 框架中集成限流功能，可以根据实际情况配置限流阈值；我.

1. 流量复制回放流量复制的作用 在开发新需求的过程中，我们可能会对应用进行重构和拆分，很难做到不改动老逻辑，只要有改动就有可能会出现问题。如果比较严谨的话，在开发完成后，会重新将 TestCase 都跑一遍，并同时补充新功能的 TestCase。如果是小改动的业务需求，这种做法一般不会出现大的问题。但对于大改动的应用，比如很多基础逻辑都被改动过，这时候如果还是通过已有的 Case 去做覆盖验证，很难保证应用上线后不出现故障，因为线上运行的真实环境要复杂很多， TestCase是很难覆盖所有细节场景

一. 优雅启动什么是启动预热启动预热就是让刚启动的服务，不直接承担全部的流量，而是让它随着时间的移动慢慢增加调用次数，最终让流量缓和运行一段时间后达到正常水平。如何实现首先对于调用方来说，我们要知道服务提供方的启动时间，这里有两种获取方法：一种是服务提供方在启动的时候，主动将启动的时间发送给注册中心；另一种就是注册中心来检测， 将服务提供方的请求注册时间作为启动时间。这两者时间会有一些差异， 但并没有关系， 因为整个预热过程的时间是一个粗略值，即使多个机器节点之间存在 1 分钟的误差也不会影