Grpc on

「连载十」分布式链路追踪 gRPC + Opentracing + Zipkin

Sat, 20 Oct 2018 12:00:00 +0000

在实际应用中，你做了那么多 Server 端，写了 N 个 RPC 方法。想看看方法的指标，却无处下手？

本文将通过 gRPC + Opentracing + Zipkin 搭建一个分布式链路追踪系统来实现查看整个系统的链路、性能等指标。

Opentracing

是什么

OpenTracing 通过提供平台无关、厂商无关的API，使得开发人员能够方便的添加（或更换）追踪系统的实现

不过 OpenTracing 并不是标准。因为 CNCF 不是官方标准机构，但是它的目标是致力为分布式追踪创建更标准的 API 和工具

名词解释

Trace

一个 trace 代表了一个事务或者流程在（分布式）系统中的执行过程

Span

一个 span 代表在分布式系统中完成的单个工作单元。也包含其他 span 的 “引用”，这允许将多个 spans 组合成一个完整的 Trace

每个 span 根据 OpenTracing 规范封装以下内容：

操作名称
开始时间和结束时间
key:value span Tags
key:value span Logs
SpanContext

Logs

Span logs（跨度日志）可以记录 Span 内特定时间或事件的日志信息。主要用于捕获特定 Span 的日志信息以及应用程序本身的其他调试或信息输出

SpanContext

SpanContext 代表跨越进程边界，传递到子级 Span 的状态。常在追踪示意图中创建上下文时使用

「连载九」gRPC Deadlines

Tue, 16 Oct 2018 12:00:00 +0000

前言

在前面的章节中，已经介绍了 gRPC 的基本用法。那你想想，让它这么裸跑真的没问题吗？

那么，肯定是有问题了。今天将介绍 gRPC Deadlines 的用法，这一个必备技巧。内容也比较简单

Deadlines

Deadlines 意指截止时间，在 gRPC 中强调 TL;DR（Too long, Don’t read）并建议始终设定截止日期，为什么呢？

为什么要设置

当未设置 Deadlines 时，将采用默认的 DEADLINE_EXCEEDED（这个时间非常大）

如果产生了阻塞等待，就会造成大量正在进行的请求都会被保留，并且所有请求都有可能达到最大超时

这会使服务面临资源耗尽的风险，例如内存，这会增加服务的延迟，或者在最坏的情况下可能导致整个进程崩溃

gRPC

Client

func main() {
    ...
	ctx, cancel := context.WithDeadline(context.Background(), time.Now().Add(time.Duration(5 * time.Second)))
	defer cancel()

	client := pb.NewSearchServiceClient(conn)
	resp, err := client.Search(ctx, &pb.SearchRequest{
		Request: "gRPC",
	})
	if err != nil {
		statusErr, ok := status.FromError(err)
		if ok {
			if statusErr.Code() == codes.DeadlineExceeded {
				log.Fatalln("client.Search err: deadline")
			}
		}

		log.Fatalf("client.Search err: %v", err)
	}

	log.Printf("resp: %s", resp.GetResponse())
}

context.WithDeadline：会返回最终上下文截止时间。第一个形参为父上下文，第二个形参为调整的截止时间。若父级时间早于子级时间，则以父级时间为准，否则以子级时间为最终截止时间

func WithDeadline(parent Context, d time.Time) (Context, CancelFunc) {
	if cur, ok := parent.Deadline(); ok && cur.Before(d) {
		// The current deadline is already sooner than the new one.
		return WithCancel(parent)
	}
	c := &timerCtx{
		cancelCtx: newCancelCtx(parent),
		deadline:  d,
	}
	propagateCancel(parent, c)
	dur := time.Until(d)
	if dur <= 0 {
		c.cancel(true, DeadlineExceeded) // deadline has already passed
		return c, func() { c.cancel(true, Canceled) }
	}
	c.mu.Lock()
	defer c.mu.Unlock()
	if c.err == nil {
		c.timer = time.AfterFunc(dur, func() {
			c.cancel(true, DeadlineExceeded)
		})
	}
	return c, func() { c.cancel(true, Canceled) }
}

context.WithTimeout：很常见的另外一个方法，是便捷操作。实际上是对于 WithDeadline 的封装

func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) {
	return WithDeadline(parent, time.Now().Add(timeout))
}

status.FromError：返回 GRPCStatus 的具体错误码，若为非法，则直接返回 codes.Unknown

Server

type SearchService struct{}

func (s *SearchService) Search(ctx context.Context, r *pb.SearchRequest) (*pb.SearchResponse, error) {
	for i := 0; i < 5; i++  {
		if ctx.Err() == context.Canceled {
			return nil, status.Errorf(codes.Canceled, "SearchService.Search canceled")
		}

		time.Sleep(1 * time.Second)
	}

	return &pb.SearchResponse{Response: r.GetRequest() + " Server"}, nil
}

func main() {
	...
}

而在 Server 端，由于 Client 已经设置了截止时间。Server 势必要去检测它

「连载八」对 RPC 方法做自定义认证

Sun, 14 Oct 2018 12:00:00 +0000

前言

在前面的章节中，我们介绍了两种（证书算一种）可全局认证的方法：

而在实际需求中，常常会对某些模块的 RPC 方法做特殊认证或校验。今天将会讲解、实现这块的功能点

课前知识

type PerRPCCredentials interface {
    GetRequestMetadata(ctx context.Context, uri ...string) (map[string]string, error)
    RequireTransportSecurity() bool
}

在 gRPC 中默认定义了 PerRPCCredentials，它就是本章节的主角，是 gRPC 默认提供用于自定义认证的接口，它的作用是将所需的安全认证信息添加到每个 RPC 方法的上下文中。其包含 2 个方法：

GetRequestMetadata：获取当前请求认证所需的元数据（metadata）
RequireTransportSecurity：是否需要基于 TLS 认证进行安全传输

目录结构

新建 simple_token_server/server.go 和 simple_token_client/client.go，目录结构如下：

go-grpc-example
├── client
│   ├── simple_client
│   ├── simple_http_client
│   ├── simple_token_client
│   └── stream_client
├── conf
├── pkg
├── proto
├── server
│   ├── simple_http_server
│   ├── simple_server
│   ├── simple_token_server
│   └── stream_server
└── vendor

gRPC

Client

package main

import (
	"context"
	"log"

	"google.golang.org/grpc"

	"github.com/EDDYCJY/go-grpc-example/pkg/gtls"
	pb "github.com/EDDYCJY/go-grpc-example/proto"
)

const PORT = "9004"

type Auth struct {
	AppKey    string
	AppSecret string
}

func (a *Auth) GetRequestMetadata(ctx context.Context, uri ...string) (map[string]string, error) {
	return map[string]string{"app_key": a.AppKey, "app_secret": a.AppSecret}, nil
}

func (a *Auth) RequireTransportSecurity() bool {
	return true
}

func main() {
	tlsClient := gtls.Client{
		ServerName: "go-grpc-example",
		CertFile:   "../../conf/server/server.pem",
	}
	c, err := tlsClient.GetTLSCredentials()
	if err != nil {
		log.Fatalf("tlsClient.GetTLSCredentials err: %v", err)
	}

	auth := Auth{
		AppKey:    "eddycjy",
		AppSecret: "20181005",
	}
	conn, err := grpc.Dial(":"+PORT, grpc.WithTransportCredentials(c), grpc.WithPerRPCCredentials(&auth))
	...
}

在 Client 端，重点实现 type PerRPCCredentials interface 所需的方法，关注两点即可：

「连载七」让你的服务同时提供 HTTP 接口

Fri, 12 Oct 2018 12:00:00 +0000

前言

接口需要提供给其他业务组访问，但是 RPC 协议不同无法内调，对方问能否走 HTTP 接口，怎么办？
微信（公众号、小程序）等第三方回调接口只支持 HTTP 接口，怎么办

我相信你在实际工作中都会遇到如上问题，在 gRPC 中都是有解决方案的，本章节将会进行介绍 🤔

为什么可以同时提供 HTTP 接口

关键一点，gRPC 的协议是基于 HTTP/2 的，因此应用程序能够在单个 TCP 端口上提供 HTTP/1.1 和 gRPC 接口服务（两种不同的流量）

怎么同时提供 HTTP 接口

检测协议

if r.ProtoMajor == 2 && strings.Contains(r.Header.Get("Content-Type"), "application/grpc") {
    server.ServeHTTP(w, r)
} else {
    mux.ServeHTTP(w, r)
}

流程

检测请求协议是否为 HTTP/2
判断 Content-Type 是否为 application/grpc（gRPC 的默认标识位）
根据协议的不同转发到不同的服务处理

gRPC

TLS

在前面的章节，为了便于展示因此没有简单封装

在本节需复用代码，重新封装了，可详见：go-grpc-example

目录结构

新建 simple_http_client、simple_http_server 目录，目录结构如下：

go-grpc-example
├── client
│   ├── simple_client
│   ├── simple_http_client
│   └── stream_client
├── conf
├── pkg
│   └── gtls
├── proto
├── server
│   ├── simple_http_server
│   ├── simple_server
│   └── stream_server

Server

在 simple_http_server 目录下新建 server.go，写入文件内容：

「连载六」Unary and Stream interceptor

Wed, 10 Oct 2018 12:00:00 +0000

前言

我想在每个 RPC 方法的前或后做某些事情，怎么做？

本章节将要介绍的拦截器（interceptor），就能帮你在合适的地方实现这些功能。

有几种方法

在 gRPC 中，大类可分为两种 RPC 方法，与拦截器的对应关系是：

普通方法：一元拦截器（grpc.UnaryInterceptor）
流方法：流拦截器（grpc.StreamInterceptor）

看一看

grpc.UnaryInterceptor

func UnaryInterceptor(i UnaryServerInterceptor) ServerOption {
	return func(o *options) {
		if o.unaryInt != nil {
			panic("The unary server interceptor was already set and may not be reset.")
		}
		o.unaryInt = i
	}
}

函数原型：

type UnaryServerInterceptor func(ctx context.Context, req interface{}, info *UnaryServerInfo, handler UnaryHandler) (resp interface{}, err error)

通过查看源码可得知，要完成一个拦截器需要实现 UnaryServerInterceptor 方法。形参如下：

ctx context.Context：请求上下文
req interface{}：RPC 方法的请求参数
info *UnaryServerInfo：RPC 方法的所有信息
handler UnaryHandler：RPC 方法本身

grpc.StreamInterceptor

func StreamInterceptor(i StreamServerInterceptor) ServerOption

函数原型：

「连载五」基于 CA 的 TLS 证书认证

Mon, 08 Oct 2018 12:00:00 +0000

前言

在上一章节中，我们提出了一个问题。就是如何保证证书的可靠性和有效性？你如何确定你 Server、Client 的证书是对的呢？

CA

为了保证证书的可靠性和有效性，在这里可引入 CA 颁发的根证书的概念。其遵守 X.509 标准

根证书

根证书（root certificate）是属于根证书颁发机构（CA）的公钥证书。我们可以通过验证 CA 的签名从而信任 CA ，任何人都可以得到 CA 的证书（含公钥），用以验证它所签发的证书（客户端、服务端）

它包含的文件如下：

公钥
密钥

生成 Key

openssl genrsa -out ca.key 2048

生成密钥

openssl req -new -x509 -days 7200 -key ca.key -out ca.pem

填写信息

Country Name (2 letter code) []:
State or Province Name (full name) []:
Locality Name (eg, city) []:
Organization Name (eg, company) []:
Organizational Unit Name (eg, section) []:
Common Name (eg, fully qualified host name) []:go-grpc-example
Email Address []:

Server

生成 CSR

openssl req -new -key server.key -out server.csr

填写信息

Country Name (2 letter code) []:
State or Province Name (full name) []:
Locality Name (eg, city) []:
Organization Name (eg, company) []:
Organizational Unit Name (eg, section) []:
Common Name (eg, fully qualified host name) []:go-grpc-example
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:

CSR 是 Cerificate Signing Request 的英文缩写，为证书请求文件。主要作用是 CA 会利用 CSR 文件进行签名使得攻击者无法伪装或篡改原有证书

「连载四」TLS 证书认证

Sun, 07 Oct 2018 12:00:00 +0000

前言

在前面的章节里，我们介绍了 gRPC 的四种 API 使用方式。是不是很简单呢 😀

此时存在一个安全问题，先前的例子中 gRPC Client/Server 都是明文传输的，会不会有被窃听的风险呢？

从结论上来讲，是有的。在明文通讯的情况下，你的请求就是裸奔的，有可能被第三方恶意篡改或者伪造为“非法”的数据

抓个包

嗯，明文传输无误。这是有问题的，接下将改造我们的 gRPC，以便于解决这个问题 😤

证书生成

私钥

openssl ecparam -genkey -name secp384r1 -out server.key

自签公钥

openssl req -new -x509 -sha256 -key server.key -out server.pem -days 3650

填写信息

Country Name (2 letter code) []:
State or Province Name (full name) []:
Locality Name (eg, city) []:
Organization Name (eg, company) []:
Organizational Unit Name (eg, section) []:
Common Name (eg, fully qualified host name) []:go-grpc-example
Email Address []:

生成完毕

生成证书结束后，将证书相关文件放到 conf/ 下，目录结构：

「连载三」gRPC Streaming, Client and Server

Mon, 24 Sep 2018 12:00:00 +0000

前言

本章节将介绍 gRPC 的流式，分为三种类型：

Server-side streaming RPC：服务器端流式 RPC
Client-side streaming RPC：客户端流式 RPC
Bidirectional streaming RPC：双向流式 RPC

流

任何技术，因为有痛点，所以才有了存在的必要性。如果您想要了解 gRPC 的流式调用，请继续

图

gRPC Streaming 是基于 HTTP/2 的，后续章节再进行详细讲解

为什么不用 Simple RPC

流式为什么要存在呢，是 Simple RPC 有什么问题吗？通过模拟业务场景，可得知在使用 Simple RPC 时，有如下问题：

数据包过大造成的瞬时压力
接收数据包时，需要所有数据包都接受成功且正确后，才能够回调响应，进行业务处理（无法客户端边发送，服务端边处理）

为什么用 Streaming RPC

大规模数据包
实时场景

模拟场景

每天早上 6 点，都有一批百万级别的数据集要同从 A 同步到 B，在同步的时候，会做一系列操作（归档、数据分析、画像、日志等）。这一次性涉及的数据量确实大

在同步完成后，也有人马上会去查阅数据，为了新的一天筹备。也符合实时性。

两者相较下，这个场景下更适合使用 Streaming RPC

gRPC

在讲解具体的 gRPC 流式代码时，会着重在第一节讲解，因为三种模式其实是不同的组合。希望你能够注重理解，举一反三，其实都是一样的知识点 👍

目录结构

$ tree go-grpc-example
go-grpc-example
├── client
│   ├── simple_client
│   │   └── client.go
│   └── stream_client
│       └── client.go
├── proto
│   ├── search.proto
│   └── stream.proto
└── server
    ├── simple_server
    │   └── server.go
    └── stream_server
        └── server.go

增加 stream_server、stream_client 存放服务端和客户端文件，proto/stream.proto 用于编写 IDL

「连载二」gRPC Client and Server

Sun, 23 Sep 2018 12:30:00 +0000

前言

本章节将使用 Go 来编写 gRPC Server 和 Client，让其互相通讯。在此之上会使用到如下库：

google.golang.org/grpc
github.com/golang/protobuf/protoc-gen-go

安装

gRPC

go get -u google.golang.org/grpc

Protocol Buffers v3

wget https://github.com/google/protobuf/releases/download/v3.5.1/protobuf-all-3.5.1.zip
unzip protobuf-all-3.5.1.zip
cd protobuf-3.5.1/
./configure
make
make install

检查是否安装成功

protoc --version

若出现以下错误，执行 ldconfig 命名就能解决这问题

protoc: error while loading shared libraries: libprotobuf.so.15: cannot open shared object file: No such file or directory

Protoc Plugin

go get -u github.com/golang/protobuf/protoc-gen-go

安装环境若有问题，可参考我先前的文章《介绍与环境安装》内有详细介绍，不再赘述

gRPC

本小节开始正式编写 gRPC 相关的程序，一起上车吧 😄

图示

目录结构

$ tree go-grpc-example
go-grpc-example
├── client
├── proto
│   └── search.proto
└── server.go

IDL

编写

在 proto 文件夹下的 search.proto 文件中，写入如下内容：

「连载一」gRPC及相关介绍

Sat, 22 Sep 2018 12:00:00 +0000

项目地址：https://github.com/EDDYCJY/go-grpc-example

作为开篇章，将会介绍 gRPC 相关的一些知识。简单来讲 gRPC 是一个基于 HTTP/2 协议设计的 RPC 框架，它采用了 Protobuf 作为 IDL

你是否有过疑惑，它们都是些什么？本文将会介绍一些常用的知识和概念，更详细的会给出手册地址去深入

一、RPC

什么是 RPC

RPC 代指远程过程调用（Remote Procedure Call），它的调用包含了传输协议和编码（对象序列号）协议等等。允许运行于一台计算机的程序调用另一台计算机的子程序，而开发人员无需额外地为这个交互作用编程

实际场景：

有两台服务器，分别是 A、B。在 A 上的应用 C 想要调用 B 服务器上的应用 D，它们可以直接本地调用吗？
答案是不能的，但走 RPC 的话，十分方便。因此常有人称使用 RPC，就跟本地调用一个函数一样简单

RPC 框架

我认为，一个完整的 RPC 框架，应包含负载均衡、服务注册和发现、服务治理等功能，并具有可拓展性便于流量监控系统等接入
那么它才算完整的，当然了。有些较单一的 RPC 框架，通过组合多组件也能达到这个标准

你认为呢？

常见 RPC 框架

比较一下

\	跨语言	多 IDL	服务治理	注册中心	服务管理
gRPC	√	×	×	×	×
Thrift	√	×	×	×	×
Rpcx	×	√	√	√	√
Dubbo	×	√	√	√	√

为什么要 RPC

简单、通用、安全、效率

Grpc on

「连载十」分布式链路追踪 gRPC + Opentracing + Zipkin

Opentracing

是什么

名词解释

Trace

Span

Tags

Logs

SpanContext

「连载九」gRPC Deadlines

前言

Deadlines

为什么要设置

gRPC

Client

Server

「连载八」对 RPC 方法做自定义认证

前言

课前知识

目录结构

gRPC

Client

「连载七」让你的服务同时提供 HTTP 接口

前言

为什么可以同时提供 HTTP 接口

怎么同时提供 HTTP 接口

检测协议

流程

gRPC

TLS

目录结构

Server

「连载六」Unary and Stream interceptor

前言

有几种方法

看一看

grpc.UnaryInterceptor

grpc.StreamInterceptor

「连载五」基于 CA 的 TLS 证书认证

前言

CA

根证书

生成 Key

生成密钥

填写信息

Server

生成 CSR

填写信息

「连载四」TLS 证书认证

前言

抓个包

证书生成

私钥

自签公钥

填写信息

生成完毕

「连载三」gRPC Streaming, Client and Server

前言

流

图

为什么不用 Simple RPC

为什么用 Streaming RPC

模拟场景

gRPC

目录结构

「连载二」gRPC Client and Server

前言

安装

gRPC

Protocol Buffers v3

Protoc Plugin

gRPC

图示

目录结构

IDL

编写

「连载一」gRPC及相关介绍

一、RPC

什么是 RPC