聊聊RPC之Provider

最新推荐文章于 2024-04-16 11:48:18 发布
最新推荐文章于 2024-04-16 11:48:18 发布
阅读量1.4k 收藏 15
点赞数 3
分类专栏： Java 微服务 web开发 文章标签： 中间件 分布式 通信
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/WANGYAN9110/article/details/69669367
版权

RPC的全称是Remote Procedure Call，它是一个分布式系统必备的一个中间件，主要解决系统之间通信的问题。

一般来说一个RPC中间件的由以下组成：

rpc

  • Provider：服务提供者，提供服务给消费者调用
  • Consumer：服务消费者，提供可以像调用本地方法一样的方式，调用远程的服务
  • Register：注册中心，为提供者、消费者提供服务地址的注册服务，当提供者不可用时即时通知调用者
  • Protocal: 通信协议，定义服务提供者和服务调用者之间的契约
  • Governance: 服务治理，为服务治理提供支持，包括限流规则、黑白名单等
  • Heartbeat: 心跳，检测服务是否可用，服务不可用即时在本地服务地址列表里清除

以上是一个的RPC中间件的组成以及各部分的职责，那么他们各个部分具体有哪些特性呢？对于使用者来说，平常的使用过程中需要哪些注意的问题呢？（接下来示例全部以Dubbo为例）

我们今天先来看看Provider，Provider对于使用者来说，都很熟悉，我们经常开发一些服务提供者给别人调用。

Provider的注册过程

在开发中开发一个Provider一般需要如下工作：

  1. 定义一个服务接口

    public interface HelloService{
  String say(String name);
}

  2. 实现定义的接口

    public class HelloServiceImpl implements{
 @Override
 public String say(String name){
    return "Hello,"+name;  
 }
}

  3. 注册服务

    <dubbo:registry address="zookeeper://192.168.0.122:2181" />

<dubbo:protocol name="dubbo" port="20880" />

<dubbo:service interface="info.yywang.service.HelloService" ref="helloService" />

<bean id="helloService" class="info.yywang.service.impl.HelloServiceImpl" />

通过以上三步的开发，我们就完成了一个HelloService服务的开发，那么在这三步的背后RPC框架帮我们做了什么呢？

  1. 在启动时，首先加载Spring配置，然后进行解析，再创建bean，注册到Spring的上下文中，这个过程是Spring的bean的加载过程的范畴，不在细说
  2. 其中在解析阶段，在spring的配置中，dubbo的标签是dubbo实现的对spring的命名空间的一个扩展。当遇到dubbo标签的配置会由DubboNamespaceHandler的定义来解析相应的节点，解析完成后注册到spring的上下文
  3. 在注册完成后，会调用ServiceConfig的export执行方法暴露，在执行export方法时，首先进行一些配置检查，和默认值设置，中间很多判断，不在详细说，直接说下面的重点
  4. 在执行export方式时，首先根据host、port等创建服务url，然后根据url的协议和配置，做一些设置，最后由ProxyFactory把URL转换成可以Invoker，然后通过Protocol.export把服务暴露出去
  5. Protocol.export根据协议获取RegistryProtocol，在以上配置中，我们使用dubbo协议。
  6. 然后调用RegistryProtocol的export执行注册
  7. 首先根据设置的注册中心地址，解析出注册中心地址，比如以上就是使用的就是zookeeper作为注册中心，服务地址是192.168.0.122。获取到Register对象。
  8. 在zookeeper的注册中，实际就是调用zkClient创建一个URL路径节点，并且添加一个注册器，订阅url节点发生变化时通知，并提交给Listener处理
  9. 至此一个服务的暴露就完成了

以上是整个服务暴露的过程，对于使用者来说，以上过程需要了解，但是对于一个使用者来说，更重要的是如何设计一个让调用者用起来爽的接口。当然如何设计一个让调用者使用起来爽的接口，是另一个话题。我们另一篇文章再讲，读者也可以思考这个问题。

Provider的开发

在开发过程中，作为Provider的接口开发者需要注意哪些问题呢？可以从以下几个方面进行探讨

  1. 扩展性

    对于一个服务接口来说，只要在线上使用过的接口，都要保证历史的接口可用。扩展性不好的接口，在每次新增需求都要修改接口或者直接新增接口。为保持接口的扩展性，在设计时需要注意一下问题

    • 保证接口职责单一，一个接口只干一件事。基于业务的本质去抽象接口，一个接口逻辑越重，面对新的需求时，越是力不从心，当接口职责足够单一时，面对新的需求可以更加灵活的去组合，实现新的业务
    • 为接口保留扩展字段，在对于一些需求时，可能字段经常增加。这时可以考虑为接口增加扩展字段，但是这时需要注意扩展字段滥用的风险，需要对于扩展字段的名称以及用途做好管控，比如可以在一个常量类里定义好可以使用的扩展字段，并注意维护

  2. 易用性

    接口的易用性可以从命名、参数、注释、设计等多个方面去考虑。在设计一个易用性的接口可以从如下方面考虑

    • 相同的操作约定的统一的命名。比如同样是查询操作，都使用query开头或者get开头，不要有的用query有的用get
    • 相同的业务含义使用统一的单词。比如相同的业务不要使用两个意义接近的单词
    • 尽量使用简单的参数类型，简单的参数类型可以减少调用者的使用成本
    • 对于复杂的参数类型，提供常用create方法，对于复杂的参数类型有些参数必填有些选填，可以提供最常用的几种create方法，方便调用者快速创建
    • 注意参数的顺序，对于不同的参数比如一个接口的顺序是getUser(int classId,int schooIId);另一个接口get(int schoolId,int classId);这种情况，调用者就非常容易使用错误
    • 对于从方法名看不出来的逻辑，需要在注释中写明
    • 对于可选参数标明，并且注明用途以及对于接口逻辑有什么影响
    • 从调用者的角度考虑，提供相应的工具方法，方便调用者使用，比如返回值，封装是否成功，调用者使用时只需要知道isSuccess就可以知道是否成功，不需要知道你是使用SUCCESS作为code还是直接用的布尔类型

  3. 兼容性

    一旦服务发布之后，以后任何的变更都需要考虑兼容性，需要从以下几个方面考虑兼容性

    • 在业务发展时，如果新老业务重合度不是非常高，尽量使用新增接口的方式
    • 接口的兼容性，在修改时通过增加参数来实现新业务，不能减少参数以及修改参数的类型
    • 在接口重构时，需要实现原有的业务逻辑，并保证输出的一致性，来保证接口的兼容性
    • 新老接口替换时，采用相同风格的命名、参数列表、使用方法等等，让接口之间自然替换

  4. 异常处理

    异常处理是否完善是评判一个接口健壮性的标准，异常从分类上来讲，有系统异常和业务异常。

    • 对于系统异常来说，一般来说是网络中断、调用超时、服务挂掉等等，这些异常在rpc框架层面做了一些处理，比如RPC的心跳机制来检测服务是否可用等，对于系统异常作为服务提供方不可避免，在服务的调用方需要考虑这个问题。
    • 对于业务异常，作为Provider的开发需要特别关注，一般业务的异常处理方式有两种，一种是把继承自RunningTimeException异常直接抛出，另一种是使用错误码的方式来报出异常。
    • 使用异常直接抛出，不同的业务异常对应不同的Exception，在调用者需要通过异常类型来区分不同的异常，在出现异常可以通过异常栈迅速定位到代码的位置，但是如果异常栈比较深，占用内存较大，在出现大量错误时，对系统的影响比较大
    • 使用错误码的方式，需要定义一套错误码标准，外部在调用时，需要对错误码做一定判断。错误码对异常做了包装，不利于错误定位，发生异常时抛出需要依赖Provider端打印的日志。一般业务性异常，使用错误码的方式
    • 在Provider实现层，对于异常一定要记录日志，方便问题排查和监控，如何做好异常日志打印也是个值得思考的话题，我自己也在思考这个问题，也欢迎大家一起来讨论这个话题

  5. 性能

    对于Provider的开发来说，性能也是一个很重要的话题，不同的接口对于性能的要求不一样。要达到不同的性能要求实现的成本也不一样。所以接口的性能指标，需要根据不同的业务场景结合实现成本来制定，对于接口性能一般可以从响应时间、并发数、吞吐量方面来衡量。一般考虑提高接口性能的方法有以下几种

    • 使用缓存，包括分布式缓存和JVM缓存，对于查询接口来说，使用缓存是提高响应时间的捷径，但是使用缓存的同时，需要考虑数据的一致性是否需要强一致。
    • 对于一个业务操作很多的接口，还可以考虑使用异步来提高接口的响应时间，对业务操作进行分类，区分哪些是可以异步完成的，交给消息中间件或者异步中间件来完成
    • 另外对于高并发的系统，需要支持集群部署，采用集群的方式支持高并发的请求
    • 回归根本，优化代码。比如尽量避免访问数据库的次数、缓存中间结果、并行处理、优化算法等等
    • 一般的业务操作的性能问题，多出在数据库操作上，所以优化数据存储也是解决性能问题的重要方式

欢迎关注我的公众号MyArtNote

MyArtNote

SpringCloud Alibaba 实战之《RPC 消息：Dubbo 与 Nacos 体系如何协同作业》
小米吃辣椒的博客
05-27 207
上一节我介绍了什么是 OpenFeign 通信组件，讲解了如何基于 OpenFeign 实现微服务间的高可用通信。本文我们将继续探讨微服务通信话题，了解阿里巴巴自家的 RPC 框架 Dubbo 是如何与 Spring Cloud Alibaba 协同作业的。在本文我们将介绍以下三方面内容： 对比 RESTful 与 RPC； 介绍 Dubbo 的特点； 讲解 Dubbo 与 Spring Cloud Alibaba 的整合过程。 RESTful 与 RPC 的区别 在微服务定义中提道，每个小服务运行
透彻解析 RPC 原理
id_8180的博客
03-04 614
本文主要论述的是“RPC 实现原理”，那么首先明确一个问题什么是 RPC 呢？RPC 是 Remote Procedure Call 的缩写，即，远程过程调用。RPC 是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而开发人员无需额外地为这个交互编程。 值得注意是，两个或多个应用程序都分布在不同的服务器上，它们之间的调用都像是本地方法调用一样。接下来我们便来分析一下一次 RPC 调用发生了些什么？ 一次基本的 RPC 调用会涉及到什么？ 现在业界内比较流行的一些..
RpcProvider类（负责发布RPC Service）
TABE_的博客
10-05 682
RpcProvider类mprpcprovider.hmprpcprovider.cc RpcProvider类是框架提供的专门发布rpc服务的网络对象类。 mprpcprovider.h #pragma once #include "google/protobuf/service.h" #include <functional> #include <google/protobuf/descriptor.h> #include <muduo/net/EventLoop.h&g
手写RPC(八) provider、consumer 实现
hxj413977035的博客
12-08 1693
首先，我们的provider是需要提供rpc服务的，而我们 rpc底层是需要依赖netty的，因此我们需要依赖我们已经编写好的rpc-protocol模块。 rpc-provider模块 pom.xml文件添加 <dependency> <groupId>com.info</groupId> <artifactId>rpc-protocol</artifactId> <version>1.0-
从零开始我的rpc第三篇之通信层Provider端
dressrosa
06-27 751
上一篇讲了consumer端,这次说下provider端.不过老是在client/consumer,server/provider名词间胡乱转换,挺烦的.个人觉得站在通信层更适合讲client/server,不过站在整个rpc上来讲,还是consumer/provider比较合适.好了,回到这个provider端来. 首先我们梳理下server主要的功能有哪些. 当然server肯定是用来接受...
eosjs v20 如何通过jsonrpc连接到主网节点
mongo_node的专栏
12-21 608
用eosjs连接主网节点很简单，只需要在创建JsonRpc对象时，指定要连接主网节点的地址 就可以了。 例如，下面的代码将创建一个使用eosnewyork.io节点RPC旳JsonRpc 对象，然后使用get_info()方法获取网络总体信息： const { JsonRpc } = require('eosjs') const fetch = require('node-fetch') con...
框架扩展：注解 RPC Consumer属性动态注入
公众号：微观技术
03-13 2018
分布式系统架构时代，RPC框架你一定不会陌生。目前主流的RPC框架有 dubbo、thrift、motan、grpc等。 消费端（RPC Consumer）通常只有服务接口定义，接口的业务逻辑实现部署在生产端（RPC Provider），服务调用一般是采用动态代理方式，通过Proxy创建一个代理类，借助增强方式完成网络的远程调用，获取执行结果。 这里有两个关键点： 1、如何实现一个通用的代理类？ 2、如何在消费端动态注入接口的代理对象？ 如何实现一个通用的代理类？ 目前动态代理的实现方案有很多种
100 行代码摆平了 RPC 原理，面试官随便问
zhaohuodian的博客
08-31 133
本文简单介绍了 RPC 的整个流程，并实现了一个简单的 RPC 调用。希望阅读完本文之后，能加深你对 RPC 的一些认识。加载服务接口，并缓存服务注册，将服务接口以及服务主机信息写入注册中心（本例使用的是 zookeeper)启动网络服务器并监听反射，本地调用代理服务接口生成代理对象服务发现（连接 zookeeper，拿到服务地址列表，通过客户端负载策略获取合适的服务地址）-远程方法调用（本例通过 Netty，发送消息，并获取响应结果）......
聊聊Dubbo3.0新特性之应用级服务发现
hosaos的博客
02-11 2457
文章目录什么是服务发现信息孤岛问题Http通信微服务与Rpc框架Dubbo2.0中的接口级服务发现应用级服务发现兼容性设计Rpc元数据同步机制性能表现参考资料 什么是服务发现 信息孤岛问题 计算机诞生之初，往往信息系统都是以单机的形式存在，系统与系统交互较少，存在信息孤岛问题，数据的交换得通过硬件设备的拷贝、人工在不同系统之间进行拷贝(硬盘、U盘等)。随着互联网的兴起，任何一个系统都难以在互联网浪潮中“独善其身”，不同服务、系统之间往往存在信息互通的需求，比如浏览淘宝网是用户的电脑请求淘宝网的服务器获得相关
Provider处理请求逻辑梳理
weixin_34004750的博客
09-25 194
2019独角兽企业重金招聘Python工程师标准>>> ...
分布式网络通信框架（七）——RpcProvider发布服务方法
qq_42120843的博客
05-28 570
利用muduo库的来实现数据的收发，利用protobuf来实现数据的序列化（发送前）和反序列化（接收后）发布服务主要在实现，重点在于生成一张表，记录服务对象和其发布的所有服务方法// 保存服务对象的地址 std :: unordered_map < std :: string , const google :: protobuf :: MethodDescriptor * > m_methodMap;// 保存服务方法映射<方法名, 方法描述符指针> };
聊聊RPC之Provider_publicprovider,w3mprovider,jsonrpcprovider 怎么理解
2401_84301832的博客
04-16 422
对于一个服务接口来说，只要在线上使用过的接口，都要保证历史的接口可用。以上是一个的RPC中间件的组成以及各部分的职责，那么他们各个部分具体有哪些特性呢？通过以上三步的开发，我们就完成了一个HelloService服务的开发，那么在这三步的背后RPC框架帮我们做了什么呢？我们今天先来看看Provider，Provider对于使用者来说，都很熟悉，我们经常开发一些服务提供者给别人调用。以上是整个服务暴露的过程，对于使用者来说，以上过程需要了解，但是对于一个使用者来说，更重要的是。可以从以下几个方面进行探讨。
RpcProvider的网络服务，以及怎么发布服务方法
Sauron7i的博客
09-05 317
那目前实现的功能除了初始化rpc框架和加载配置文件，还设计一个类RpcProvider，实现了框架的网络模块，RpcProvider还需要有提供服务方法：NotifyService()本地的方法会从中得到请求的参数，执行本地服务，然后把响应response填写好，执行回调操作返回。那么问题就是，当接收到一个rpc调用请求时，如何知道要调用哪个应用程序的哪个rpc方法呢？首先的思路是，我们需要一个表，来记录当前节点的服务对象和服务方法信息。如果有请求从网络上发送过来。
微信小程序授权功能
anjignren的博客
07-20 1480
思路： 1.首先获取授权，看看到底有没有这个授权，如果有，那么就不再进行再次请求，如果没有，那么再次请求或者其他的业务逻辑。 2.查看授权信息接口：wx.getSetting(Object object),后面我们具体分析这个接口如何使用 3.通过来调取授权 <button open-type='getUserInfo' bindgetuserinfo="getUserInfo"></button> 业务代码： 获取用户授权信息 // 获取微信授权信息 // getShouq
uniapp写APP时调用微信登录
TYD0313的博客
10-22 1471
uniapp调用微信授权登录
uniapp微信登陆
weixin_52335582的博客
08-20 387
uniapp如何微信登陆
RpcProvider（rpc服务提供者）实现思路
godaa的博客
07-28 1051
RpcProvider（rpc服务提供者）实现思路
手写rpc远程过程调用框架
xiaoyou137的博客
02-26 596
这是一个模仿grpc,基于TCP协议和protobuf编解码的RPC框架，支持多种数据类型的序列化和反序列化，使用muduo网络库实现高并发处理,使用zookeeper作为服务配置中心。同时，采用了函数特征的模板类和protobuf框架自动生成代码等技术，使得代码实现简洁高效。
详细聊聊Model-Driven SAL (MD-SAL) 开发
最新发布
03-18
<think>好的，我现在需要回答用户关于Model-Driven SAL (MD-SAL) 开发细节的问题，包括架构设计、实现方式和应用场景。首先，我需要回忆一下MD-SAL的基本概念和相关知识。根据用户提供的引用内容，尤其是引用[1]提到的yang模型和数据结构定义，以及引用[2]中关于SAL的基础服务和REST API的调用，还有引用[3]中的RPC服务代码示例，这些都可能与MD-SAL相关。 首先，MD-SAL是OpenDaylight项目的核心组件，采用模型驱动的架构，通过YANG模型定义数据结构和接口，实现南北向的解耦。架构设计方面，MD-SAL分为数据存储层、服务抽象层和消费者层。数据存储层可能包括operational和config两种数据存储，如引用[1]中提到的。服务抽象层提供基础服务，如RPC和通知，消费者层则是应用通过REST API或插件调用这些服务，如引用[2]所述。 实现方式方面，YANG模型是关键，需要定义数据结构、RPC接口和通知。然后生成Java代码，使用提供的API进行服务注册和调用，如引用[3]中的代码示例。应用场景可能包括网络自动化、服务链编排和跨域协作，这些都是SDN控制器常见的应用。 接下来需要确保回答结构清晰，分点说明架构、实现和应用。同时注意用户提到的LaTeX格式要求，行内公式用$...$，独立公式用$$...$$。虽然当前问题可能不涉及数学公式，但如果有的话需要正确应用。另外，生成的相关问题要符合用户需求，可能涉及开发流程、YANG模型作用、性能优化等。 需要检查引用是否正确，引用[1]提到YANG模型和数据结构，引用[2]关于SAL的基础服务和REST API，引用[3]的RPC服务调用，这些都应在回答中适当引用。例如，在架构设计的数据存储层部分引用[1]，在实现方式部分引用[2]和[3]。 最后，确保使用中文，避免Markdown格式，代码块用正确格式包裹，并生成相关问题。现在组织这些内容，确保符合用户的所有要求。</think>### Model-Driven Service Abstraction Layer (MD-SAL) 开发详解 #### 一、架构设计 MD-SAL是OpenDaylight（ODL）控制器的核心组件，采用**模型驱动架构**，通过YANG模型定义数据结构与接口，实现南向设备与北向应用解耦[^1]。其架构分为三层： 1. **数据存储层** 包含`operational data store`（运行时状态数据）和`config data store`（配置数据），通过YANG模型定义存储结构。例如： ```yang container network-topology { list topology { key "topology-id"; leaf topology-id { type string; } } } ``` 引用[1]中提到的`list & key`语法即用于定义此类数据结构。 2. **服务抽象层** 提供统一API，包括： - **RPC服务**：如设备配置下发 - **通知服务**：如网络状态变更事件 - **数据树服务**：读写`operational/config`数据 3. **消费者层** 北向应用通过REST API或插件调用MD-SAL服务，如引用[2]提到的可视化界面开发。 #### 二、实现方式 1. **YANG模型定义** - 定义数据结构（如容器、列表、叶子节点） - 声明RPC接口与通知事件 - 示例：定义一个RPC接口 ```yang rpc update-config { input { leaf device-id { type string; } leaf config-data { type binary; } } output { leaf result { type boolean; } } } ``` 2. **代码生成与绑定** 使用`maven-sal-plugin`将YANG模型编译为Java接口，自动生成： - **Data Object**：数据存储实体 - **RPC Consumer/Provider**：服务调用与实现类 - **Notification Listener**：事件监听器 3. **服务注册与调用** - **Provider端**：实现生成的服务接口并注册 ```java public class ConfigServiceImpl implements ConfigService { @Override public Future<RpcResult<UpdateConfigOutput>> updateConfig(UpdateConfigInput input) { // 实现配置下发逻辑 } } ``` - **Consumer端**：通过`RpcConsumerRegistry`获取服务代理 ```java ConfigService service = rpcConsumerRegistry.getRpcService(ConfigService.class); service.updateConfig(input); ``` 如引用[3]中的`HiService`调用模式。 #### 三、应用场景 1. **网络自动化配置** 通过YANG模型定义设备配置模板，结合RPC实现批量下发。 2. **服务链编排** 利用数据树服务监听网络状态，动态调整流量路径。例如： $$ \text{流量路径} = \arg\min_{p \in Paths} \sum_{link \in p} \text{负载}(link) $$ 3. **跨域协作** 通过MD-SAL将多厂商设备抽象为统一模型，支持混合SDN环境管理[^2]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值