开发扩展说明
【1】启动机制：提供 ProviderBootstrap、 ConsumerBootstrap分别作为服务提供者、服务消费者启动类，在项目中引用其初始化RPC框架
【2】注解驱动：引入自定义注解，实现类似Dubbo框架应用的注解配置：@EnableRpc、@RpcService、@RpcReference
【3】构建sample-springboot-provider、sample-springboot-consumer引入starter，使用注解配置完成RPC框架应用
可选扩展点
【1】RPC 请求类中支持携带参数列表，可用于安全校验等
参考思路:比如服务提供者参数列表、服务消费者参数列表，服务端收到请求后可以根据参数列表中的值，判断如何进一步处理，比如在参数列表中携带 token 可以实现安全校验。
【2】开发服务管理界面。
参考思路:类似 Nacos 注册中心面板，需要一定的前端基础
【3】项目支持读取 yml/yaml 等更多类型的配置文件，作为全局配置。
参考思路:仿照现有的 ConfigUtils 工具类，支持更多读取配置的方式，甚至可以使用 SPI 机制允许开发者二次扩展配置解析器。
核心构建说明
【1】容错机制概念、不同容错策略
【2】容错机制实现：定义容错策略接口、扩展不同的容错策略
【3】引入SPI机制和工厂模式：支持配置和自定义容错策略扩展
基于上述内容给RPC框架增加了重试机制，提升了服务消费端的可靠性和健壮性。但如果重试超过了一定次数仍然失败，又该怎么处理呢?或者说当调用出现失败时一定要重试么?有没有其他的策略呢?
此处引入一个提高服务消费端可靠性和健壮性的机制 -- 容错机制
扩展说明
【1】重试策略概念梳理、常见重试策略
【2】引入两种重试策略：不重试、固定时间间隔
【3】自定义重试策略接口定义，提供扩展重试策略
基于目前实现的RPC框架实现，如果使用RPC框架的服务消费者调用接口失败，就会直接报错。调用接口失败可能有很多原因，有时可能是服务提供者返回了错误，但有时可能只是网络不稳定或服务提供者重启等临时性问题。这种情况下，可能更希望服务消费者拥有自动重试的能力，提高系统的可用性。
扩展说明
【1】负载均衡概念梳理、常见负载均衡算法
【2】引入轮询、随机、一致性Hash三种负载均衡算法
【3】自定义负载均衡器，提供扩展负载均衡器接口
目前RPC框架已经可以从注册中心获取到服务提供者的注册信息了，同一个服务可能会有多个服务提供者，但是目前消费者始终读取了第一个服务提供者节点发起调用，不仅会增大单个节点的压力，而且没有利用好其他节点的资源。
引入负载均衡概念：可以从服务提供者节点中，选择一个服务提供者发起请求，而不是每次都请求同一个服务提供者（根据相应策略选择节点）
扩展核心
【1】自定义协议格式梳理（协议消息、相关协议数据字段枚举）
【2】基于Vert.x的TCP实现（参考基于Vert.x的HTTP实现思路进行构建）：先从demo（server、client）理解TCP协议的请求响应，然后在RPC框架中引入（服务提供者：server引用自定义的TcpServerHandler；服务消费者在ServerProxy中按照TCP协议规则处理响应）
【3】解决半包、粘包问题：使用Vert.x的RecordParse
【4】装饰者模式的场景应用：对半包、粘包方法进行封装（基于Handler进行装饰对buffer进行处理，引入TcpBufferHandlerWrapper）、修改ServiceProxy中TCP响应处理（将响应处理方法放在VertxTcpClient实现）
扩展核心
【1】序列化器概念和SPI机制引入
【2】自定义多种序列化器，结合SPI机制动态加载自定义序列化器
【3】提供扩展接口，可实现Serializer接口扩展自定义序列化器，随后将其注册并应用
问题分析
序列化器的作用：无论是请求或响应,都会涉及参数的传输。而Java对象是存活在JVM虚拟机中的,如果想在其他位置存储并访问、或者在网络中进行传输，就需要进行序列化和反序列化。
扩展核心
【1】注册中心概念引入：结合注册中心基础功能一步步完善设计
【2】基本实现：基于Etcd实现服务注册、服务发现
【3】扩展实现：心跳检测和续期机制、服务节点下线机制、消费端服务缓存、基于Zookeeper的注册中心实现（还可扩展其他注册中心）
RPC框架中的一个核心模块是注册中心，目的是为了帮助服务消费者获取到服务提供者的调用信息（地址、方法等），而不是将调用地址硬编码到项目中，在简易版RPC框架中使用的是LocalRegistry本地服务注册的方式存储接口服务信息，此处则引入注册中心完善RPC框架流程
扩展核心
【1】引入全局配置（框架配置核心构建）
【2】构建RpcApplication加载全局配置
在使用一些现有的RPC框架，可能会涉及到一些配置信息，例如注册中心地址、序列化方式、网络服务器端口号等。在基础版RPC框架中这些配置在程序中使用了硬编码实现，反而不利于维护。且RPC框架是需要被其他项目作为服务提供者或者服务消费者引入的，应当允许引入框架的项目通过编写配置文件来定义配置。一般情况下，服务提供者和服务消费者需要编写相同的RPC配置。因此，需要一套全局配置加载功能。能够让RPC框架轻松地从配置文件中读取配置，并且维护一个全局配置对象，便于框架快速获取到一致的配置。
扩展核心
【1】Mock概念引入：类似模拟数据（针对一些开发场景下无法调通服务的情况，提供一些模拟服务响应数据模拟远程服务行为，便于开发流程调通）
【2】Mock实现：设定mock属性（确认框架是否开启mock模式），通过代理模式构建MockService
什么是Mock？
RPC框架的核心功能是调用其他远程服务。但是在实际开发和测试过程中，有时可能无法直接访问真实的远程服务，或者访问真实的远程服务可能会产生不可控的影响，例如网络延迟、服务不稳定等。在这种情况下，就需要使用mock服务来模拟远程服务的行为，以便进行接口的测试、开发和调试。
