C# 的轻量级 RPC 框架

Redola.Rpc 的一个小目标

Redola.Rpc 的一个小目标

Redola.Rpc 的一个小目标：20000 tps。

   Concurrency level: 8 threads
   Complete requests: 20000
Time taken for tests: 0.886 seconds
    Time per request: 0.044 ms (avg)
 Requests per second: 22573 [#/sec] (avg)
   Concurrency level: 8 threads
   Complete requests: 10000
Time taken for tests: 0.424 seconds
    Time per request: 0.042 ms (mean)
 Requests per second: 23584 [#/sec] (avg)

测试环境使用 AWS 虚拟机 AWS EC2 C4 Instance Model c4.2xlarge，配置如下：

Processor: Intel(R) Xeon(R) CPU E5-2666 v3 @ 2.90GHz
     vCPU: 8
   Memory: 15 GiB
  Storage: 30G EBS-Only
Bandwidth: 1,000 Mbps
       OS: Windows Server 2012 R2

Redola.Rpc 是什么？

  • Redola.Rpc 是一个基于 C# 的轻量级 RPC 框架；
  • Redola.Rpc 是一个源代码托管在 GitHub 上的开源项目；
  • Redola.Rpc 是一个发布在 nuget.org 上的可安装软件包；

　　源代码开源地址：https://github.com/gaochundong/Redola

　　样例测试代码：https://github.com/gaochundong/Redola/tree/master/Tests

Redola.Rpc 的特点

  • 简单粗暴，一看就懂；
  • 简单的注册中心，消除配置障碍；
  • 支持 Request / Response 阻塞模型；
  • 支持任意服务间的消息推送；
  • 内置 protobuf 序列化，提供可替换接口；

Redola.Rpc 内部结构

Redola.Rpc 基于 Cowboy.Sockets 进行构建，使用 TCP Socket 进行服务间通信，默认使用 .NET APM TCP Socket 模式。通过 Actor 模型抽象封装 Socket 连接与交互，实现 Actor 之间的 Register、Lookup、Handshake、KeepAlive 等功能；

Redola.Rpc 概念模型

  • Actor Peer：代表一个 Actor 节点，任意 Actor 之间均可通信；
  • Actor Master：作为 Actor 节点注册中心，用于服务的注册与发现；
  • Actor Identity：一个 Actor 的身份描述，包括 Type、Name、Address、Port 等；
  • RPC Service：用于实现具体的 RPC 服务，一个 Actor 可以注册多个 RPC Service；

Redola.Rpc 通信模型

Actor Peer 与 Actor Peer 之间通过 TCP 长连接进行通信。Actor 封装了 TCP 中关于 TcpClient 和 TcpServer 的抽象，对外不再暴露 Client 和 Server 的概念，仅以 Peer 呈现，Peer 与 Peer 之间是平等的。Actor Master 与其他 Peer 的区别仅是承担了 Register 和 Lookup 的职责。

Actor Peer 间通过 Actor Master 查询到需要通信的对端 Actor Peer 的 Actor Identity，会首先进行 Handshake 交换 Actor Identity，用以记录对方的身份。Handshake 之后，即可进行预定义注册的 RPC 消息通信。

为掌握对端 Peer 的活跃情况，通过内置的 KeepAlive 机制进行服务间保活，每隔约定时间进行消息交互，若超时时间内未获得保活回复，则自动断开连接。KeepAlive 同时做了一定的优化，若服务间在保活时间内有任何 Send 或 Receive 消息操作，则视为有服务间通信，即对端为活跃状态，会延迟发送保活请求。

假设 Actor 1 (Tyep:hello, Name:hello-001, Address:192.168.1.139, Port:8888) 需要与 Actor 2 (Type:world, Name:world-001, Address:192.168.1.158, Port:7777) 进行通信，则仅需发送消息时指定 Actor 2 的身份 (world, world-001)，其中 world 为 Actor 2 的类型，world-001 为该 world 类型下名称为 world-001 的 Actor Peer。

Redola.Rpc 基本契约

  • 任意 Actor 均需向 Actor Master 注册，提供自身 Actor Identity 信息；
  • 仅指定 Actor Type 发送消息，则会随机 Lookup 一个该 Type 的 Actor 进行通信；
  • Actor 不区分 Client 和 Server 角色，角色由使用者设计；
  • RPC 调用接口有同步和异步之分，由使用者选择；
  • 支持 Request/Response 同步阻塞模式，可设置阻塞超时时间；
  • 消息注册后，通过反射匹配消息处理方法，On + MessageType 契约编程；
  • RPC 限流在消息处理侧实施，默认 RateLimiter 限制 CPU 相同数量线程；
  • 内部 TCP 配置 Buffer Pool 连续内存会伴随连接数和吞吐增加，单 Buffer 8K 大小；
  • 若 RPC 传递消息大于 84K，.NET 将 Buffer 分配到 LOH 上，GC 未必及时回收；

Redola.Rpc 的依赖库

有那么多 RPC 框架，为什么要自己写一个？

演进出来的，那就是一个故事了。

起初，我们作为一个初创公司，还在尝试思考清楚我们要做的东西究竟应该是什么样子，毕竟市场上少有同类竞品，那么首先设计一个原型是合理的。所以，我们只有一个应用程序，用于定时拉取第三方合作伙伴的 WebService 数据，并通过设计的算法进行计算处理，然后写入数据库；

有了数据，总要找地方展现吧，于是招聘了 Unity3D 前端开始做炫酷的 App，有实时数据推送的展现要求，所以前后端通信使用了 WebSocket 协议，也就产生了 Cowboy.WebSockets；

第三方合作伙伴的 WebService 显然不只一个接口，多个接口并发拉取，每 100 毫秒拉取一次，线程繁忙影响了计算处理和写入数据库；好，将数据拉取分离出去，并进行前期的数据清洗和过滤，然后再发给算法计算引擎；这时，就有了 2 个服务，一个负责拉取数据 Feed，一个负责计算入库 Engine，通过 Cowboy.Sockets 进行 TCP 消息通信；

终于有更多的数据可供展现了，当然 U3D App 也快开发完成了，App 不可能就装在一个手机上吧，万一发布到 AppStore 上火了呢？引入了接入层 Gateway 系列服务，用于保持 WebSocket 长连接和数据推送；好，现在有了 2 + n 个服务了，并且 n > 5 还做了软负载均衡；

算法引擎 Engine 计算完后，要将数据分发到这 n 个 Gateway 服务上，臣妾就这两颗 CPU，着实做不到啊！分发成了瓶颈，万一 n 成长到 50 怎么办？好，将数据推送委托给新服务 Bolt 服务，专门做推送给 Gateway；

引擎算法发现需要更多输入源数据参与计算，好吧，引入更多第三方数据 Feed 提供商，每家一个服务做拉取；艾玛~ 每家实际上是多个服务拉取~ 还有要求主动推送的 ~

哎呀，对于同一领域对象，每家的描述 ID 显然不一样，毕竟不是一个公司，手工匹配好烦，眼睛都快瞎了，做个 Mapping 自动服务根据特征专门负责匹配 ID，匹配好了再发给引擎，妈妈再也不用担心我的 ID；

数据简直不要太多，计算引擎 Engine 边计算边入库，常年 100% CPU 啊我的哥；拆！先将预处理数据入库，再将计算的结果入库；

什么？数据库写入有延迟？线程被阻塞，又跟我的 CPU 过不去！拆，引流写操作到 MQ 消息队列，加上 Durability 落地，爱阻塞谁阻塞谁，爱啥时候写啥时候写。

隔壁老王看了一眼我们的 U3D App，矮油不错哦，狂拽酷霸吊炸天啊！你们这数据算法和计算引擎有些超出我的知识范围，我有一些新的产品想法，要么你们帮我实现 H5，要么你们提供 API 我们自己实现 H5，反正我的想法必须实现，你看这是 20% 预付款你们下个星期能不能上线 API 啊？王哥，有钱还能有办不成的事儿？是吧，说，你都要啥推送接口？Socket + Protobuf 可以吧？HTTP 也行？

刚回国的尼古拉斯赵四听闻有 API 开放能力，那必须接入啊，共享经济实现共赢嘛，有钱大家一起赚，只是这 API 接口能不能修改成 RESTful + 反向 POST？

我相信，明天还会有新需求的！要善待今天的自己，底层封装成 Redola.Rpc 框架！

时间： 2024-10-04 05:48:44

C# 的轻量级 RPC 框架的相关文章

微博轻量级RPC框架Motan正式开源：支撑千亿调用

支撑微博千亿调用的轻量级 RPC 框架 Motan 正式开源了,项目地址为https://github.com/weibocom/motan. 微博轻量级RPC框架Motan正式开源 Motan 是微博技术团队研发的基于 Java 的轻量级 RPC 框架,已在微博内部大规模应用多年,每天稳定支撑微博上亿次的内部调用.Motan 基于微博的高并发和高负载场景优化,成为一套简单.易用.高可用的 RPC 服务框架. Motan 功能特点:简单.易用.高可用 无侵入集成.简单易用,通过 Spring 配

基于Netty和SpringBoot实现一个轻量级RPC框架-Client篇

前提 前置文章: <基于Netty和SpringBoot实现一个轻量级RPC框架-协议篇> <基于Netty和SpringBoot实现一个轻量级RPC框架-Server篇> 前一篇文章相对简略地介绍了RPC服务端的编写,而这篇博文最要介绍服务端(Client)的实现.RPC调用一般是面向契约编程的,而Client的核心功能就是:把契约接口方法的调用抽象为使用Netty向RPC服务端通过私有协议发送一个请求.这里最底层的实现依赖于动态代理,因此动态代理是动态实现接口的最简单方式(如果

.NET轻量级RPC框架：Rabbit.Rpc

最近准备写一个.NET的管理平台应用在公司,由于存在大量的Client => Server,Server => Client的请求需求在加上之前一直接触了解过RpcClient组件的开发,所以就造了个新轮子Rabbit.Rpc.这篇文章也用于介绍这个新组件. 什么是RPC? RPC全称为:Remote Procedure Call Protocol,远程过程调用协议. 用.NET的技术可以理解为:Remoting.WCF.主要目的就是:实现服务的远程调用.远程执行,当然既然有协议那么其它语言(

【转】轻量级分布式 RPC 框架

第一步:编写服务接口 第二步:编写服务接口的实现类 第三步:配置服务端 第四步:启动服务器并发布服务 第五步:实现服务注册 第六步:实现 RPC 服务器 第七步:配置客户端 第八步:实现服务发现 第九步:实现 RPC 代理 第十步:发送 RPC 请求 总结 附录:Maven 依赖 RPC,即 Remote Procedure Call(远程过程调用),说得通俗一点就是:调用远程计算机上的服务,就像调用本地服务一样. RPC 可基于 HTTP 或 TCP 协议,Web Service 就是基于 H

轻量级分布式 RPC 框架

原文出处: 黄勇 RPC,即 Remote Procedure Call(远程过程调用),说得通俗一点就是:调用远程计算机上的服务,就像调用本地服务一样. RPC 可基于 HTTP 或 TCP 协议,Web Service 就是基于 HTTP 协议的 RPC,它具有良好的跨平台性,但其性能却不如基于 TCP 协议的 RPC.会两方面会直接影响 RPC 的性能,一是传输方式,二是序列化. 众所周知,TCP 是传输层协议,HTTP 是应用层协议,而传输层较应用层更加底层,在数据传输方面,越底层越快,

轻量级分布式 RPC 框架(转)

RPC,即 Remote Procedure Call(远程过程调用),说得通俗一点就是:调用远程计算机上的服务,就像调用本地服务一样. RPC 可基于 HTTP 或 TCP 协议,Web Service 就是基于 HTTP 协议的 RPC,它具有良好的跨平台性,但其性能却不如基于 TCP 协议的 RPC.会两方面会直接影响 RPC 的性能,一是传输方式,二是序列化. 众所周知,TCP 是传输层协议,HTTP 是应用层协议,而传输层较应用层更加底层,在数据传输方面,越底层越快,因此,在一般情况下

拥抱.NET Core，跨平台的轻量级RPC：Rabbit.Rpc

不久前发布了一篇博文".NET轻量级RPC框架:Rabbit.Rpc",当初只实现了非常简单的功能,也罗列了之后的计划,经过几天的不断努力又为Rabbit.Rpc增加了一大波新特性,今天主要介绍下项目近况. 特性一览 Apache License 2.0协议开源 支持客户端负载均衡(提供了轮询.随机算法的实现) 支持ZooKeeper和文件共享形式的服务协调 运行时客户端代理生成(基于Roslyn) 预生成客户端代理 客户端代理预生成(基于Roslyn) 抽象的编解码器(提供了JSON

一个轻量级分布式RPC框架--NettyRpc

1.背景 最近在搜索Netty和Zookeeper方面的文章时,看到了这篇文章<轻量级分布式 RPC 框架>,作者用Zookeeper.Netty和Spring写了一个轻量级的分布式RPC框架.花了一些时间看了下他的代码,写的干净简单,写的RPC框架可以算是一个简易版的dubbo.这个RPC框架虽小,但是麻雀虽小,五脏俱全,有兴趣的可以学习一下. 项目地址:https://github.com/luxiaoxun/NettyRpc 自己花了点时间整理了下代码,并修改一些问题,以下是自己学习的一

轻量级高性能 RPC 框架 HRPC

HRPC HRPC是一款基于Netty和Zookeeper设计的轻量级高性能RPC框架. 特性 采用Protostuff序列化:高性能,负载均衡:支持服务的注册和订阅:支持同步及异步2种调用方式:长连接,自动重连:采用cglib动态代理:代码简答,易上手:支持Spring: 更多轻量级高性能 RPC 框架 HRPC介绍