turbo-rpc 是一款速度超凡的异步响应式RPC框架。
功能特点
仅支持异步调用，Service接口所有public方法返回值都必须为CompletableFuture。
配置定义在Service接口上，而非实现类上，方法实现者和调用者都不需要引入奇奇怪怪的注解。
支持REST调用。
支持失败回退, 支持熔断, 支持心跳, 支持自动重连。
支持自定义 服务注册 负载均衡 序列化。
支持Filter, 可通过该机制实现 Tracing 限流限速 黑白名单 等功能。
支持spring boot。
Quick Start
1.定义接口
@TurboService(version = "1.0.0")
public interface HelloService {
@TurboService(version = "1.0.0", rest = "hello")
default CompletableFuture<String> hello(String msg) {
// default实现会自动注册为失败回退方法，当远程调用失败时执行
return CompletableFuture.completedFuture("error");
}
}
2.服务端实现接口
@Component
public class HelloServiceImpl implements HelloService {
@Override
public CompletableFuture<String> hello(String msg) {
return CompletableFuture.completedFuture(msg);
}
}
3.配置turbo-server.conf, 声明 服务器地址 序列化协议 注册地址 等信息
4.服务端启动
@SpringBootApplication(scanBasePackages = { "com.hello" })
@EnableTurboServer
public class TruboServerBootTest {
public static void main(String[] args) {
SpringApplication.run(TruboServerBootTest.class, args);
}
}
5.客户端调用
@Component
public class HelloReferTest {
@Autowired
HelloService helloService;
public void doSomeThing(String msg) {
helloService.hello(msg)
.thenAccept(message -> System.out.println(message));
}
}
6.配置turbo-client.conf, 声明 服务器地址 序列化协议 注册地址 等信息
7.客户端启动
@SpringBootApplication(scanBasePackages = { "com.hello" })
@EnableTurboClient
public class HelloBootTest {
public static void main(String[] args) {
SpringApplication.run(HelloBootTest.class, args);
}
}-
周一 一大早，ServiceComb社区惊奇地发现，由独立个人鲁小憨主导的RPC Benchmark测试中，增加了Apache ServiceComb、armeria-http、springboot-undertow的性能比拼测试。 Apache ServiceComb 在没有进行任何优化的情况下，在该第三方主持的Benchmark测试中稳居第一梯队，ServiceComb社区小编不得不紧急欣喜转
-
测试说明 仅限于 Java 客户端使用 JMH 进行压测, 32 线程, 3 轮预热 3 轮测试, 每轮 10s 每次运行前都会执行 killall java, 但没有在每轮测试时重启操作系统 所有类库版本在发布时都是最新的, 除非存在 bug 所有框架都尽量参考该项目自带的 Benchmark 实现 将会一直持续, 不定期发布测试结果 测试用例 boolean existUser(String
-
完全基于docker部署一个php通过rpc访问golang的环境。 基本架构 我们用PHP的Laravel框架来实现一个用户登录的Restful Api，地址为： POST /user/login 返回信息为用户Id以及JWT token。 Golang用来实现两个服务，一个是用户信息服务，一个是登录的统计服务，PHP通过gRPC与Golang通讯。 最终部署完成后，共有4个docker的co
-
我们通常看到每个RPC框架介绍时都宣称“高性能”，到底哪个框架性能更好，很难得到明确答案。因为不同框架一般都有特别适合自己的测试场景，在特定场景下性能表现突出，其实说明不了问题。 为了相对准确评估不同框架性能，有网友做了一个性能基准测试，测试结果表明ServiceComb比大多主流服务框架有明显性能优势。 测试说明 仅限于 Java 客户端使用 JMH 进行压测, 32 线程, 3 轮预热 3 轮
-
本文转载自 RPC Benchmark 作者 鲁小憨 的简书博文 https://www.jianshu.com/p/caf51f5cfbaa 测试说明 仅限于 Java 客户端使用 JMH 进行压测, 32 线程, 3 轮预热 3 轮测试, 每轮 10s 每次运行前都会执行 killall java, 但没有在每轮测试时重启操作系统 所有类库版本在发布时都是最新的, 除非存在 bug 所有框架
-
测试说明 仅限于 Java 客户端使用 JMH 进行压测, 32 线程, 3 轮预热 3 轮测试, 每轮 10s 每次运行前都会执行 killall java, 但没有在每轮测试时重启操作系统 所有类库版本在发布时都是最新的, 除非存在 bug 所有框架都尽量参考该项目自带的 Benchmark 实现 将会一直持续, 不定期发布测试结果 测试用例 boolean existUser(String
-
测试说明 仅限于 Java 客户端使用 JMH 进行压测, 32 线程, 3 轮预热 3 轮测试, 每轮 10s 每次运行前都会执行 killall java, 但没有在每轮测试时重启操作系统 所有类库版本在发布时都是最新的, 除非存在 bug 所有框架都尽量参考该项目自带的 Benchmark 实现 将会一直持续, 不定期发布测试结果 测试用例 boolean existUser(String
-
在 RPC Benchmark Round 1 中，Turbo 性能炸裂表现强悍，并且在 listUser 这一项目中，取得了 10x dubbo 性能的好成绩。本文将介绍 Turbo 强悍性能背后的原理，并探讨如何编写高性能的 RPC 框架。 过早的优化是万恶之源？ 这句话是 The Art of Computer Programming 作者，图领奖得主 Donald Knuth 大神说的。不
-
测试说明 仅限于 Java 客户端使用 JMH 进行压测, 32 线程, 3 轮预热 3 轮测试, 每轮 10s 每次运行前都会执行 killall java, 但没有在每轮测试时重启操作系统 所有类库版本在发布时都是最新的, 除非存在 bug 所有框架都尽量参考该项目自带的 Benchmark 实现 将会一直持续, 不定期发布测试结果 测试用例 boolean existUser(String
-
rpc-benchmark 说明及答疑 几乎所有的 RPC 框架都宣称自己是“高性能”的, 那么实际结果到底如何呢, 让我们来做一个性能测试吧. 项目地址: https://github.com/hank-whu/rpc-benchmark https://gitee.com/hank-whu/rpc-benchmark 测试说明 仅限于Java. 客户端使用JMH进行压测, 32 线程,
-
同步调用的缺点 我们假设一个电子商城用户购买商品的场景: 创建订单前的验证方法。 /** * 验证订单是否合法 * * @param userId 用户id * @param itemId 商品id * @param discount 折扣 * @return */ public boolean verifyOrder(long userId, long itemId, doubl
-
在 RPC Benchmark Round 1 中 turbo 的成绩一骑绝尘，实力碾压众 rpc 框架。对此，很多人表示不服气，认为作者既是运动员又是裁判员有失公平。所以我认为有必要解释一下 rpc-benchmark 的公正性，以及为什么 turbo 能够如此强悍。 参考对象 rpc-benchmark 灵感源自 techempower-benchmarks，为了能够评测众多服务器框架，tec
-
Turbo 是一个很“轻”的微服务工具，把你的grpc|thrift接口变成HTTP接口！ 主要功能 Turbo能生成一个反向代理服务器，把HTTP请求转换为 grpc 或者 Thrift 格式的请求。 (换句话说，你现在有一个grpc|thrift的service？Turbo能把你的grpc|thrift接口变成HTTP接口！) 支持 gRPC 和 Thrift 。 支持 RESTFUL JSO
-
一种流式RPC的实现，RPC基于命令式调用，对于大量数据的传输没有流式调用来得高效！ 该SRPC既支持单通道也支持双通道。 单通道：客户端传入参数，服务端返回大量数据。 双通道：客户端传入大量数据，服务端返回大量数据。 该组件受Hadoop IPC启发而创建，参考Hadoop序列化机制，简单高效。 声明：OSCHINA 博客文章版权属于作者，受法律保护。未经作者同意不得转载。 注意：下载时需要SVN客户端！
-
Flex提供RPC服务以向客户端提供服务器端数据。 Flex为服务器端数据提供了相当大的控制。 使用Flex RPC服务，我们可以定义要在服务器端执行的用户操作。 Flex RPC Sservices可以与任何服务器端技术集成。 其中一个Flex RPC服务提供内置支持，可以通过线路传输压缩二进制数据，速度非常快。 Flex提供以下三种类型的RPC服务 S.No RPC服务和描述 1 HttpSe
-
基于GWT的应用程序通常由客户端模块和服务器端模块组成。 客户端代码在浏览器中运行，服务器端代码在Web服务器中运行。 客户端代码必须在网络上发出HTTP请求才能访问服务器端数据。 RPC，远程过程调用是GWT使用的机制，其中客户端代码可以直接执行服务器端方法。 GWT RPC是基于servlet的。 GWT RPC是异步的，客户端在通信期间从不被阻止。 使用GWT RPC Java对象可以直接在
-
主要内容：1.RPC流水线工程,2.RPC 技术选型,3.如何设计 RPC1.RPC流水线工程 ① Client以本地调用的方式调用服务 ② Client Stub接收到调用后，把服务调用相关信息组装成需要网络传输的消息体，并找到服务地址（host:port），对消息进行编码后交给Connector进行发送 ③ Connector通过网络通道发送消息给Acceptor ④ Acceptor接收到消息后交给Server Stub ⑤ Server Stub对消息进行解码，
-
RPC文档托管在这里： https://tendermint.com/rpc/ 若要更新文档，可以在 rpc/core 目录 编辑相关的 godoc 注释。