krpc-rust Фреймворк Rust-RPC, больше всего похожий на фреймворк RPC.

https://github.com/kwsc98/krpc-rust

Студенты, которые только что изучили язык Rust или мало что знают о платформе Rust-RPC, могут подумать, что это просто еще одна горячая тема, но на самом деле студенты, которые поняли эту часть, знают, что текущая основная среда Rust-RPC и фактическое определение RPC. Структура все еще сильно отличается. Давайте сначала посмотрим, как реализована соседняя Java. В качестве примера возьмем Java-версию krpc-java этого проекта. Студенты, заинтересованные в изучении платформы Java-RPC, не забудьте нажать «Звездочка».

krpc

Внедрите структуру RPC на основе сетевой модели одноканального мультиплексирования Netty, поддержите запуск с весенней загрузкой, Zookeeper и центр регистрации Nacos.

Начните с SpringBoot

Пример интерфейса

public interface ExampeService {
   ResponseDTO doRun(RequestDTO requestDTO);
}

Customer

Настройте application.properties krpc.registeredPath = nacos://114.116.3.221:8848

@KrpcResource(version = "1.0.1",timeout = 1000)
private ExampeService exampeService;

Provider

Настройте application.properties krpc.registeredPath = nacos://114.116.3.221:8848 krpc.port = 8082

@KrpcService(version = "1.0.1")
public class ExampeServiceImpl implements ExampeService {
   
   @Override
   public ResponseDTO doRun(RequestDTO requestDTO) {
       ResponseDTO responseDTO = new ResponseDTO();
       responseDTO.setDate(new Date(requestDTO.getDate().getTime() + (long) requestDTO.getNum() * 60 * 60 * 1000));
       return responseDTO;
   }
}

Мы видим, что нам нужно только определить интерфейс, а затем серверная часть реализует этот интерфейс, а клиентская сторона добавляет аннотацию к интерфейсу, и тогда можно выполнять вызовы RPC. Это связано с тем, что в Java есть большой убийца, а именно. отражение во время выполнения, которое можно легко улучшить классами во время выполнения, но это также является основным недостатком Java, заключающимся в том, что выполнение программы сокращается из-за существования среды выполнения. Конечно, Rust, известный своей высокой производительностью, делает это. не имеет среды выполнения, но также не имеет функции отражения времени выполнения One, так как же нынешняя основная платформа Rust-RPC решает эту проблему? В настоящее время на рынке представлены два основных продукта: Dubbo от Alibaba и Volo от Byte. Сначала давайте посмотрим, как Dubbo это делает.

Глава «Быстрый старт Dubbo» описывает, как использовать Dubbo Rust. Фактически она разделена на три части.

Первая часть определяет интерфейс. В настоящее время Dubbo поддерживает множество протоколов, включая протокол gRPC. Версия Rust реализует интерфейс через протокол ProtoBuf.

avatar

Вторая часть заключается в реализации соответствующего кода Rust через файл определения. Поскольку у Rust нет среды выполнения, нет возможности генерировать клиентский класс через динамический прокси-сервер при вызове клиента. Решением Dubbo является создание соответствующих вызовов клиента. путем определения кода содержимого интерфейса, чтобы «снижать» стоимость использования для пользователей.

avatar

Третья часть — написать соответствующую логику кода на стороне сервера, а затем выполнить вызовы RPC через сгенерированный код клиента.

Volo компании Byte фактически следует той же идее. Он определяет интерфейс посредством IDL, а затем генерирует вызывающий код с помощью сценариев формирования шаблонов. Заинтересованные студенты могут ознакомиться с быстрым запуском Volo-grpc.

avatar

Подводя итог, можно использовать сценарии для создания вызывающего кода и интерфейсов служб посредством определений интерфейсов, а затем реализовать бизнес-реализацию на стороне сервера и клиентские вызовы.

Если посмотреть на это с этой точки зрения, реализация Dubbo и Volo, особенно по сравнению с реализацией версии Java, все еще далека от реальной структуры RPC, включая множество проблем, таких как

1. Необходимо использовать некоторые спецификации интерфейса RPC, например код ошибки, на который следует реагировать.

// #[async_trait]
#[async_trait]
impl Greeter for GreeterServerImpl {
    async fn greet(
        &self,
        request: Request<GreeterRequest>,
    ) -> Result<Response<GreeterReply>, dubbo::status::Status> {
        println!("GreeterServer::greet {:?}", request.metadata);

        Ok(Response::new(GreeterReply {
            message: "hello, dubbo-rust".to_string(),
        }))
    }
}

1. При вызове Клиента тело запроса должно быть упаковано в стиле, генерируемом кодом.

    let req = volo_gen::proto_gen::hello::HelloRequest {
        name: FastStr::from_static_str("Volo"),
    };

1. Ключ в том, хотите ли вы изменить поле ответа на запрос или добавить новый интерфейс.,Затем мы должны перегенерировать весь код с помощью скриптов.,Включая клиентскую и серверную часть,Все мы знаем компании, у которых есть требования к качеству программного обеспечения.,При изменении кода необходимо оценить масштаб влияния и затем отправить его на тестирование.,Означает ли это, что если мы внесем небольшие изменения, нам придется позволить тесту выполнить все тестирование?

Так является ли отсутствие отражения во время выполнения в Rust также «недостатком»? В настоящее время это действительно так. Оба крупных производителя могут дать только такой ответ, который нас не устраивает. У Java есть убийственное оружие отражения, позволяющее доминировать в области микросервисов. Так что же может сделать Rust для улучшения микросервисов? поле также бросает вызов Java? Затем мы должны упомянуть макрооружие уровня ядерной бомбы Rust.

Макросы ржавчины

Все в шутку утверждают, что макросы Rust могут реализовать другой язык программирования посредством макросов. Это показывает силу макросов. Мы все знаем, что макросы действуют во время компиляции, поэтому не будет ли достаточно, если мы просто используем макросы для реализации отражения во время компиляции. ? Факты действительно правдивы. После разговора о столь длинном абзаце ерунды выше, давайте перейдем к основной теме и посмотрим. krpc-rust Если выполнен вызов RPC

Server

use krpc_core::server::KrpcServer;
use krpc_macro::krpc_server;
use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize, Default, Debug)]
struct ReqDto {
   str: String,
}

#[derive(Serialize, Deserialize, Default)]
struct ResDto {
   str: String,
}

#[derive(Clone)]
struct TestServer {
   _db: String,
}

krpc_server! {
  TestServer,
  "1.0.0",
  async fn do_run1(&self,res : ReqDto) -> ResDto {
   println!("{:?}" ,res);
   return ResDto { str : "TestServer say hello 1".to_string()};
  }
  async fn do_run2(&self,res : ReqDto) -> ResDto {
   println!("{:?}" ,res);
   return ResDto { str : "TestServer say hello 2".to_string()};
  }
}

#[tokio::main(worker_threads = 512)]
async fn main() {
   let server: TestServer = TestServer {
       _db: «Я база данных БД».to_string(),
   };
   KrpcServer::build()
       .set_port("8081")
       .add_rpc_server(Box::new(server))
       .run()
       .await;
} 

Client

use krpc_core::client::KrpcClient;
use krpc_macro::krpc_client;
use lazy_static::lazy_static;
use serde::{Deserialize, Serialize};

lazy_static! {
    static ref CLI: KrpcClient = KrpcClient::build("http://127.0.0.1:8081".to_string());
}

#[derive(Serialize, Deserialize, Default, Debug)]
struct ReqDto {
    str: String,
}

#[derive(Serialize, Deserialize, Default,Debug)]
struct ResDto {
    str: String,
}

struct TestServer;

krpc_client! {
   CLI,
   TestServer,
   "1.0.0",
   async fn do_run1(&self,res : ReqDto) -> ResDto
   async fn do_run2(&self,res : ReqDto) -> ResDto 
}

#[tokio::main(worker_threads = 512)]
async fn main() {
    let client = TestServer;
    let res = client.do_run1(ReqDto{str : "client say hello 1".to_string()}).await;
    println!("{:?}",res);
    let res = client.do_run2(ReqDto{str : "client say hello 2".to_string()}).await;
    println!("{:?}",res);
}

Давайте запустим его напрямую и посмотрим

avatar

Это то, на что похожа структура RPC? Если вы видите здесь студентов, поставьте этому проекту звездочку в знак благодарности за поддержку. Этот проект — хороший обучающий проект, и я также надеюсь, что благодаря этому проекту Rust также будет развиваться в области микросервисов. Благодаря концепции нулевой стоимости абстракции в Rust, этот проект, конечно, также нацелен на высокую производительность, поэтому давайте просто проведем стресс-тест, потому что какое-то время мне не удавалось запустить текущий пример версии Dubbo с открытым исходным кодом... Итак, мы сделаем это с помощью Compare Volo.

https://github.com/kwsc98/krpc-rust

Машина для стресс-тестирования — MacBook Pro M1 16 + 512. Содержание стресс-теста — четыре миллиона запросов. Количество асинхронных потоков — 512 на стороне клиента и 512 на стороне сервера. Поскольку вызовы RPC требуют большого количества операций ввода-вывода, требуется больше потоков. открылся. Ниже приведен тестовый скрипт

krpc-rust Результаты испытаний Четыре миллиона запросов были выполнены в среднем за 47 секунд, 8,5w+QTS в секунду! ! ! И использование памяти относительно стабильно.

Могу только сказать, что он достоин Rust, а Java выражает зависть к системе реальных имен... Далее мы посмотрим на выступление Воло. Лоб. . . Что-то произошло. При тестировании 100-го параллелизма все работало нормально, но потребление памяти и времени во время стресс-теста было аномально высоким, поскольку печать журнала была отключена для стресс-теста. Затем откройте журнал и посмотрите результат.

Когда concurrency был установлен на 500, произошла ошибка в соединении сокета. Только 139 из 500 запросов были успешными. В Volo все еще могут быть некоторые проблемы, но влияние не является значительным. Мы доказали, что у Rust действительно есть шанс. убить Java в сфере микросервисов.

Если заинтересованные студенты могут обсуждать и учиться вместе, в этом проекте еще предстоит проделать работу, такую ​​​​как обработка исключений, многокомпонентная поддержка, регистрация и обнаружение сервисов, но скелет платформы уже построен и проверен, и будущее многообещающее. ~