标签: grpc

我知道我们正在比较两种不同的技术,但我想知道两者的优缺点.WCF现在已经存在了将近十年.到目前为止,java世界中没有类似的东西吗？

我已经尝试了3天,现在找到如何在没有运气的情况下在Windows上安装和使用gRPC.我使用的是Visual Studio 2015,Win7 64位.为了安全起见,我会一步一步地写下我正在做的事情.它可能没有必要,但我是C++和VS的初学者,所以我不确定我是否正确地做到了:

(以下指南http://www.infopulse.com/blog/grpc-framework-by-google-tutorial/):

• 从git,init子模块获取gRPC
• 为protobuf获取gmock和gtest(不在指南中,但是它不起作用)
• 在protobuf上运行cmake
• 在发布模式下在Visual Studio中构建protobuf.sln(为解决方案的每个部分设置Property Manager> C/C++>代码生成>运行时库> / MDd)
• Copy Release/ folder to protobuf/cmake/ (instead of Debug/ as in intructions - that would give me libprotobufd.lib instead of libprotobuf.lib which is required)
• Build grpc/vsprojects/grpc_protoc_plugins.sln in VS also in Release mode and again set for each part of the solution Property Manager > C/C++ > Code Generation > Runtime Library > /MDd
• Copy protoc.exe from protobuf/cmake/Release to grpc/vsprojects/Release, which was …

我试图让一台Grpc服务器作为控制台守护程序运行.这个gRPC服务器是一个在docker容器中运行的微服务.

我能找到的所有例子都使用以下内容:

Console.ReadKey();

这确实会阻塞主线程并使其保持运行但在docker中不起作用,并出现以下错误:

"Cannot read keys when either application does not have a console or when console input has been redirected. Try Console.Read."

现在我可能会尝试专门为docker找到解决方法,但这仍然感觉不对.有没有人知道一个良好的"生产就绪"方式来保持服务运行？

golang grpc 实现是如何处理服务器并发的？

每个方法调用一个 goroutine？或者某种 goroutine 池？

是否依赖于net/http2的并发模型？

用于创建通道的 gRPC C++ API 返回一个 shared_ptr。生成的函数 NewStub 返回一个 unique_ptr。但是，我已经看到有人在尝试创建存根类型的多个实例、共享频道时遇到问题的报告。他们的解决方案是共享存根。

从文档或 API 中不清楚客户端是要创建多个共享通道的存根实例还是共享单个存根。请阐明存根、通道和唯一客户端连接之间的概念关系。

深入一点：服务器可以提供多个服务，客户端端点可以使用单个通道将相应的存根类型连接到这些服务中的每一个。为此，很明显不同的存根类型共享单个通道以与服务器端点通信。对于给定的服务，gRPC 是否期望每个通道只有一个客户端，或者我可以在客户端端点上有多个客户端与单个服务通信？如果允许，如何在客户端端点上为给定服务实现多个客户端？服务器如何将这些区分为独立的客户端？

顺便说一句，这篇 SO 帖子表明 Channels 和 Stubs 都是线程安全的。（这篇文章是专门针对 Java 的，但我假设它会延续到 C++）。

我想为我信任的来源创建一个 grpc 通道，但我缺少其证书。使用默认凭据设置安全通道失败：

import gprc
ssh_channel = grpc.secure_channel(<gprc url>, grpc.ssl_channel_credentials())
grpc.channel_ready_future(ssh_channel).result()

结果是：

E1017 10:05:15.783011100   11539 ssl_transport_security.cc:1229] Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED.
E1017 10:05:16.846366639   11539 ssl_transport_security.cc:1229] Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED.
E1017 10:05:18.688887874   11539 ssl_transport_security.cc:1229] Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED.
E1017 10:05:21.557399186   11539 ssl_transport_security.cc:1229] Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED.

我知道这是可能的，因为例如在 Java 中，会执行以下操作：

import io.grpc.netty.GrpcSslContexts;
import io.grpc.netty.NettyChannelBuilder;
import io.netty.handler.ssl.SslContext;
import io.netty.handler.ssl.util.InsecureTrustManagerFactory;
...
sslContext = GrpcSslContexts.forClient().trustManager(InsecureTrustManagerFactory.INSTANCE).build();
channel = NettyChannelBuilder.forAddress(<gprc url>, 443).sslContext(sslContext).build(); …

// api_internal.proto
service InvoiceTemplateMatcher {
   rpc Process(InvoiceFilePath) returns (UploadStatus) {}
}

message InvoiceFilePath {
   string invoice_id = 1;
   string file_path = 2;
}

// template_matcher/src/main.cc
class OrkaEngineInvoiceTemplateMatcherImpl final : public InvoiceTemplateMatcher::Service {
private:
    Status Process(
        ServerContext* context,
        orka_engine_internal::InvoiceFilePath* invoicefp,
        orka_engine_internal::UploadStatus* response) override {
    // do stuff
    }
};

类InvoiceTemplateMatcher::Service是在编译期间从该.proto文件生成的。

当我尝试编译时，出现错误

‘grpc::Status OrkaEngineInvoiceTemplateMatcherImpl::Process(grpc::ServerContext*, orka_engine_internal::InvoiceFilePath*, orka_engine_internal::UploadStatus*)’ marked ‘override’, but does not override
     Status Process(ServerContext* context, orka_engine_internal::InvoiceFilePath* invoicefp, orka_engine_internal::UploadStatus* response) override {

据我所知，我的代码与Route Guide example 中的编写方式相同。我错过了什么？

由于您必须共享 .proto 文件来为 gRPC 定义数据和服务，因此服务提供者和客户端需要访问相同的 .proto 文件。是否有分发这些文件的通用策略？我想避免每个项目在其 Git 存储库中都有自己的 .proto 文件，而我们的团队成员需要手动编辑这些文件或通过电子邮件共享它们。

有什么共同的最佳实践吗？

我正在工作gRPC，我想在同一个端口上运行多个服务

Server server = ServerBuilder.forPort(8080)
    .addService(new HelloServiceImpl())
    .addService(new ByeServiceImpl())
    .build();

Server server = ServerBuilder.forPort(8080)
    .addService(new HelloServiceImpl())
    .addService(new ByeServiceImpl())
    .build();

syntax = "proto3";

option java_multiple_files = true;

package proto3.rpc;

message HelloRequest {
    string firstName = 1;
    string lastName = 2;
}

message HelloResponse {
    string greeting = 1;
}

service HelloService {
    rpc hello(HelloRequest) returns (HelloResponse);
}

syntax = "proto3";

option java_multiple_files = true;

package proto3.rpc;

message ByeRequest {
    string firstName …