本文深入探討了grpc java服務(wù)器在添加多個服務(wù)時可能遇到的一個隱蔽問題：當不同服務(wù)由同名但位于不同目錄的protobuf文件定義時，可能導(dǎo)致部分服務(wù)無法正常暴露。文章揭示了`protoreflectionservice`內(nèi)部處理文件描述符的機制是問題的根源，并提供了通過確保protobuf文件命名唯一性來解決此類沖突的有效方案與最佳實踐，以保障grpc服務(wù)的穩(wěn)定性和可發(fā)現(xiàn)性。

gRPC服務(wù)暴露異?，F(xiàn)象解析

在構(gòu)建gRPC服務(wù)器時，我們通常會通過ServerBuilder.addService()方法注冊多個服務(wù)實例。然而，有時會遇到一個令人困惑的現(xiàn)象：盡管所有服務(wù)都已被顯式添加，并且grpcurl list命令也能正確列出所有服務(wù)，但嘗試通過grpcurl調(diào)用其中某個服務(wù)的RPC方法時，卻會收到“target server does not expose service”的錯誤信息。

例如，以下是一個典型的gRPC服務(wù)器構(gòu)建代碼片段：

Server server = ServerBuilder
        .forPort(8980)
        .addService(new GrpcService1())
        .addService(new GrpcService2())
        .addService(new GrpcService3())
        .addService(ProtoReflectionService.newInstance()) // 添加反射服務(wù)
        .build();

假設(shè)GrpcService1和GrpcService2是由不同的.proto文件定義，但這兩個文件恰好擁有相同的名稱，例如都命名為services.proto，即使它們位于不同的包路徑下。在這種情況下，如果GrpcService1先于GrpcService2被添加，那么GrpcService2將無法被客戶端正常調(diào)用，反之亦然。而GrpcService3由于其.proto文件名稱唯一，則始終可以正常工作。

當嘗試調(diào)用受影響的服務(wù)時，grpcurl會返回如下錯誤：

立即學(xué)習(xí)“Java免費學(xué)習(xí)筆記（深入）”；

$ grpcurl -plaintext \                   
  localhost:8980 \
  specs.grpc_service2.GrpcService2/someRpc
Error invoking method "specs.grpc_service2.GrpcService2/someRpc": target server does not expose service "specs.grpc_service2.GrpcService2"

然而，通過grpcurl list命令，所有服務(wù)似乎都已注冊成功：

$ grpcurl -plaintext localhost:8980 list
grpc.reflection.v1alpha.ServerReflection
specs.grpc_service3.GrpcService3
specs.grpc_service2.GrpcService2
specs.grpc_service1.GrpcService1

這種矛盾的現(xiàn)象表明，問題并非出在服務(wù)注冊本身，而可能與服務(wù)發(fā)現(xiàn)或反射機制的內(nèi)部處理邏輯有關(guān)。

根本原因：ProtoReflectionService的工作機制

經(jīng)過深入調(diào)查，問題的根源在于ProtoReflectionService的內(nèi)部實現(xiàn)。ProtoReflectionService是gRPC提供的一個重要組件，它允許客戶端在運行時發(fā)現(xiàn)服務(wù)器暴露的服務(wù)及其方法定義，這對于grpcurl、gRPC UI等工具至關(guān)重要。

ProtoReflectionService在處理服務(wù)描述符時，會遍歷所有已注冊的服務(wù)，并提取其對應(yīng)的Protobuf文件描述符（FileDescriptor）。為了避免重復(fù)處理同一個Protobuf文件，它內(nèi)部維護了一個已處理文件名稱的集合（seenFiles）。其核心邏輯如下：

// 簡化后的ProtoReflectionService內(nèi)部邏輯
if (!seenFiles.contains(fileDescriptor.getName())) {
  seenFiles.add(fileDescriptor.getName());
  fileDescriptorsToProcess.add(fileDescriptor);
}

這里的關(guān)鍵在于fileDescriptor.getName()方法。該方法返回的是Protobuf文件的物理文件名（例如，services.proto），而不是其完整的路徑或Protobuf包名。因此，如果兩個不同的Protobuf文件，即使它們位于不同的目錄或定義了不同的package和option java_package，但只要它們的文件名相同，ProtoReflectionService就會錯誤地認為它們是同一個文件。

當?shù)谝粋€名為services.proto的文件（例如GrpcService1對應(yīng)的文件）被處理并添加到seenFiles集合后，第二個同樣名為services.proto的文件（例如GrpcService2對應(yīng)的文件）在后續(xù)處理中，其fileDescriptor.getName()返回值將與seenFiles中的現(xiàn)有條目匹配。結(jié)果是，第二個文件的描述符會被忽略，不會被添加到fileDescriptorsToProcess中，導(dǎo)致ProtoReflectionService無法正確地為該服務(wù)提供反射信息，盡管該服務(wù)本身可能已在gRPC服務(wù)器中注冊。

NameGPT名稱生成器

免費AI公司名稱生成器，AI在線生成企業(yè)名稱，注冊公司名稱起名大全。

0

查看詳情

以下是兩個沖突的.proto文件定義示例：

src/main/proto/grpc_service1/services.proto：

syntax = "proto3";

option java_multiple_files = true;
option java_package = "com.service.internal_query_api";
option java_outer_classname = "InternalQueryGrpcProto";

package specs.grpc_service1;

service GrpcService1 {
  // ...
}

src/main/proto/grpc_service2/services.proto：

syntax = "proto3";

option java_multiple_files = true;
option java_package = "com.service.matform.api";
option java_outer_classname = "MatformGrpcProto";

package specs.grpc_service2;

service GrpcService2 {
  // ...
}

盡管它們的package和java_package不同，但由于文件名都是services.proto，因此觸發(fā)了上述沖突。

解決方案與最佳實踐

解決此問題的方案非常直接：確保項目中所有Protobuf文件的物理文件名都是唯一的。

解決方案

只需重命名沖突的Protobuf文件之一，使其具有一個獨特的名稱。例如，將src/main/proto/grpc_service2/services.proto重命名為src/main/proto/grpc_service2/matform_services.proto或src/main/proto/grpc_service2/service2_api.proto。

重命名后，ProtoReflectionService將能夠正確區(qū)分這兩個文件，并為所有服務(wù)提供完整的反射信息，從而解決服務(wù)暴露沖突。

最佳實踐

為了避免未來再次遇到此類問題，建議在Protobuf項目開發(fā)中遵循以下命名規(guī)范：

1. 全局唯一文件名： 確保整個項目中所有.proto文件的文件名都是唯一的。這是一種簡單而有效的預(yù)防措施。
2. 描述性命名： 使用能夠清晰反映文件內(nèi)容或所屬服務(wù)的名稱。例如，如果一個.proto文件定義了用戶服務(wù)相關(guān)的消息和RPC，可以命名為user_service.proto或user_api.proto。
3. 避免通用名稱： 盡量避免使用services.proto、messages.proto、common.proto等過于通用的文件名，尤其是在大型或模塊化的項目中，這些名稱很容易在不同模塊中重復(fù)。
4. 結(jié)合包名或服務(wù)名： 可以在文件名中包含其所屬的Protobuf包名或服務(wù)名，以進一步確保唯一性和可讀性。例如，com.example.users包下的User.proto可以命名為users_user.proto。

注意事項與總結(jié)

• 與Java包名無關(guān)： 此問題與Protobuf文件內(nèi)部定義的package或option java_package無關(guān)。即使這些包名完全不同，只要物理文件名相同，沖突依然會發(fā)生。
• grpcurl list的誤導(dǎo)性： grpcurl list命令可能仍然會列出所有服務(wù)，但這并不能保證每個服務(wù)都能被成功調(diào)用。這是因為list操作可能依賴于不同的反射API或緩存機制，而實際的RPC方法調(diào)用需要更完整的服務(wù)描述符信息。
• 反射服務(wù)的重要性： ProtoReflectionService對于gRPC生態(tài)系統(tǒng)中的工具鏈至關(guān)重要。確保其正常工作是保障開發(fā)和運維效率的基礎(chǔ)。

總結(jié)，gRPC Java服務(wù)器中服務(wù)暴露沖突，尤其是當ProtoReflectionService參與其中時，通常是由Protobuf文件的物理文件名重復(fù)導(dǎo)致的。理解ProtoReflectionService的工作原理，并采納全局唯一的Protobuf文件命名規(guī)范，是確保gRPC服務(wù)穩(wěn)定、可發(fā)現(xiàn)和易于維護的關(guān)鍵。通過簡單的文件重命名和良好的命名習(xí)慣，可以有效規(guī)避這類隱蔽但影響深遠的問題。

以上就是解決gRPC Java服務(wù)器服務(wù)暴露沖突：Protobuf文件命名規(guī)范的重要性的詳細內(nèi)容，更多請關(guān)注php中文網(wǎng)其它相關(guān)文章！