cloudwego / volo

Rust RPC framework with high-performance and strong-extensibility for building micro-services.

English | 中文

Volo is a high-performance and strong-extensibility Rust RPC framework that helps developers build microservices.

Volo uses Motore as its middleware abstraction, which is powered by AFIT and RPITIT.

Overview

Crates

Volo mainly consists of six crates:

1. The volo crate, which contains the common components of the framework.
2. The volo-thrift crate, which provides the Thrift RPC implementation.
3. The volo-grpc crate, which provides the gRPC implementation.
4. The volo-http crate, which provides the HTTP implementation.
5. The volo-build crate, which generates thrift and protobuf code.
6. The volo-cli crate, which provides the CLI interface to bootstrap a new project and manages the idl files.
7. The volo-macros crate, which provides the macros for the framework.

Features

Powered by AFIT and RPITIT

Volo uses Motore as its middleware abstraction, which is powered by AFIT and RPITIT.

Through RPITIT, we can avoid many unnecessary Box memory allocations, improve ease of use, and provide users with a more friendly programming interface and a more ergonomic programming paradigm.

High Performance

Rust is known for its high performance and safety. We always take high performance as our goal in the design and implementation process, reduce the overhead of each place as much as possible, and improve the performance of each implementation.

First of all, it is very unfair to compare the performance with the Go framework, so we will not focus on comparing the performance of Volo and Kitex, and the data we give can only be used as a reference, I hope everyone can view it objectively; at the same time, due to the open source community has not found another mature Rust async version Thrift RPC framework, and performance comparison is always easy to lead to war, so we hope to weaken the comparison of performance data as much as possible, and we'll only publish our own QPS data.

Under the same test conditions as Kitex (limited to 4C), the Volo QPS is 350k; at the same time, we are internally verifying the version based on Monoio (CloudWeGo's open source Rust async runtime), and the QPS can reach 440k.

From the flame graph of our online business, thanks to Rust's static distribution and excellent compilation optimization, the overhead of the framework part is basically negligible (excluding syscall overhead).

Easy to Use

Rust is known for being hard to learn and hard to use, and we want to make it as easy as possible for users to use the Volo framework and write microservices in the Rust language, providing the most ergonomic and intuitive coding experience possible. Therefore, we make ease of use one of our most important goals.

For example, we provide the volo command line tool for bootstraping projects and managing idl files; at the same time, we split thrift and gRPC into two independent(but share some components) frameworks to provide programming paradigms that best conform to different protocol semantics and interface.

We also provide the #[service] macro (which can be understood as the async_trait that does not require Box) to enable users to write service middleware using async rust without psychological burden.

Strong Extensibility

Benefiting from Rust's powerful expression and abstraction capabilities, through the flexible middleware Service abstraction, developers can process RPC meta-information, requests and responses in a very unified form.

For example, service governance functions such as service discovery and load balancing can be implemented in the form of services without the need to implement Trait independently.

We have also created an organization Volo-rs, any contributions are welcome.

For more information, you may refer to our guide.

Tutorial

Volo-Thrift: https://www.cloudwego.io/zh/docs/volo/volo-thrift/getting-started/

Volo-gRPC: https://www.cloudwego.io/zh/docs/volo/volo-grpc/getting-started/

Volo-HTTP: Work In Progess

Examples

See Examples.

Related Projects

• Volo-rs: The volo ecosystem which contains a lot of useful components.
• Motore: Middleware abstraction layer powered by AFIT and RPITIT.
• Pilota: A thrift and protobuf implementation in pure rust with high performance and extensibility.
• Metainfo: Transmissing metainfo across components.

RoadMap

See ROADMAP.md for more information.

Contributing

See CONTRIBUTING.md for more information.

License

Volo is dual-licensed under the MIT license and the Apache License (Version 2.0).

See LICENSE-MIT and LICENSE-APACHE for details.

Credits

We have used some third party components, and we thank them for their work.

For the full list, you may refer to the CREDITS.md file.

Community

• Email: [email protected]

• How to become a member: COMMUNITY MEMBERSHIP

• Issues: Issues

• Feishu: Scan the QR code below with Feishu or click this link to join our CloudWeGo Volo user group.

  

volo's Issues

我需要rpc 四种请求模式的示例 比如服务端流模式

我需要rpc 四种请求模式的示例 比如服务端流模式

Crates
volo-grpc

Motivation
没有在https://www.cloudwego.io/zh/docs/volo/volo-grpc/getting-started/ 中看到相关示例

Proposal
在开源群里得到了答复：https://github.com/cloudwego/volo/tree/main/examples/src

Support TLS for gRPC / 在 gRPC 中支持 TLS

Feature Request

Crates

volo-grpc

Motivation

Currently we don't support TLS in gRPC, we need to support it.

目前 volo-grpc 不支持 TLS，我们应当支持一下。

Proposal

TBD

Are you using Volo?

The purpose of this issue

We are always interested in finding out who is using Volo, what attracted you to using it, how we can listen to your needs and if you are interested, help promote your organization.

• We have people reaching out to us asking, who uses Volo in production?
• We’d like to listen to what you would like to see in Volo in your scenarios?
• We'd like to help promote your organization and work with you.

What we would like from you

Submit a comment in this issue and include the following information:

• Your organization or company
• Link to your website
• Your country
• Your contact info to reach out to you: blog, email or Twitter (at least one).
• What is your scenario for using Volo?
• Are you running your application in testing or production?

Organization/Company: ByteDance
Website: https://www.bytedance.com
Country: Global
Contact: [email protected]
Usage scenario: Using Volo to build large scale Cloud Native applications
Status: Production

Thank you very much!

cannot find macro `izip` in this scope

我更新依赖到0.6,报错截图如下

grpc 的调用能像anyhow::Result一样支持任意错误的抛出吗？

我觉得

Pin<Box<(dyn Future<Output = Result<volo_grpc::Response<QOut>, Status>

可以改为

Pin<Box<(dyn Future<Output = Result<volo_grpc::Response<QOut>, Into<Status>>

然后 为anyhow::Error 实现 Into

最后，就可以这么用
async fn q(&self, req: Request<QIn>) -> Result<Response<QOut>, anyhow::Error> {

可以作为一个单独的特性，选择性启用

Support reference type in rpc call

Feature Request

Support reference as method args in a rpc call
like
client.get_user_info(&UserInfoRequest{...})

Crates

volo-thrift

Motivation

in some case, it can save Clone cost.

Could add msrv in README?

Feature Request

add msrv(Minimum Supported Rust Version).

Crates

volo-*

Volo-gRPC 文档示例编译报错

在参照Volo文档搭建gRPC项目时，发现编译无法通过，报错信息如下：

error: failed to run custom build command for `volo-gen v0.1.0 (/Users/roger/personal-projects/volo-example/volo-gen)`

Caused by:
  process didn't exit successfully: `/Users/roger/personal-projects/volo-example/target/debug/build/volo-gen-2a96fb6f15154f43/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: using pure parser

  Caused by:
      file `../idl/volo_example.proto` must reside in include path []', /Users/roger/.cargo/registry/src/rsproxy.cn-637fb788320b50df/pilota-build-0.1.1/src/parser/protobuf/mod.rs:428:60
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Volo 中去掉对于 Service Clone 的 Trait Bound

随着 motore 0.3 的发布，Service 已经不再必须要 Clone 了，需要调研一下 Volo 是否可以去掉这个 Trait Bound。

Support de/compression for gRPC / gRPC 支持压缩/解压缩

Feature Request

Crates

volo-grpc

Motivation

Currently volo-grpc doesn't support de/compression, we need to support it.

目前 volo-grpc 不支持压缩/解压缩，我们需要对其进行支持。

Proposal

First, we need to add the de/compression builder option for grpc server and client, and this can only be set when initialize the server/client.

Then, we need to implement the de/compression logic in encoder/decoder, and send the compression header.

首先，我们需要给 grpc server 和 client 加上相关的压缩/解压缩的选项，这些选项应当只有初始化的时候可以设置。

其次，我们需要在 codec 中实现相关的压缩和解压缩的逻辑。记得要在 header 里面也增加 compression 的值。

pb 的生成代码能否加上注释？

pb 的生成代码能否加上注释？

how to add custom field to S in volo-rust

Hi，i need to call redis or remote service at fn in struct S.
How to add redis or thrift clients to struct S as struct field, so that i can touch them by '&self'.

Support auto generate default impl code in lib.rs in volo-cli init command / 使用 volo-cli init 时支持在 lib.rs 中自动生成一个默认实现

Feature Request

Crates

volo-cli

Motivation

Currently, we only generate an empty impl block for users, and they need to fill in this to get compiled.

It's better to generate a default impl for them when they call init command, such as a simple Ok(Default::default()).

目前 volo-cli 的 init 命令，只会生成一个空的impl代码块，用户必须补足这块才能编译通过。

如果我们能够在 init 时自动为用户生成一个默认实现，例如Ok(Default::default())会更好。

Proposal

First, we need to get the last service defined and its functions from the thrift or protobuf AST.

Then, we need to generate a struct for it, and provide a default impl for each function.

首先，我们需要从 thrift 或者 protobuf 的 AST 中获得用户定义的最后一个 service。

其次，我们需要为这个 service 的每一个方法生成一个默认的实现。

Question

Do we need to use another template engine instead of the built-in println macro?

我们是否需要更换一个更强大的模板引擎？

支持 Monoio 作为可选的 Runtime

Feature Request

Crates

影响所有的 crate。

Motivation

Monoio 是一个主要基于 io-uring 的 thread-per-core 的 runtime，在 thread-per-core 场景下性能很好。

支持 Monoio 作为可选的 runtime 可以使得我们的部分场景的用户获得巨大的性能提升，如 Proxy 场景用户和存储场景用户。

Proposal

首先，我们希望用户能够以较低的成本来在两个 Runtime 之间切换，例如使用 feature 的方式。我们可以定义两个 feature，如runtime-monoio和runtime-tokio。

接着，我们希望能够尽可能提高可维护性，因此我们可以把一些 runtime 相关的逻辑，抽象出来一个独立的包，例如叫做volo-rt，统一放到这个包里维护，并在其它 crate 中复用。

最后，我们需要找到所有直接依赖 tokio 的地方，改成依赖volo-rt或者通过条件编译改成 monoio 的方案。

要注意，有一些依赖库可能会直接依赖 tokio。

Alternatives

另一种可选的方案是，以牺牲一定性能为代价，尝试使用 monoio-compact 来兼容 Tokio。该方案可行性仍然待讨论。

基于 Volo 框架实现一个简单的 Redis Server 和 Client

Motivation

实现基于 Volo RPC 通信的 Redis Server 和 Client。

Requirements

1. 能够处理 GET SET 命令
2. 支持 AOF 持久化
3. 主从架构，主节点可以向从节点同步数据
4. 分片存储

Alternatives

Cli command generates project to ignore Cargo.lock file

Feature Request

Crates

volo-cli

Motivation

Add Cargo.lock file ignore

Proposal

Alternatives

Internal metrics support.

Feature Request

Crates

volo-otel? volo-var?

Motivation

like bvar in brpc. support export to otel or openmetrics format to prometheus easy.

export runtime metrics, like eventloop delay.

Proposal

like bvar. write metrics var to thread local storage. and merge all tls on read.

Alternatives

if not impl it in framework. user may need do it on application layer and hard to monitor runtime metrics. may conflict with volo's better perf. such like some prom client use one instance and need mutex. it may conflict with volo's slogan lock free.

快速开始教程无法编译

Bug Report

Version

Platform

Crates

Description

按新手教程中的步骤，编译失败，输出如下

error[E0277]: `dyn Future<Output = Result<Item, pilota::thrift::DecodeError>> + Send` is not a future
   --> /home/sen/code/volo-play/volo-example/target/debug/build/volo-gen-2f3f6b511768088d/out/volo_gen.rs:166:22
    |
166 |                   ) -> ::std::pin::Pin<
    |  ______________________^
167 | |                     ::std::boxed::Box<
168 | |                         dyn ::std::future::Future<
169 | |                                 Output = ::std::result::Result<Self, ::pilota::thrift::DecodeError>,
...   |
172 | |                     >,
173 | |                 > {
    | |_________________^ `dyn Future<Output = Result<Item, pilota::thrift::DecodeError>> + Send` is not a future
    |
    = help: the trait `Future` is not implemented for `dyn Future<Output = Result<Item, pilota::thrift::DecodeError>> + Send`
    = note: dyn Future<Output = Result<Item, pilota::thrift::DecodeError>> + Send must be a future or must implement `IntoFuture` to be awaited
    = note: required for `Pin<Box<dyn Future<Output = Result<Item, pilota::thrift::DecodeError>> + Send>>` to implement `Future`
note: required by a bound in `volo_thrift::Message::{opaque#0}`
   --> /home/sen/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/pilota-0.9.0/src/thrift/mod.rs:46:22
    |
46  |     ) -> impl Future<Output = Result<Self, DecodeError>> + Send;
    |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `Message::{opaque#0}`

error[E0277]: `dyn Future<Output = Result<Item, pilota::thrift::DecodeError>> + Send` cannot be sent between threads safely
   --> /home/sen/code//volo-play/volo-example/target/debug/build/volo-gen-2f3f6b511768088d/out/volo_gen.rs:166:22
    |
166 |                   ) -> ::std::pin::Pin<
    |  ______________________^
167 | |                     ::std::boxed::Box<
168 | |                         dyn ::std::future::Future<
169 | |                                 Output = ::std::result::Result<Self, ::pilota::thrift::DecodeError>,
...   |
172 | |                     >,
173 | |                 > {
    | |_________________^ `dyn Future<Output = Result<Item, pilota::thrift::DecodeError>> + Send` cannot be sent between threads safely
    |
    = help: the trait `Send` is not implemented for `dyn Future<Output = Result<Item, pilota::thrift::DecodeError>> + Send`
    = note: required for `std::ptr::Unique<dyn Future<Output = Result<Item, pilota::thrift::DecodeError>> + Send>` to implement `Send`
note: required because it appears within the type `Box<dyn Future<Output = Result<Item, DecodeError>> + Send>`
   --> /home/sen/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:195:12
    |
195 | pub struct Box<
    |            ^^^
note: required because it appears within the type `Pin<Box<dyn Future<Output = Result<Item, DecodeError>> + Send>>`
   --> /home/sen/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/pin.rs:410:12

rust 版本：

(base) [sen@OP005 volo-example]$ rustup --version 
rustup 1.26.0 (5af9b9484 2023-04-05)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.75.0-nightly (fee5518cd 2023-11-05)`

增加使用 volo workspace 命令的文档

Feature Request

Crates

Motivation

增加使用 volo workspace 命令的文档，文档需要补充在 https://github.com/cloudwego/cloudwego.github.io/tree/main/content/zh/docs/volo/guide 下

Proposal

Alternatives

eProsima Serialization

Feature Request

Please assess eProsima as a faster alternative to proto.

Crates

Volo

Motivation

QPS matters a lot and serialization and deserialization contributes a lot to the overall performance. As it seems eProsima is quite a bit faster than proto and thrift while improving latency.

Windows and Linux seems to be supported out of the box but Mac support is unclear from the documentation.

https://www.eprosima.com/index.php/resources-all/performance/apache-thrift-vs-protocol-buffers-vs-fast-buffers

https://www.eprosima.com/index.php/resources-all/performance/eprosima-fast-dds-performance

Proposal

There is a comprehensive C/C++ API that might need to get wrapped in Rust via unsafe.

https://www.eprosima.com/docs/fast-buffers/0.3.0/html/index.html

https://www.eprosima.com/index.php/products-all/tools/eprosima-fast-buffers

As I said, the actual question here is to start an assessment if it's worth integrating eprosima as a third option for better performance.

Maybe it's worth starting with a simple experiment to figure out if the performance gains are real?

Fixing some typos

Feature Request

Crates

• volo-build
• volo-cli

Motivation

• Fixing some typos

Proposal

Alternatives

Incorrect error propagation from server to client

Bug Report

Current behavior with error propagation leads to client error loss.
The issue is the same as in spring-cloud-gateway

Description

I've tried to compare the results from the official GRPC server and the Volo. You can create two identical implementations for Java/Scala/Kotlin and Volo which just respond with an error status for the unary call.

The Java version responds with a single error message and closes the stream in this message as well, as a result, the client receives an error as a result of the call.

The Volo version responds with two messages first with an error, and second with a stream close, as a result, the client is stuck.

Use GAT in volo-grpc `SendEntryMessage`

Feature Request

Crates

Motivation

The definition of SendEntryMessage can be better with GAT

pub trait SendEntryMessage {
    fn into_body(
        self,
        compression_config: Option<CompressionEncoding>,
    ) -> crate::BoxStream<'static, Result<Bytes, crate::Status>>;
}

with GAT

pub trait SendEntryMessage {
    type Body: Stream<Item = Result<Bytes, crate::Status>> + Send
    fn into_body(
        self,
        compression_config: Option<CompressionEncoding>,
    ) -> Self::Body;
}

代码生成多个文件和生成http-gw代码

1.代码生成，能不能不生成一个文件啊？想生成多个文件，因为proto想作为集中仓库，全部生成到一个文件里，不现实。proto是按文件夹管理的，我想生成的代码也是同样的文件夹。现在的问题是rs文件里不仅包含了path的代码，还包含了includes的代码，这没法分开生成了。
2.能生成http代码吗？protoc-gen-grpc-gateway这个就能生成go的http的代码。

Support graceful shutdown for volo-grpc / 为 volo-grpc 支持 graceful shutdown

Feature Request

Crates

volo-grpc

Motivation

Graceful shutdown is an important feature for grpc server, which can make the server completes all its requests before shutdown, which can promote SLA.

Graceful shutdown 对 server 来说是一个很重要的功能，可以让 server 在退出之前先处理完毕自己的所有请求，避免请求失败，并提升 SLA。

Proposal

We need to close the listener when we received the exit signal, which means we will not accept new connections nor new streams on exist connections.

Then, we need to wait for all exist requests to be completed, or we reach a timeout.

当我们接收到退出信号时，我们需要关闭 listener，不再接受新的连接，也不再接受新的 stream。

同时，我们需要等到所有已有的请求都处理完成后，或者达到超时时间后，再退出。

feat: Show me warning if artificialtion is empty or I did not use the artificialtion.

Feature Request

Motivation

• Background:
  Since I didn't know much about volo, I did a little exploring.
  I added some entries, but I didn't notice that I added thrift without service.

Proposal

1. So I want to do a [cargo check or cargo build or something] to remind me that the file I generated for the entry is empty.
   In other word, just give me a warning.
2. Even, if I don't include the corresponding filename, give me a warning.

• more info about option 2 in lib.rs

mod gen {
    volo::include_service!("volo_gen.rs");
    volo::include_service!("volo_gen2.rs");  // if I forget add this one
}

pub use gen::volo_gen::*;
pub use gen::volo_gen2::*;

Proposal: shall we use `async_fn_in_traits`?

Now that async_fn_in_traits has reached MVP in nightly, and will hopefully be stabilized in six months.

Shall we use that?

FYI:

1. https://blog.rust-lang.org/inside-rust/2022/11/17/async-fn-in-trait-nightly.html
2. rust-lang/rust#91611

rust 1.73-nightly

impl Trait only allowed in function and inherent method return types, not in trait method return types

增加对 callopt 功能的介绍

Feature Request

Crates

Motivation

增加对 callopt 功能的介绍, 文档需要补充在 https://github.com/cloudwego/cloudwego.github.io/tree/main/content/zh/docs/volo/guide 下

Proposal

Alternatives

Trait for async Thrift codec

Feature Request

Crates

volo-thrift

Motivation

Extending the Thrift (Apache) Compact protocol support for codec. Currently volo_thrift::message_wrapper::ThriftMessage<M> method decode_async only accept concrete &mut TAsyncBinaryProtocol<R> causing the following compile error:

error[E0308]: mismatched types
   --> volo/volo-thrift/src/codec/default/thrift.rs:174:62
    |
174 |                 let msg = ThriftMessage::<Msg>::decode_async(&mut p, cx).await?;
    |                           ---------------------------------- ^^^^^^ expected struct `TAsyncBinaryProtocol`, found struct `TAsyncCompactProtocol`
    |                           |
    |                           arguments to this function are incorrect
    |
    = note: expected mutable reference `&mut TAsyncBinaryProtocol<_>`
               found mutable reference `&mut TAsyncCompactProtocol<&mut volo::util::buf_reader::BufReader<R>>`
note: associated function defined here
   --> volo/volo-thrift/src/message_wrapper.rs:185:25
    |
185 |     pub(crate) async fn decode_async<Cx: ThriftContext + Send, R>(
    |                         ^^^^^^^^^^^^
186 |         protocol: &mut TAsyncBinaryProtocol<R>,
    |         --------------------------------------

Proposal

Trait for async codec, use GAT just like TInputProtocol and TOutputProtocol are implemented.

Alternatives

None, RFC?

支持使用自定义 Codec 实现

Feature Request

Crates

volo-thrift

Motivation

目前我们仅支持了 CodecType 的设置，但是 Codec 的实现仍然是写死的 BinaryProtocol，并且不允许替换实现。

为了支持更多的 Protocol 和使用场景，也为了之后的 Codec 性能优化做准备，我们需要支持自定义 Codec 实现。

Proposal

TBD

Volo-gRPC 支持 gRPC gateway

ref: https://github.com/grpc-ecosystem/grpc-gateway

如何同时对 .proto 文件生成代码？

gRPC 的新手，冒昧地打扰一下！

看到 #87 提到已经支持一个 server 包含多个 service，但不知如何生成代码？举例，我有：

proto/a.proto
proto/b.proto

其中 a.proto 定义了 service ServiceA {}，以此类推。而 文档 中的举例是：

volo init --includes=idl volo-example idl/volo_example.proto

这里我们使用init命令，后面跟了我们项目的名字，意思是需要生成模板代码。在末尾，需要指定一个 IDL 表示 server 使用的 IDL。

如果只需要增加一个 IDL（如 client 的 IDL）而不需要生成模板的话，如：

$ volo idl add idl/volo_example.proto

是否说明 volo 只能对单文件生成项目？我该如何对多个 .proto 生成代码以提供多个 service ？gRPC 也不支持 service 嵌套……

谢谢！

---

另外还有个小问题，volo 命令行中的 entry （默认值为 default）是何用处？

Add examples to volo / 为 Volo 增加一些示例

Feature Request

Proposal

Firstly, we need to create a new directory called examples, and write an idl file.

Secondly, we should generate an example using volo-cli, and adjust the Cargo.toml to use path instead of from crate.io.

Thirdly, we need to add an example to write a layer such as log layer, and add it to the server or client.

[Test]Add test case for volo crate util mod

Feature Request

Crates

volo

Motivation

• Add test case for volo crate util mod

Proposal

Alternatives

Windows support / 支持 Windows 系统

Feature Request

Crates

volo

Motivation

We used tokio::net::unix directly so windows is not supported now.

目前我们直接使用了tokio::net::unix所以 windows 上目前编译不过。

Proposal

We can use conditional compilation to resolve this.

我们可以尝试使用条件编译来解决这个问题。

generic call

Feature Request

Crates

volo

Motivation

for gateway usage

Proposal

Alternatives

gRPC 支持一个 server 中包含多个 service

Feature Request

Crates

Volo-gRPC

Motivation

支持一个 server 中包含多个 service。

Re-export FastStr

FastStr is used in the public API, but user cannot import FastStr directly.

cargo install volo-cli failed

error: failed to download from `https://crates-io.proxy.ustclug.org/api/v1/crates/volo-cli/0.3.3/download`
Timeout was reached (failed to download any data for `volo-cli v0.3.3` within 30s)

好像缺少volo-cli v0.3.3包

[test]Add test case for crate volo-build util

Feature Request

Crates

volo-build

Motivation

Add test case for crate volo-build util

Proposal

Alternatives

HTTP transport for Thrift

Feature Request

Support for HTTP server/client transport wrapper for Thrift RPC.

Crates

volo-thrift

Motivation

Extending compatibility of Thrift implementation to support HTTP transport wrapper.
Current state of supported features compared with another Thrift library: apache/thrift/LANGUAGES.md

Proposal

Using hyper as Thrift HTTP transport wrapper, implements volo::net::dial::MakeTransport.

Alternatives

RFC

windows下怎么编译

Compiling num_enum_derive v0.5.7
Compiling volo v0.1.0
Compiling volo-build v0.1.1
error[E0432]: unresolved imports tokio::net::unix, tokio::net::UnixStream
--> C:\Users\BJSYDZ.cargo\registry\src\github.com-1ecc6299db9ec823\volo-0.1.0\src\net\conn.rs:10:16
|
10 | net::{tcp, unix, TcpStream, UnixStream},
| ^^^^ ^^^^^^^^^^ no UnixStream in net
| |
| no unix in net

error[E0432]: unresolved import tokio::net::UnixStream
--> C:\Users\BJSYDZ.cargo\registry\src\github.com-1ecc6299db9ec823\volo-0.1.0\src\net\dial.rs:4:22
|
4 | net::{TcpStream, UnixStream},
| ^^^^^^^^^^ no UnixStream in net

Add integration tests for volo

Currently, we relies on the internal long-running stability testing services to ensure the stability of volo. This is not easily noticeable and cannot prevent errors from being merged in ci.

Thus, we need to add some integration tests for volo and run them in the github action.

I think we can just follow the guide in TRPL here.

I'll add some examples later when I have time.

Support consistent hash load balance / 支持一致性哈希路由

Feature Request

Crates

volo

Motivation

Consistent hash load balance is useful and important, we need to support it.

一致性哈希路由是一个很常用也很重要的路由策略，我们需要支持它。

Proposal

We can refer to the implementation of Kitex, which uses the hash ring algorithm.

We can also use red-black tree to optimize the performance.

我们可以参考Kitex的实现，并在其基础之上进行优化，如使用红黑树进行在线的更新。

Alternatives

Is there any other better implementations?

欢迎大家提出更佳的实现方式。

error: non-defining opaque type use in defining scope

Bug Report

Version

volo v0.2.0

Platform

Windows 11 64-bit

active toolchain

nightly-x86_64-pc-windows-msvc (overridden by 'D:\volo-example\rust-toolchain.toml')
rustc 1.66.0-nightly (758f19645 2022-10-24)

Description

run this example

error: non-defining opaque type use in defining scope
   --> C:\Users\xxx\.cargo\registry\src\mirrors.ustc.edu.cn-61ef6e0cd06fb9b8\volo-0.2.0\src\loadbalance\random.rs:128:9
    |
128 | /         async {
129 | |             let key = discover.key(endpoint);
130 | |             let weighted_list = match self.router.entry(key) {
131 | |                 Entry::Occupied(e) => e.get().clone(),
...   |
148 | |             })
149 | |         }
    | |_________^ lifetime `'future` is part of concrete type but not used in parameter list of the `impl Trait` type alias

Optimize the init command code

Feature Request

Crates

volo-cli

Motivation

Optimize the init command code

Proposal

Alternatives

支持注册中心吗

支持注册中心吗

Add a description for Cli init command argument name

Feature Request

Crates

volo-cli

Motivation

Proposal

Add a description for Cli init command argument name

Alternatives

Implement a limiter Layer for volo / 为 Volo 实现一个过载保护 Layer

Feature Request

Crates

This should be placed under https://github.com/volo-rs.

这应该放在 volo-rs 组织下，作为 volo 的生态。

Motivation

Limiters are very useful when under high qps, which can prevent the server from being overload.

We can support it for volo.

过载保护对于在大流量下保护 server 非常有用，这可以防止 server 被打挂然后雪崩。

Proposal

We propose to support a QPS limiter and a concurrent limiter for volo.

实现一个 QPS limiter 和一个 concurrent limiter，尽可能让 gRPC 和 Thrift 都能用。