没有合适的资源?快使用搜索试试~ 我知道了~
首页gRPC: Up and Running
本书介绍了gRPC的基本概念和实例,是一本适用于Go、Java、Node和Python的实践指南。通过本书,读者可以全面了解gRPC高性能的进程间通信协议,并学习如何在微服务架构中使用gRPC连接多语言服务,同时提供了定义服务合同和数据类型的丰富框架。 书中结合了实际案例,通过Go、Java、Node和Python的实例帮助读者理解gRPC的使用。此外,本书还介绍了使用gRPC开发产品的关键技术和最佳实践。 本书的作者是Kasun Indrasiri和Danesh Kuruppu,版权归他们所有。此外,该书由O'Reilly Media出版,在美国的Sebastopol出版。读者可以购买该书用于教育、商业或个人用途。
资源详情
资源评论
资源推荐
fundamentals of protocol buffers in detail in Chapter 4, but for now you can
think of it as a data serialization mechanism). The service interface
definition is specified in a proto file—an ordinary text file with a .proto
extension. You define gRPC services in ordinary protocol buffer format,
with RPC method parameters and return types specified as protocol buffer
messages. Since the service definition is an extension to the protocol buffer
specification, a special gRPC plug-in is used to generate code from your
proto file.
In our example use case, the
ProductInfo
service’s interface can be
defined using protocol buffers as shown in Example 1-1. The service
definition of
ProductInfo
is comprised of a service interface definition
where we specify the remote methods, their input and output parameters,
and the type definition (or message formats) of those parameters.
Example 1-1. gRPC service definition of ProductInfo service using protocol
buffers
// ProductInfo.proto
syntax = "proto3";
package ecommerce;
service ProductInfo {
rpc addProduct(Product) returns (ProductID);
rpc getProduct(ProductID) returns (Product);
}
message Product {
string id = 1;
string name = 2;
string description = 3;
}
message ProductID {
string value = 1;
}
The service definition begins with specifying the protocol buffer version
(proto3) that we use.
Package names are used to prevent name clashes between protocol
message types and also will be used to generate code.
Defining the service interface of a gRPC service.
Remote method to add a product that returns the product ID as the
response.
Remote method to get a product based on the product ID.
Definition of the message format/type of
Product
.
Field (name-value pair) that holds the product ID with unique field
numbers that are used to identify your fields in the message binary
format.
User-defined type for product identification number.
A service is thus a collection of methods (e.g.,
addProduct
and
getProduct
) that can be remotely invoked. Each method has input
parameters and return types that we define as either part of the service or
that can be imported into the protocol buffer definition.
The input and return parameters can be a user-defined type (e.g.,
Product
and
ProductID
types) or a protocol buffer well-known type defined in the
service definition. Those types are structured as messages, where each
message is a small logical record of information containing a series of
name-value pairs called fields. These fields are name-value pairs with
unique field numbers (e.g.,
string id = 1
) that are used to identify your
fields in the message binary format.
This service definition is used to build the server and client side of your
gRPC application. In the next section, we’ll go into the details of gRPC
server implementation.
gRPC Server
Once you have a service definition in place, you can use it to generate the
server- or client-side code using the protocol buffer compiler protoc. With
the gRPC plug-in for protocol buffers, you can generate gRPC server-side
and client-side code, as well as the regular protocol buffer code for
populating, serializing, and retrieving your message types.
On the server side, the server implements that service definition and runs a
gRPC server to handle client calls. Therefore, on the server side, to make
the
ProductInfo
service do its job you need to do the following:
1. Implement the service logic of the generated service skeleton by
overriding the service base class.
2. Run a gRPC server to listen for requests from clients and return the
service responses.
When implementing service logic, the first thing to do is generate the
service skeleton from the service definition. For example, in the code
snippet in Example 1-2, you can find the generated remote functions for the
ProductInfo
service built with Go. Inside the body of these remote
functions you can implement the logic of each function.
Example 1-2. gRPC server-side implementation of ProductInfo service with
Go
import (
...
"context"
pb "github.com/grpc-up-and-running/samples/ch02/productinfo/go/proto"
"google.golang.org/grpc"
...
)
// ProductInfo implementation with Go
// Add product remote method
func (s *server) AddProduct(ctx context.Context, in *pb.Product) (
*pb.ProductID, error) {
// business logic
}
// Get product remote method
func (s *server) GetProduct(ctx context.Context, in *pb.ProductID) (
*pb.Product, error) {
// business logic
}
Once you have the service implementation ready, you need to run a gRPC
server to listen for requests from clients, dispatch those requests to the
service implementation, and return the service responses back to the client.
The code snippet in Example 1-3 shows a gRPC server implementation
with Go for the
ProductInfo
service use case. Here we open up a TCP
port, start the gRPC server, and register the
ProductInfo
service with that
server.
Example 1-3. Running a gRPC server for ProductInfo service with Go
func main() {
lis, _ := net.Listen("tcp", port)
s := grpc.NewServer()
pb.RegisterProductInfoServer(s, &server{})
if err := s.Serve(lis); err != nil {
log.Fatalf("failed to serve: %v", err)
}
}
That’s all you have to do on the server side. Let’s move on to the gRPC
client-side implementation.
gRPC Client
Similar to the server side, we can generate the client-side stub using the
service definition. The client stub provides the same methods as the server,
which your client code can invoke; the client stub translates them to remote
function invocation network calls that go to the server side. Since gRPC
service definitions are language-agnostic, you can generate clients and
servers for any supported language (via the third-party implementations) of
your choice. So for the
ProductInfo
service use case, we can generate the
client stub for Java while our server side is implemented with Go. In the
code snippet in Example 1-4, you find the code for Java. Despite the
programming language we use, the simple steps involved in a client-side
implementation involve setting up a connection with the remote server,
attaching the client stub with that connection, and invoking the remote
method using the client stub.
Example 1-4. gRPC client to invoke a remote method of service
// Create a channel using remote server address
ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 8080)
.usePlaintext(true)
.build();
// Initialize blocking stub using the channel
ProductInfoGrpc.ProductInfoBlockingStub stub =
ProductInfoGrpc.newBlockingStub(channel);
// Call remote method using the blocking stub
StringValue productID = stub.addProduct(
Product.newBuilder()
.setName("Apple iPhone 11")
.setDescription("Meet Apple iPhone 11." +
"All-new dual-camera system with " +
"Ultra Wide and Night mode.")
.build());
As you now have a good sense of the key concepts of gRPC, let’s try to
understand the gRPC client–server message flow in detail.
Client–Server Message Flow
When a gRPC client invokes a gRPC service, the client-side gRPC library
uses the protocol buffer and marshals the remote procedure call protocol
buffer format, which is then sent over HTTP/2. On the server side, the
request is unmarshaled and the respective procedure invocation is executed
using protocol buffers. The response follows a similar execution flow from
the server to the client. As the wire transport protocol, gRPC uses HTTP/2,
which is a high-performance binary message protocol with support for
bidirectional messaging. We will further discuss the low-level details of the
message flow between gRPC clients and servers along with protocol buffers
and how gRPC uses HTTP/2 in Chapter 4.
NOTE
Marshaling is the process of packing parameters and a remote function into a message
packet that is sent over the network, while unmarshaling unpacks the message packet
into the respective method invocation.
剩余256页未读,继续阅读
溺水的鱼
- 粉丝: 950
- 资源: 436
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- zigbee-cluster-library-specification
- JSBSim Reference Manual
- c++校园超市商品信息管理系统课程设计说明书(含源代码) (2).pdf
- 建筑供配电系统相关课件.pptx
- 企业管理规章制度及管理模式.doc
- vb打开摄像头.doc
- 云计算-可信计算中认证协议改进方案.pdf
- [详细完整版]单片机编程4.ppt
- c语言常用算法.pdf
- c++经典程序代码大全.pdf
- 单片机数字时钟资料.doc
- 11项目管理前沿1.0.pptx
- 基于ssm的“魅力”繁峙宣传网站的设计与实现论文.doc
- 智慧交通综合解决方案.pptx
- 建筑防潮设计-PowerPointPresentati.pptx
- SPC统计过程控制程序.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0