Go语言缺乏好用的动态加载代码的机制，Go程序通常是单个自包含的二进制文件，因此难以实现类似于Java那样的插件系统。

这种插件直接编译到二进制文件中。典型的例子是database/sql包中的数据库驱动。这种插件都是通过空白导入：

package main
import _ "name"

的方式激活，插件包的init方法负责插件的注册和初始化。这类插件的缺点包括：

1. 违反开闭原则，引入插件必须修改依赖它的程序

对于编译型（直接编译为本地代码，不是JVM那样的虚拟机的代码）语言，都可以调用共享库。Go语言也不例外，其内置的plugin包，就是基于共享库实现插件化。plugin包有一些致命的缺点：

1. 限制条件非常苛刻，对于主程序、插件共同使用的包，有任何修改，你都必须重新编译主程序和插件。否则会得到报错：plugin was built with a different version of package
2. 主程序和插件的编译器、编译标记也必须一致
3. 对操作系统的支持不完善，不支持Windows  

hashicorp / go-plugin是一个通过RPC实现的Go插件系统，在Packer、Terraform, Nomad、Vault等由HashiCorp主导的项目中均由应用。go-plugin允许应用程序通过本地网络（本机）的gRPC调用插件，规避了Go无法动态加载代码的缺点。

go-plugin插件由宿主进程调用，宿主进程会以插件二进制文件为映像创建子进程，并且通过单个网络连接与之通信。网络协议可以是：

1. net/rpc：这种情况下go-plugin使用yamux库对连接进行多路复用
2. gRPC：这种情况下基于HTTP2协议进行多路复用

go-plugin的特性包括：

1. 插件是Go接口的实现：这让插件的编写、使用非常自然。对于插件的作者来说，他只需要实现一个Go接口即可；对于插件的用户来说，他只需要调用一个Go接口即可。go-plugin会处理好本地调用转换为gRPC调用的所有细节
2. 跨语言支持：插件可以基于任何主流语言编写，同样可以被任何主流语言消费
3. 支持复杂的参数、返回值：go-plugin可以处理接口、io.Reader/Writer等复杂类型
4. 双向通信：为了支持复杂参数，宿主进程能够将接口实现发送给插件，插件也能够回调到宿主进程
5. 内置日志系统：任何使用log标准库的的插件，都会将日志信息传回宿主机进程。宿主进程会在这些日志前面加上插件二进制文件的路径，并且打印日志
6. 协议版本化：支持一个简单的协议版本化，增加版本号后可以基于老版本协议的插件无效化。当接口签名变化时应当增加版本
7. 标准输出/错误同步：插件以子进程的方式运行，这些子进程可以自由的使用标准输出/错误，并且打印的内容会被自动同步到宿主进程，宿主进程可以为同步的日志指定一个io.Writer
8. TTY Preservation：插件子进程可以链接到宿主进程的stdin文件描述符，以便要求TTY的软件能正常工作
9. 宿主进程升级：宿主进程升级的时候，插件子进程可以继续允许，并在升级后自动关联到新的宿主进程
10. 加密通信：gRPC信道可以加密
11. 完整性校验：支持对插件的二进制文件进行Checksum
12. 插件崩溃了，不会导致宿主进程崩溃
13. 容易安装：只需要将插件放到某个宿主进程能够访问的目录即可

插件接口是宿主进程、插件进程进行通信的桥梁：

1. 宿主进程会将插件接口的实现放到自己的插件集中
2. 插件进程会将插件接口的实现放到自己的插件集中，并为每个插件指定业务接口的实现。一个插件可以实现多个业务接口
3. 宿主进程可以：
   1. 主动创建插件进程，从而得到插件进程的监听套接字
   2. 关联到既有插件进程，需要手工提供插件进程的监听套接字
4. 宿主进程会调用Client方法，获得插件客户端
5. 插件进程会调用Server方法，创建插件服务器端，并且将请求委托给业务接口的实现
6. 宿主进程通过plugin.Client，可以获得业务接口的Stub，调用业务接口的方法会自动转换为RPC远程调用
7. 插件进程上的UDS套接字监听到调用后，会解析RPC请求，并（Lazy的）分发（Dispense）给对应的业务接口Impl

架构示意如下：

接口

Plugin

type Plugin interface {
	// 返回一个RPC服务器兼容的结构，提供客户端可以通过net/rpc调用的方法
	Server(*MuxBroker) (interface{}, error)

	// 返回一个RPC客户端
	Client(*MuxBroker, *rpc.Client) (interface{}, error)
}

这个接口类似，只是通信方式基于gRPC：

type GRPCPlugin interface {
	// 由于gRPC插件以单例方式服务，因此该方法仅调用一次
	GRPCServer(*GRPCBroker, *grpc.Server) error

	// 插件进程退出时，context会被go-plugin关闭
	GRPCClient(context.Context, *GRPCBroker, *grpc.ClientConn) (interface{}, error)
}

这个结构负责管理一个插件应用（进程）的完整生命周期，包括创建插件进程、连接到插件进程、Dispense业务接口的实现、最后杀死进程。

对于每个插件（二进制文件），宿主进程需要创建一个plugin.Client实例。

该结构的字段如下：

type Client struct {
	// 插件客户端配置
	config            *ClientConfig
	// 插件进程是否已经退出
	exited            bool
	l                 sync.Mutex
	// 插件进程的RPC监听地址
	address           net.Addr
	// 插件进程对象
	process           *os.Process
	// 协议客户端，宿主进程需要调用其Dispense方法来获得业务接口的Stub
	client            ClientProtocol
	// 通信协议
	protocol          Protocol
	logger            hclog.Logger
	doneCtx           context.Context
	ctxCancel         context.CancelFunc
	negotiatedVersion int

	// 用于管理 插件管理协程的生命周期
	clientWaitGroup sync.WaitGroup

	stderrWaitGroup sync.WaitGroup

	//  测试用，标记进程是否被强杀
	processKilled bool
}

包含初始化一个插件客户端所需的配置信息，一旦初始化客户端，即不可修改：

type ClientConfig struct {
	// 握手信息，用于宿主、插件的匹配。如果不匹配，插件会拒绝连接
	HandshakeConfig

	// 可以调用的插件列表
	Plugins PluginSet

	// 版本化的插件列表，用于支持在客户端、服务器之间协商兼容版本
	VersionedPlugins map[int]PluginSet

	// 启动插件进程使用的命令行，不能和Reattach联用
	Cmd      *exec.Cmd
	// 连接到既有插件进程的必要信息，不能和Cmd联用
	Reattach *ReattachConfig

	// 用于在启动插件时校验二进制文件的完整性
	SecureConfig *SecureConfig

	// 基于TLS进行RPC通信时需要的信息
	TLSConfig *tls.Config

	// 客户端是否应该被plugin包自动管理
	// 如果为true，则调用CleanupClients自动清理
	// 否则用户需要负责杀掉插件客户端，默认false
	Managed bool

	// 和子进程通信使用的端口范围
	MinPort, MaxPort uint

	// 启动插件的超时
	StartTimeout time.Duration

	Stderr io.Writer
	SyncStdout io.Writer
	SyncStderr io.Writer

	// 支持的协议，如果不指定仅仅支持netrpc
	AllowedProtocols []Protocol

	// 不指定则为hclog的默认logger
	Logger hclog.Logger

	AutoMTLS bool
}

插件主函数的结尾，必须调用此函数来启动监听，需要传入一个ServeConfig。

type ServeConfig struct {
	// 和客户端匹配的握手配置
	HandshakeConfig

	// 调用此函数得到tls.Config
	TLSProvider func() (*tls.Config, error)

	// 插件集
	Plugins PluginSet

	// 版本化的插件集
	VersionedPlugins map[int]PluginSet

	// 如果通过gRPC提供服务，则此字段不能为空
	// 调用此函数创建一个gRPC服务器对象
	GRPCServer func([]grpc.ServerOption) *grpc.Server

	Logger hclog.Logger
} 

ClientConfig、ServerConfig都会嵌入此结构，此结构用于宿主、插件建立连接前的握手。

宿主进程创建插件进程时，会将此信息通过环境变量传递。这样插件进程能够正常启动。如果没有这些环境变量，则插件进程会退出，并提示你插件必须由宿主进程启动。

type HandshakeConfig struct {
	// 协议版本号
	ProtocolVersion uint

	// 用于简单的校验插件进程是否人为手工启动的
	MagicCookieKey   string
	MagicCookieValue string
}

基于net/rpc的通信方式目前仅仅用于向后兼容，任何新开发的代码都应该考虑使用gRPC方式。

很简单，返回一个问候信息：

type Greeter interface {
	Greet() string
}

需要提供一个基于net/rpc的实现：

import "net/rpc"

// Here is an implementation that talks over RPC
type GreeterRPC struct{ client *rpc.Client }

func (g *GreeterRPC) Greet() string {
	var resp string
	err := g.client.Call("Plugin.Greet", new(interface{}), &resp)
	if err != nil {
		panic(err)
	}

	return resp
}

此结构实现plugin.Plugin接口：

type GreeterPlugin struct {
	// 内嵌业务接口，插件进程会设置此自动，宿主进程则置空
	Impl Greeter
}

// 此方法由插件进程Lazy的调用
func (p *GreeterPlugin) Server(*plugin.MuxBroker) (interface{}, error) {
	return &GreeterRPCServer{Impl: p.Impl}, nil
}

// 此方法由宿主进程调用
func (GreeterPlugin) Client(b *plugin.MuxBroker, c *rpc.Client) (interface{}, error) {
	return &GreeterRPC{client: c}, nil
}

// 这是net/rpc所需要的RPC服务器对象
type GreeterRPCServer struct {
	// This is the real implementation
	Impl Greeter
}
func (s *GreeterRPCServer) Greet(args interface{}, resp *string) error {
	*resp = s.Impl.Greet()
	return nil
}

即插件客户端：

package main

import (
	"fmt"
	"github.com/hashicorp/go-hclog"
	"github.com/hashicorp/go-plugin"
	"github.com/hashicorp/go-plugin/examples/basic/commons"
	"log"
	"net"
	"os"
)

func main() {
	logger := hclog.New(&hclog.LoggerOptions{
		Name:   "plugin",
		Output: os.Stdout,
		Level:  hclog.Debug,
	})

	// 宿主机调用plugin.NewClient，创建或连接到插件进程
	client := plugin.NewClient(&plugin.ClientConfig{
		HandshakeConfig: handshakeConfig,
		Plugins: map[string]plugin.Plugin{
			// 插件名字到插件的映射关系
			"greeter": &example.GreeterPlugin{},
		},
		// 创建新进程
		Cmd:             exec.Command("./plugin/greeter"),
		// 连接到现有进程
		Reattach: &plugin.ReattachConfig{
			Pid: 2802223,
			Addr: &net.UnixAddr{
				Net:  "unix",
				Name: "/tmp/plugin137476534",
			},
		},
		Logger: logger,
	})
	// 此调用会终止插件子进程的执行，并且进行必要的清理工作（例如收集日志）
	defer client.Kill()

	// 获取RPC客户端对象
	rpcClient, err := client.Client()
	if err != nil {
		log.Fatal(err)
	}

	// 产生具有指定名字的插件的实例
	raw, err := rpcClient.Dispense("greeter")
	if err != nil {
		log.Fatal(err)
	}

	// 插件实例可以强制转型为业务接口
	greeter := raw.(example.Greeter)
	// 像调用本地函数一样调用远程插件，客户端本身是线程安全的，你可以并发的调用业务接口
	fmt.Println(greeter.Greet())
}

// 用于插件和宿主之间的简单握手，用于提升用户体验（而非安全特性）
// 如果握手失败，则提示一个友好的信息
// 可以防止：1、执行错误的插件；2、用户手工启动插件
var handshakeConfig = plugin.HandshakeConfig{
	ProtocolVersion:  1,
	MagicCookieKey:   "BASIC_PLUGIN",
	MagicCookieValue: "hello",
}

不管是插件客户端还是服务器，都需要（在ClientConfig/ServeConfig中）指定一个一个PluginSet，列出支持的插件。对于服务器，必须指定每个插件的Impl。

package main

import (
	"os"

	"github.com/hashicorp/go-hclog"
	"github.com/hashicorp/go-plugin"
	"github.com/hashicorp/go-plugin/examples/basic/commons"
)

// 业务接口的真实实现
type GreeterHello struct {
	logger hclog.Logger
}

func (g *GreeterHello) Greet() string {
	g.logger.Debug("message from GreeterHello.Greet")
	return "Hello!"
}

// 握手配置
var handshakeConfig = plugin.HandshakeConfig{
	ProtocolVersion:  1,
	MagicCookieKey:   "BASIC_PLUGIN",
	MagicCookieValue: "hello",
}

func main() {
	logger := hclog.New(&hclog.LoggerOptions{
		Level:      hclog.Trace,
		Output:     os.Stderr,
		JSONFormat: true,
	})

	greeter := &GreeterHello{
		logger: logger,
	}
	// 插件集类似于宿主进程，只是插件需要指定Impl字段
	var pluginMap = map[string]plugin.Plugin{
		"greeter": &example.GreeterPlugin{Impl: greeter},
	}

	logger.Debug("message from plugin", "foo", "bar")

	// 启动RPC监听
	plugin.Serve(&plugin.ServeConfig{
		HandshakeConfig: handshakeConfig,
		Plugins:         pluginMap,
	})
}

服务器调用plugin.Serve方法后，主线程即阻塞。直到客户端调用

Dispense

func (d *dispenseServer) Dispense(
	name string, response *uint32) error {
	// 从PluginSet中查找
	p, ok := d.plugins[name]
	if !ok {
		return fmt.Errorf("unknown plugin type: %s", name)
	}

	// 调用（下面的那个函数）插件接口的方法
	impl, err := p.Server(d.broker)
	if err != nil {
		return errors.New(err.Error())
	}

	// MuxBroker基于唯一性的ID进行TCP连接的多路复用
	id := d.broker.NextId()
	*response = id

	// 在另外一个协程中处理该请求
	go func() {
		conn, err := d.broker.Accept(id)
		if err != nil {
			log.Printf("[ERR] go-plugin: plugin dispense error: %s: %s", name, err)
			return
		}

		serve(conn, "Plugin", impl)
	}()

	return nil
}

func (p *GreeterPlugin) Server(*plugin.MuxBroker) (interface{}, error) {
	return &GreeterRPCServer{Impl: p.Impl}, nil
}

应当尽量使用grpc而非net/rpc，原因如下：

1. gRPC支持多种语言来实现插件，而net/rpc是Go专有的
2. 在gRPC模式下，go-plugin插件请求通过HTTP2发送，而非私有的yamux
3. net/rpc使用go类型，尽管比较方便，但却存在潜在的兼容性问题

此外需要注意，对于gRPC模式来说，插件进程中只会有单个插件“实例”。对于net/rpc你可能创建多个“实例”。

使用gRPC模式时，你需要：

1. 通过Proto文件定义语言中立的接口
2. 从Proto生成gRPC客户端、服务器样板代码
3. 实现

   plugin.GRPCPlugin

   的两个方法，分别调用上面生成的样板代码，获取gRPC客户端、注册gRPC服务实现类
4. 在gRPC服务实现类中，将gRPC接口适配为业务接口
5. 业务接口的实现由插件进程提供

样板类模板比较多，有些繁琐。

一个简单的键值存储服务：

syntax = "proto3";
package proto;

message GetRequest {
    string key = 1;
}

message GetResponse {
    bytes value = 1;
}

message PutRequest {
    string key = 1;
    bytes value = 2;
}

message Empty {}

service KV {
    rpc Get(GetRequest) returns (GetResponse);
    rpc Put(PutRequest) returns (Empty);
}

执行命令：

protoc -I proto/ proto/kv.proto --go_out=plugins=grpc:proto/

// Package shared contains shared data between the host and plugins.
package shared

import (
	"context"
	"net/rpc"

	"google.golang.org/grpc"

	"github.com/hashicorp/go-plugin"
	"github.com/hashicorp/go-plugin/examples/grpc/proto"
)


// 业务接口
type KV interface {
	Put(key string, value []byte) error
	Get(key string) ([]byte, error)
}

这一节的代码被宿主进程，插件进程共享。

gRPC模式下，你需要实现接口plugin.GRPCPlugin，并嵌入plugin.Plugin接口：

type KVGRPCPlugin struct {
	// 需要嵌入插件接口
	plugin.Plugin
	// 具体实现，仅当业务接口实现基于Go时该字段有用
	Impl KV
}

plugin.GRPCPlugin接口的规格如下，你需要实现两个方法：

type GRPCPlugin interface {
	// 此方法被插件进程调用，插件进程提供一个grpc.Server
	// 你需要向其注册gRPC服务的实现（服务器端存根）
	// 由于gRPC下服务器端是单例模式，因此该方法仅调用一次
	GRPCServer(*GRPCBroker, *grpc.Server) error

	// 此方法被宿主进程调用
	// 你需要返回一个业务接口的实现（客户端存根），此实现直接将请求转给gRPC客户端即可
	// 传入的context对象会在插件进程销毁时取消
	GRPCClient(context.Context, *GRPCBroker, *grpc.ClientConn) (interface{}, error)
}

在GRPCServer方法的实现中，你需要向参数提供的grpc.Server注册通过Proto文件生成的gRPC服务的Go接口：

type KVServer interface {
	Get(context.Context, *GetRequest) (*GetResponse, error)
	Put(context.Context, *PutRequest) (*Empty, error)
}

的实现（服务器存根）：

// 在此方法中提供实现：
func (p *KVGRPCPlugin) GRPCServer(broker *plugin.GRPCBroker, s *grpc.Server) error {
	proto.RegisterKVServer(s, &KVServerStub{Impl: p.Impl})
	return nil
}

// 实现自动生成的KVServer接口，具体逻辑委托给业务接口KV的实现
type KVServerStub struct {
	// This is the real implementation
	Impl KV
}

// 样板代码
func (m *KVServerStub) Put( ctx context.Context, req *proto.PutRequest) (*proto.Empty, error) {
	return &proto.Empty{}, m.Impl.Put(req.Key, req.Value)
}
func (m *KVServerStub) Get( ctx context.Context, req *proto.GetRequest) (*proto.GetResponse, error) {
	v, err := m.Impl.Get(req.Key)
	return &proto.GetResponse{Value: v}, err
}

在GRPCClient方法的实现中，你需要返回一个业务接口的实现（客户端存根），此实现只是将请求转发给gRPC服务处理：

func (p *KVGRPCPlugin) GRPCClient(ctx context.Context, broker *plugin.GRPCBroker, c *grpc.ClientConn) (interface{}, error) {
	//                         创建gRPC客户端的方法是自动生成的
	return &KVClientStub{client: proto.NewKVClient(c)}, nil
}

// 业务接口KV的实现，通过gRPC客户端转发请求给插件进程
type KVClientStub struct{ client proto.KVClient }

//                   业务接口
func (m *KVClientStub) Put(key string, value []byte) error {
// 转发
	_, err := m.client.Put(context.Background(), &proto.PutRequest{
		Key:   key,
		Value: value,
	})
	return err
}

func (m *KVClientStub) Get(key string) ([]byte, error) {
	resp, err := m.client.Get(context.Background(), &proto.GetRequest{
		Key: key,
	})
	if err != nil {
		return nil, err
	}

	return resp.Value, nil
}

使用gRPC方式时，只需要设置AllowedProtocols，其余的和netrpc模式没有区别。

package main

import (
	"fmt"
	"io/ioutil"
	"log"
	"os"
	"os/exec"

	"github.com/hashicorp/go-plugin"
	"github.com/hashicorp/go-plugin/examples/grpc/shared"
)

func main() {
	log.SetOutput(ioutil.Discard)

	// 创建插件进程
	client := plugin.NewClient(&plugin.ClientConfig{
		HandshakeConfig: plugin.HandshakeConfig{
			ProtocolVersion:  1,
			MagicCookieKey:   "BASIC_PLUGIN",
			MagicCookieValue: "hello",
		},
		Plugins:         map[string]plugin.Plugin{
			"kv_grpc": &KVGRPCPlugin{},
		},
		Cmd:             exec.Command("sh", "-c", os.Getenv("KV_PLUGIN")),
  	 	// 允许的协议类型，默认情况下允许netrpc
		AllowedProtocols: []plugin.Protocol{
			plugin.ProtocolNetRPC, plugin.ProtocolGRPC},
	})
	defer client.Kill()

	// 获取RPC客户端
	rpcClient, err := client.Client()
	if err != nil {
		fmt.Println("Error:", err.Error())
		os.Exit(1)
	}

	// 得到插件实例
	raw, err := rpcClient.Dispense("kv_grpc")
	if err != nil {
		fmt.Println("Error:", err.Error())
		os.Exit(1)
	}

	// 插件实例转换为业务接口
	// ...
}

和netrpc方式也没什么差别，只需要指定GRPCServer，提供创建gRPC服务器的函数即可：

package main

import (
	"fmt"
	"io/ioutil"

	"github.com/hashicorp/go-plugin"
	"github.com/hashicorp/go-plugin/examples/grpc/shared"
)

// 这里是KV的真实实现
type KV struct{}

func (KV) Put(key string, value []byte) error {
	value = []byte(fmt.Sprintf("%s\n\nWritten from plugin-go-grpc", string(value)))
	return ioutil.WriteFile("kv_"+key, value, 0644)
}

func (KV) Get(key string) ([]byte, error) {
	return ioutil.ReadFile("kv_" + key)
}

func main() {
	plugin.Serve(&plugin.ServeConfig{
		HandshakeConfig: plugin.HandshakeConfig{
			ProtocolVersion:  1,
			MagicCookieKey:   "BASIC_PLUGIN",
			MagicCookieValue: "hello",
		},
		Plugins: map[string]plugin.Plugin{
			"kv": &shared.KVGRPCPlugin{Impl: &KV{}},
		},

		// 该字段不为nil，则基于gRPC协议进行服务
		GRPCServer: plugin.DefaultGRPCServer,
	})
}

The post 基于本地gRPC的Go插件系统 appeared first on 绿色记忆.

gRPC是Google开源的高性能RPC框架，它在HTTP/2的基础之上实现。gRPC能高效的连接数据中心内部、跨数据中心的服务，并且可以提供名称解析、负载均衡、请求跟踪、健康检查以及身份验证等基础服务。它的主要适用场景包括：

1. 在微服务架构中，有效的将多种语言开发的服务连接到一起
2.  gRPC也可以用来将设备、移动应用程序、浏览器连接到后端服务
3. 生成高效的客户端库

gRPC的核心特性包括：

1. 支持多种主流编程语言
2. 基于HTTP/2的双向流传输
3. 可拔插的基础服务支持

相比起传统的HTTP/REST/JSON方式的RPC，基于HTTP/2实现RPC具有优势：二进制协议、单个连接上的请求多路分发、头压缩。

gRPC要求Go的版本在1.6+。执行下面的命令安装所需的包：

export https_proxy="http://10.0.0.1:8087/"
# gRPC
go get -u google.golang.org/grpc
# ProtoBuf
go get -u github.com/golang/protobuf/protoc-gen-go

下面是一个用户信息查询服务的例子：

syntax = "proto3";
package gmem;

service UserService {
    // gRPC服务的参数和返回值必须是message类型，不能是任何原始类型
    rpc GetUser (GetUserRequest) returns (User) {
    }
}
message GetUserRequest {
    uint32 userId = 1;
}
message User {
    uint32 userId = 1;
    string userName = 2;
    string dob = 3;
}

执行如下命令生成gRPC的Go语言代码：

cd /home/alex/Go/workspace/default/src/grpc
# Proto源文件中注意Go包声明 option go_package = "./pkg/grpc/supportplan";
protoc --proto_path=protos --go_out=. --go-grpc_out=. protos/*.proto

命令输出为一个Go源码文件，内容如下：

package gmem

import (
    proto "github.com/golang/protobuf/proto"
    context "golang.org/x/net/context"
    grpc "google.golang.org/grpc"
)


/* 消息结构体代码 */
// RPC请求消息结构体
type GetUserRequest struct {
    UserId uint32 `protobuf:"varint,1,opt,name=userId" json:"userId,omitempty"`
}
// RPC响应消息结构体
type User struct {
    UserId   uint32 `protobuf:"varint,1,opt,name=userId" json:"userId,omitempty"`
    UserName string `protobuf:"bytes,2,opt,name=userName" json:"userName,omitempty"`
    Dob      string `protobuf:"bytes,3,opt,name=dob" json:"dob,omitempty"`
}
func init() {
    // 将Go语言结构指针映射到对应的ProtoBuf全限定名
    proto.RegisterType((*GetUserRequest)(nil), "gmem.GetUserRequest")
    proto.RegisterType((*User)(nil), "gmem.User")
}


/* gRPC代码 */

// gRPC服务的客户端API
type UserServiceClient interface {
    GetUser(ctx context.Context, in *GetUserRequest, opts ...grpc.CallOption) (*User, error)
}
type userServiceClient struct {
    cc *grpc.ClientConn
}
// 调用下面的方法来创建gRPC客户端
func NewUserServiceClient(cc *grpc.ClientConn) UserServiceClient {
    return &userServiceClient{cc}
}
func (c *userServiceClient) GetUser(ctx context.Context, in *GetUserRequest, opts ...grpc.CallOption) (*User, error) {
	out := new(User)
	err := grpc.Invoke(ctx, "/gmem.UserService/GetUser", in, out, c.cc, opts...)
	if err != nil {
		return nil, err
	}
	return out, nil
}

// gRPC服务的服务器端API
type UserServiceServer interface {
	GetUser(context.Context, *GetUserRequest) (*User, error)
}
// 调用下面的方法来注册gRPC服务器端实现
func RegisterUserServiceServer(s *grpc.Server, srv UserServiceServer) {
	s.RegisterService(&_UserService_serviceDesc, srv)
}
func _UserService_GetUser_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
	in := new(GetUserRequest)
	if err := dec(in); err != nil {
		return nil, err
	}
	if interceptor == nil {
		return srv.(UserServiceServer).GetUser(ctx, in)
	}
	info := &grpc.UnaryServerInfo{
		Server:     srv,
		FullMethod: "/gmem.UserService/GetUser",
	}
	handler := func(ctx context.Context, req interface{}) (interface{}, error) {
		return srv.(UserServiceServer).GetUser(ctx, req.(*GetUserRequest))
	}
	return interceptor(ctx, in, info, handler)
}
var _UserService_serviceDesc = grpc.ServiceDesc{
	ServiceName: "gmem.UserService",
	HandlerType: (*UserServiceServer)(nil),
	Methods: []grpc.MethodDesc{
		{
			MethodName: "GetUser",
			Handler:    _UserService_GetUser_Handler,
		},
	},
	Streams:  []grpc.StreamDesc{},
	Metadata: "UserService.proto",
}

func init() { proto.RegisterFile("UserService.proto", fileDescriptor0) }

可以看到，gRPC的客户端存根、服务器接口是自动生成的，其中封装了和远程调用相关的逻辑。我们需要调用存根、实现接口，来编写完整的gRPC客户端或者服务器。 

package main

import (
    "context"
    "grpc/gmem"
    "net"
    "google.golang.org/grpc"
    "google.golang.org/grpc/reflection"
    "log"
)

// 实现服务器端接口 UserServiceServer
type UserServiceServerImpl struct {
}

func (srv *UserServiceServerImpl) GetUser(ctx context.Context, req *gmem.GetUserRequest) (*gmem.User, error) {
    return &gmem.User{
        UserId:   req.GetUserId(),
        UserName: "Alex Wong",
        Dob:      "1986-09-12",
    }, nil
}

func main() {
    lis, _ := net.Listen("tcp", ":5500")
    grpc := grpc.NewServer()
    gmem.RegisterUserServiceServer(grpc, &UserServiceServerImpl{})
    reflection.Register(grpc)
    err := grpc.Serve(lis)
    if err != nil {
        log.Fatalf("无法创建RPC服务器：%v", err)
    }
}

package main

import (
    "google.golang.org/grpc"
    "log"
    "grpc/gmem"
    "context"
    "encoding/json"
)

func main() {
    // 连接gRPC服务器
    conn, _ := grpc.Dial("localhost:5500", grpc.WithInsecure())

    // 不再使用时需要关闭连接
    defer conn.Close()

    // 创建客户端对象
    var client gmem.UserServiceClient = gmem.NewUserServiceClient(conn)
    userRequest := gmem.GetUserRequest{UserId: 10000}
    user, err := client.GetUser(context.Background(), &userRequest)
    if err != nil {
        log.Fatalf("远程调用失败: %v", err)
    }
    userJson, _ := json.Marshal(*user)
    log.Println(string(userJson)) //  {"userId":10000,"userName":"Alex Wong","dob":"1986-09-12"}
} 

可以使用Maven插件protobuf-maven-plugin来生成gRPC的客户端和服务器API：

<project>
    <!-- GRPC相关依赖 -->
    <dependencies>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-netty</artifactId>
            <version>1.9.0</version>
        </dependency>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-protobuf</artifactId>
            <version>1.9.0</version>
        </dependency>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-stub</artifactId>
            <version>1.9.0</version>
        </dependency>
    </dependencies>

    <build>
        <extensions>
            <extension>
                <groupId>kr.motd.maven</groupId>
                <artifactId>os-maven-plugin</artifactId>
                <version>1.5.0.Final</version>
            </extension>
        </extensions>
        <plugins>
            <!-- 集成基于ProtoBuf的代码生成 -->
            <plugin>
                <groupId>org.xolstice.maven.plugins</groupId>
                <artifactId>protobuf-maven-plugin</artifactId>
                <version>0.5.0</version>
                <configuration>
                    <protocArtifact>com.google.protobuf:protoc:3.5.1-1:exe:${os.detected.classifier}</protocArtifact>
                    <pluginId>grpc-java</pluginId>
                    <pluginArtifact>io.grpc:protoc-gen-grpc-java:1.9.0:exe:${os.detected.classifier}</pluginArtifact>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                            <goal>compile-custom</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.5.1</version>
                <configuration>
                    <encoding>${project.build.sourceEncoding}</encoding>
                    <source>1.8</source>
                    <target>1.8</target>
                    <debug>true</debug>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

需要使用到的插件目标：

注意：

1. 上述目标生成代码会自动添加到工程的源码路径，不需要拷贝到src/main/java
2. proto文件需要放置在src/main/proto下

服务器示例：

package cc.gmem.study.grpc;

import io.grpc.ServerBuilder;
import io.grpc.stub.StreamObserver;

import java.io.IOException;

public class UserServiceServer {

    public static void main( String[] args ) throws IOException, InterruptedException {
        // 启动GRPC服务器并注册RPC接口的实现类
        io.grpc.Server server = ServerBuilder
                .forPort( 5500 )
                .addService( new UserServiceImpl() )
                .build()
                .start();
        server.awaitTermination();
        // 优雅的关闭GRPC服务器
        Runtime.getRuntime().addShutdownHook( new Thread( () -> server.shutdown() ) );
    }

    private static class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {

        @Override
        public void getUser( GetUserRequest request, StreamObserver<User> responseObserver ) {
            User user = User.newBuilder()
                            .setUserId( request.getUserId() )
                            .setUserName( "Alex Wong" )
                            .setDob( "1986-09-12" )
                            .build();
            responseObserver.onNext( user );
            responseObserver.onCompleted();
        }
    }
} 

客户端示例：

package cc.gmem.study.grpc;

import io.grpc.ManagedChannel;
import io.grpc.ManagedChannelBuilder;

import java.util.concurrent.ExecutionException;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;

public class UserServiceClient {

    public static void main( String[] args ) throws InterruptedException, TimeoutException, ExecutionException {
        ManagedChannel channel = ManagedChannelBuilder.forAddress( "localhost", 5500 ).usePlaintext( true ).build();
        // 阻塞的客户端存根
        UserServiceGrpc.UserServiceBlockingStub stub = UserServiceGrpc.newBlockingStub( channel );
        // 非阻塞的客户端存根
        UserServiceGrpc.UserServiceFutureStub asyncStub = UserServiceGrpc.newFutureStub( channel );

        // 构建请求消息
        GetUserRequest request = GetUserRequest.newBuilder().setUserId( 10000 ).build();
        // 发起同步请求
        User user = stub.getUser( request );
        // 发起异步请求
        asyncStub.getUser( request ).get( 1, TimeUnit.SECONDS );

        // 关闭通道
        channel.shutdown().awaitTermination( 5, TimeUnit.SECONDS );
    }
}

和典型的RPC一样，gRPC允许你定义服务、指定可以被远程调用的接口，为这些接口指定参数和返回值类型。默认的，gRPC使用ProtoBuf作为接口定义语言（IDL，Interface Definition Language ）。gRPC支持四类服务定义。

conn, _ := grpc.Dial(ChartAddr, []grpc.DialOption{
        // 不加下面这项可能出现段错误
        grpc.WithInsecure(),
        // 阻塞直到连接成功，默认情况下Dial方法立即返回，在后台连接
	grpc.WithBlock(),
        // 每30s发送keepalive心跳包，防止连接被上游服务器关闭
	grpc.WithKeepaliveParams(keepalive.ClientParameters{
		Time: time.Duration(30) * time.Second,
	}),
        // 增加最大消息限制，默认4MB
	grpc.WithDefaultCallOptions(grpc.MaxCallRecvMsgSize(1024 * 1024 * 20)),
}...)

客户端发起单个请求，然后获得单个响应，就像是典型的函数调用：

rpc SayHello(HelloRequest) returns (HelloResponse){
}

1. 客户端调用Stub代码
2. 服务器感知到RPC调用的发生，获得客户端的元数据、方法名、Deadline
3. 服务器可以将自己的元数据发送给客户端，或者等待请求消息的到达。元数据必须先于响应发送
4. 服务器接收到客户端的请求消息后，进行处理
5. 响应消息连同状态（状态码、可选的状态信息）一起发送给客户端，可以附加一个trailing元数据一起发送
6. 如果响应码为ok，客户端获取响应并处理

客户端发起单个请求，然后获得一个流，服务端通过此流连续的发送多个响应消息：

rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse){
}

和一元RPC类似，但是服务器会发生响应消息的流。当所有响应消息发送完毕后，状态、可选的trailing元数据被发送

服务器：

func (ms *MediaService) NewPublished(from *google_protobuf.Timestamp, stream digital.MediaService_NewPublishedServer) error {
    medias, error := mediaRepo.queryPublishedFrom(time.Unix(from.Seconds, int64(from.Nanos)))
    for _, media := range *medias {
        stream.Send(&media)
    }
    return error
}

客户端：

func TestMediaNewPubRPC(t *testing.T) {
    conn, _ := grpc.Dial("localhost:7700", grpc.WithInsecure())
    defer conn.Close()
    client := digital.NewMediaServiceClient(conn)
    from, _ := now.Parse("2017-01-01")
    stream, err := client.NewPublished(context.Background(), &protobuf.Timestamp{Seconds: int64(from.Unix())})
    fatalIf(err)
    for {
        media, err := stream.Recv()
        if err == io.EOF {
            break
        }
        log.Println(media.GetTitle())
    }
}

客户端发起一系列的请求消息，并等待服务器的单个响应消息：

rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse) {
}

和一元RPC类似，但是：

1. 客户端发送请求消息的流
2. 服务器可以在尚未接收全部请求消息的情况下给出响应

客户端、服务器都使用流来收发消息，请求流、响应流独立运行。消息处理方式很自由：

1. 服务器可以等待，接收到客户端的所有消息后，进行处理并产生响应
2. 服务器可以读取到一个消息，然后写入一个响应
3. 其它任意的组合方式 

每个流的消息的顺序是被保证的。

rpc BidiHello(stream HelloRequest) returns (stream HelloResponse){
}

同步化的RPC调用会一直阻塞，直到响应到达客户端，这种通信模型是典型RPC所期望的。

但是，网络传输天生是异步的，在很多情况下，启动一个RPC调用但不阻塞当前线程，可以增强系统容量。gRPC为大部分语言提供了两套（同步/异步）编程接口。

gRPC允许客户端指定，等待RPC调用完成的最长时间，如果超时未完成会出现

DEADLINE_EXCEEDED

在Go语言中，超时通过Context设置：

ctx, cancel := context.WithTimeout(context.Background(), 50*time.Millisecond)
defer cancel()

client.GetUser(context.Background(), &userRequest)

在Java语言中，调用Stub的方法设置超时：

blockingStub = UserServiceGrpc
        .newBlockingStub(channel)
        .withDeadlineAfter(3, TimeUnit.SECONDS);

在gRPC中，客户端、服务器分别独立的在本地判定调用是否成功 —— 两者的结论可能不一致。服务器端成功但是客户端没有收到响应是可能的。

在任何时候，客户端、服务器都可以取消RPC调用。

元数据是和某次特定的RPC调用相关的，键值对的列表。其中键为字符串，值通常也是字符串。

元数据包括的信息例如：身份验证的详细信息

参考：Protocol Buffers初探

gRPC支持使用HTTP/2的PING帧实现保活。

创建客户端时，你可以：

var kacp = keepalive.ClientParameters{
	Time:                10 * time.Second, // 如果没有活动，每10秒发送PING帧
	Timeout:             time.Second,      // 等待接收到PING的ACK的超时，超时后认为连接坏掉了
	PermitWithoutStream: true,             // 即使没有活动的stream，也发送PING帧
}
//Dial 中传入 keepalive 配置
conn, err := grpc.Dial(*addr, grpc.WithInsecure(), grpc.WithKeepaliveParams(kacp))

创建服务器时，你可以： 

var kaep = keepalive.EnforcementPolicy{
// 客户端在发送Keepalive PING之前，需要等待的最小时间，默认5分钟
	MinTime:             5 * time.Minute,
// 即使没有活动的流，也允许客户端发送PING。如果设置为false，客户端在没有流的情况下发送PING，
// 服务器会答复GOAWAY，并终止HTTP/2连接
	PermitWithoutStream: true,
}

var kasp = keepalive.ServerParameters{
// 连接最大空闲时间，超过此时间服务器主动发送GOAWAY
// 空闲的起点：从连接建立开始、或者没有正常处理中的RPC调用的那一刻开始算
	MaxConnectionIdle:     15 * time.Second,
// 一个连接可以最大存活的时间，超过此时间（服务器增加10%抖动），则发送GOWAY
	MaxConnectionAge:      30 * time.Second,
// 超过MaxConnectionAge之后，再等待MaxConnectionAgeGrace才强制关闭连接
	MaxConnectionAgeGrace: 5 * time.Second,
// 如果经过下面这么长时间，服务器没有看到任何活动，发送PING来探测客户端是否还活着
	Time:                  5 * time.Second,
// 等待上述PING的超时，超时后关闭连接
	Timeout:               1 * time.Second,
}

func main(){
	...
	s := grpc.NewServer(grpc.KeepaliveEnforcementPolicy(kaep), grpc.KeepaliveParams(kasp))
	...
}

 大型的gRPC部署场景中，每个RPC服务都会有多个实例。负载均衡负责把客户端负载优化的（根据服务器能力）

这是Go语言的gRPC库。本文Go语言的例子都是基于此库。

ClientConn可以被跨Goroutine安全的访问。但是在我们的一个项目中，长期存在的ClientConn导致很高的CPU占用，原因未知。

使用Stream时，避免从不通Goroutine多次调用同一个Stream的SendMsg、RecvMsg方法。具体来说：

1. 对于同一个Stream，从一个Goroutine调用SendMsg，另一个调用RecvMsg是安全的
2. 对于同一个Stream，分别从两个Goroutine调用SendMsg，或者RecvMsg是不安全的

在服务器端，每个注册到gRPC服务器的RPC Handler，都在独立的Goroutine中运行。

RPC服务的参数、返回值都必须是消息类型，不能是原始类型。

示例：

service MediaService {
    rpc NewPublished (google.protobuf.Timestamp) returns (stream Media);
}

使用这种方式时，客户端会得到一个迭代器。在服务器尚未把响应完全发送之前，客户端就可以开始处理。

示例：

message MediaResp {
    repeated Media medias = 1;
}
service MediaService {
    rpc NewPublished (google.protobuf.Timestamp) returns (stream Media);
}

The post gRPC学习笔记 appeared first on 绿色记忆.

节选自：https://dubbo.apache.org/zh-cn/blog/rpc-introduction.html，稍作改动。

RPC（Remote Procedure Call）即远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。现在业界有很多开源的优秀 RPC 框架，例如 Spring Cloud、Dubbo、Thrift 等。

RPC 这个概念术语在上世纪 80 年代由 Bruce Jay Nelson 提出。在 Nelson 的论文 "Implementing Remote Procedure Calls" 中提到了RPC的几点优势：

1. 简单：RPC 概念的语义十分清晰和简单，这样建立分布式计算就更容易
2. 高效：过程调用看起来十分简单而且高效
3. 通用：在单机计算中过程往往是不同算法部分间最重要的通信机制

通俗一点说，就是一般程序员对于本地的过程调用很熟悉，那么我们把 RPC 作成和本地调用完全类似，那么就更容易被接受，使用起来毫无障碍。Nelson 的论文发表于 30 年前，其观点今天看来确实高瞻远瞩，今天我们使用的 RPC 框架基本就是按这个目标来实现的。

Nelson 的论文中的RPC包含以下角色：

1. User（客户端）：像调用本地服务似的调用远程服务
2. User-stub：接收到调用后，将方法、参数序列化；接收到结果消息，并进行解码（将结果消息反序列化）
3. RPCRuntime
4. Server-stub：收到消息后进行解码（将消息对象反序列化）、根据解码结果调用本地的服务、将返回结果打包成消息（将结果消息对象序列化）
5. Server（服务器）实现服务逻辑

它们之间的交互流程如下：

RPC框架通常会细化出以下组件：

各组件职责：

1. RpcServer：负责导出（export）远程接口
2. RpcClient：负责导入（import）远程接口的代理实现
3. RpcProxy：远程接口的代理实现
4. RpcInvoker：
   1. 客户方实现：负责编码调用信息和发送调用请求到服务方并等待调用结果返回
   2. 服务方实现：负责调用服务端接口的具体实现并返回调用结果
5. RpcProtocol：负责协议编/解码
6. RpcConnector：负责维持客户方和服务方的连接通道和发送数据到服务方
7. RpcAcceptor：负责接收客户方请求并返回请求结果
8. RpcProcessor：负责在服务方控制调用过程，包括管理调用线程池、超时时间等
9. RpcChannel：数据传输通道

下面是一段示例代码，以编程的方式创建消费者，并获取RPC接口的Stub：

ApplicationConfig application = new ApplicationConfig();
application.setName( "ITokenVerifyApiStressor" );

RegistryConfig registry = new RegistryConfig();
registry.setAddress( "zookeeper://10.255.223.119:2881" );

ReferenceConfig<ITokenVerifyApi> reference = new ReferenceConfig<ITokenVerifyApi>();
reference.setApplication( application );
reference.setRegistry( registry );
reference.setInterface( ITokenVerifyApi.class );
reference.setVersion( "5.0" );

ITokenVerifyApi api = reference.get();

// 服务的实现
UploadService uploadService = new UpdateServiceImpl();

// Dubbo应用程序信息
ApplicationConfig application = new ApplicationConfig();
application.setName( "UploadServiceProvider" );

// 注册中心配置
RegistryConfig registry = new RegistryConfig();
registry.setAddress( "zookeeper://10.255.223.119:2881" );

// 服务提供者协议配置
ProtocolConfig protocol = new ProtocolConfig();
protocol.setName( "dubbo" );
protocol.setPort( 20880 );
protocol.setThreads( 8 );
protocol.setPayload( 8388608 / 8 / 1024 );

// 暴露服务配置
ServiceConfig<UploadService> service = new ServiceConfig<UploadService>();
service.setApplication( application );
service.setRegistry( registry );
service.setProtocol( protocol );
service.setInterface( UploadService.class );
service.setRef( uploadService );
service.setVersion( "1.0" );
service.export();

<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.5.RELEASE</version>
    </parent>

    <dependencies>
        <dependency>
            <groupId>com.alibaba.spring.boot</groupId>
            <artifactId>dubbo-spring-boot-starter</artifactId>
            <version>2.0.0</version>
        </dependency>
        <dependency>
            <groupId>com.github.sgroschupf</groupId>
            <artifactId>zkclient</artifactId>
            <version>0.1</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

spring.application.name=dubbo-exporter
spring.dubbo.server=true
spring.dubbo.registry=zookeeper://10.108.94.255:2181

@SpringBootApplication
@EnableDubboConfiguration
public class Application {

    public static void main( String[] args ) {
        SpringApplication.run( Application.class, args );
    }
}

@Service( interfaceClass = MonitorService.class )
@Component
public class MonitorServiceImpl implements MonitorService {
} 

该注解是 @EnableDubboConfig 和 @DubboComponentScan两者的组合：

@EnableDubboConfig
@DubboComponentScan
public @interface EnableDubbo {
    // 扫描 @Service 的基包
    @AliasFor(annotation = DubboComponentScan.class, attribute = "basePackages")
    String[] scanBasePackages() default {};

    // 扫描 @Service 的基包（指定的类所在的包）
    @AliasFor(annotation = DubboComponentScan.class, attribute = "basePackageClasses")
    Class<?>[] scanBasePackageClasses() default {};    
}

用来配置服务提供方： 

package org.apache.dubbo.config.annotation;

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE}) 
@Inherited
public @interface Service {
    // 实现的 interface 的类
    Class<?> interfaceClass() default void.class;
    // 实现的 interface 的类名
    String interfaceName() default "";
    // 服务的版本号
    String version() default "";
    // 服务的分组
    String group() default "";
    // 是否暴露服务
    boolean export() default true;
    // 是否向注册中心注册服务
    boolean register() default true;
    // 应用程序名称
    String application() default "";
    // 模块名称
    String module() default "";
    // 提供者名称
    String provider() default "";
    // 协议配置
    String[] protocol() default {};
    // 监控中心配置
    String monitor() default "";
    // 注册中心配置
    String[] registry() default {};
}

用来配置消费者： 

package org.apache.dubbo.config.annotation;

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.METHOD, ElementType.ANNOTATION_TYPE}) 
public @interface Reference {
    Class<?> interfaceClass() default void.class; 
    String interfaceName() default ""; 
    String version() default "";
    String group() default "";
    String url() default "";
    
    String application() default "";
    String module() default "";
    String consumer() default "";
    String protocol() default "";
    String monitor() default "";
    String[] registry() default {};
} 

Hystrix 旨在通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备拥有回退机制和断路器功能的线程和信号隔离，请求缓存和请求打包，以及监控和配置等功能。

spring boot官方提供了对hystrix的集成，直接在pom.xml里加入依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
    <version>1.4.4.RELEASE</version>
</dependency>

然后在Application类上增加@EnableHystrix来启用：

@SpringBootApplication
@EnableHystrix
public class ProviderApplication {
}

@Service(version = "1.0.0")
public class HelloServiceImpl implements HelloService {
    @HystrixCommand(commandProperties = {
                    @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),
                    @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000") })
    @Override
    public String sayHello(String name) {
        throw new RuntimeException("Exception to show hystrix enabled.");
    }
}

@Reference(version = "1.0.0")
private HelloService demoService;

// 降级
@HystrixCommand(fallbackMethod = "reliable")
public String doSayHello(String name) {
    return demoService.sayHello(name);
}
public String reliable(String name) {
    return "hystrix fallback value";
}

新的服务定义/注册机制称为“服务自省”，一个应用只需要注册一条记录，解决了服务推送的性能瓶颈。

Dubbo RPC 协议是构建在 TCP 之上，这有很多优势也有一些缺点，缺点比如通用性、协议穿透性不强，对多语言实现不够友好等。

HTTP/2 由于其标准 HTTP 协议的属性，无疑将具有更好的通用性，现在或将来在各层网络设备上肯定都会得到很好的支持，gRPC 之所以选在 HTTP/2 作为传输层载体很大程度上也是因为这个因素。

Dubbo 支持 gRPC 协议带来的直观好处有：

1. 正式支持基于 HTTP/2 的远程通信，在协议通用性和穿透性上进一步提升
2. 支持跨进程的 Stream 流式通信，支持 Reactive 风格的 RPC 编程
3. 解决了 gRPC 框架难以直接用于微服务开发的问题，将其纳入 Dubbo 的服务治理体系
4. 为连接组织内部已有的 gRPC 或多语言体系提供支持

支持 Protobuf 是为了解决Dubbo的跨语言、易用性问题。协议上 2.7.5 版本支持了 gRPC，而关于服务定义与序列化，Protobuf 则提供了很好的解决方案：

1. 服务定义：当前 Dubbo 的服务定义和具体的编程语言绑定，没有提供一种语言中立的服务描述格式，比如 Java 就是定义 Interface 接口，到了其他语言又得重新以另外的格式定义一遍。因此 Dubbo 通过支持 Protobuf 实现了语言中立的服务定义
2. 序列化。Dubbo 当前支持的序列化包括 Json、Hessian2、Kryo、FST、Java 等，而这其中支持跨语言的只有 Json、Hessian2，通用的 Json 有固有的性能问题，而 Hessian2 无论在效率还是多语言 SDK 方面都有所欠缺。为此，Dubbo 通过支持 Protobuf 序列化来提供更高效、易用的跨语言序列化方案

QPS 性能提升将近 30%、减少了调用过程中的内存分配开销。

ProtocolConfig protocolConfig = new ProtocolConfig("grpc");
protocolConfig.setSslEnabled(true);

SslConfig sslConfig = new SslConfig();
sslConfig.setXxxCert(...);

DubboBootstrap bootstrap = DubboBootstrap.getInstance();
bootstrap.application(new ApplicationConfig("ssl-provider"))
  .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
  .protocol(protocolConfig)
  .ssl(sslConfig);

ServiceConfig<GreetingsService> service1 = new ServiceConfig<>();
ServiceConfig<GreetingsService> service2 = new ServiceConfig<>();

bootstrap.service(service1).service(service2);
bootstrap.start();

在引入 Dubbo Bootstrap 后，新的编程模型变得更简单，并且也为解决了缺少实例级启动入口的问题。 

直接支持CompletableFuture。

<dubbo:registry address=“zookeeper://127.0.0.1:2181” simplified="true"/>

<dubbo:metadata-report address="zookeeper://127.0.0.1:2181"/>

Dubbo的发展路线是作为服务治理框架，而非简单的RPC框架。在 2.7 中，Dubbo 对其服务治理能力进行了增强，增加了标签路由的能力，并抽象出了应用路由和服务路由的概念。

标签路由可以实现灰度发布。你可以在SPI扩展、过滤器中对请求打标签：

RpcContext.getContext().setAttachment()

泛化调用主要用于消费端没有 API 接口的情况，不需要引入接口 jar 包，而是直接通过 GenericService 接口来发起服务调用，参数及返回值中的所有 POJO 均用 Map 表示。

你需要声明服务引用为泛化的：

<dubbo:reference id="userService" interface="com.alibaba.dubbo.samples.generic.api.IUserService" 
    generic="true"/>

执行泛化调用的代码：

GenericService userService = (GenericService) context.getBean("userService");
//                                          方法名    参数类型数组                     参数值数组
String name = (String) userService.$invoke("delete", new String[]{int.class.getName()}, new Object[]{1});
System.out.println(name); 

从 2.2.0 版本开始，Dubbo 默认在本地以 injvm 的方式暴露服务，在同一个进程里对这个服务的调用会优先走本地调用。

本地调用可以被明确的关闭掉：

<dubbo:service interface="org.apache.dubbo.samples.local.api.DemoService" 
    ref="target" scope="remote"/>
                 <!-- 显式关闭 -->

你可以通过URL来明确进行本地调用

<dubbo:reference id="demoService" interface="org.apache.dubbo.samples.local.api.DemoService" 
    url="injvm://127.0.0.1/org.apache.dubbo.samples.local.api.DemoService"/>

在2.6.x及之前的版本提供了一定的异步编程能力，包括Consumer端异步调用、参数回调、事件通知。这些老版本中的异步调用存在缺陷：

1. Future获取方式不够直接，需要通过RpcContext获取Future
2. Future接口无法实现自动回调，而自定义ResponseFuture虽支持回调但支持的异步场景有限，如不支持Future间的相互协调或组合
3. 不支持Provider端异步

2.7.0升级了对Java 8的支持，基于CompletableFuture对当前的异步功能进行了增强，现在服务可以直接返回CompletableFuture：

public interface AsyncService {
    CompletableFuture<String> sayHello(String name);
}

如果不想将接口的返回值定义为Future类型，或者存在定义好的同步类型接口，可以重载现有的服务方法： 

public interface GreetingsService {
    String sayHi(String name);
    // 为了保证方法级服务治理规则依然有效，建议保持方法名不变: sayHi
    // 使用default实现，避免给服务端提供者带来额外实现成本
    // placeholer只是为了实现重载而增加
    default CompletableFuture<String> sayHi(String name, boolean placeholer) {
      return CompletableFuture.completedFuture(sayHello(name));
    }
}

public class AsyncServiceImpl implements AsyncService {
    public CompletableFuture<String> sayHello(String name) {
        return CompletableFuture.supplyAsync(() -> {
            try {
                Thread.sleep(5000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return "async response from provider.";
        });
    }
}

public static void main(String[] args) throws Exception {
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
            new String[]{"META-INF/spring/async-consumer.xml"});
        context.start();
        final AsyncService asyncService = (AsyncService) context.getBean("asyncService");
    
        CompletableFuture<String> future = asyncService.sayHello("async call request");
        future.whenComplete((v, t) -> {
            if (t != null) {
                t.printStackTrace();
            } else {
                System.out.println("Response: " + v);
            }
        });
        System.out.println("Executed before response return.");
        System.in.read();
}

采用异步调用后，由于异步结果在异步线程中单独执行，所以流经后半段Filter链的Result是空值，当真正的结果返回时已无法被Filter链处理。为了解决这个问题，2.7.0中为Filter增加了回调接口onResponse：

@Activate(group = {Constants.PROVIDER, Constants.CONSUMER})
public class AsyncPostprocessFilter implements Filter {

    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        return invoker.invoke(invoker, invocation);
    }

    @Override
    public Result onResponse(Result result, Invoker<?> invoker, Invocation invocation) {
        System.out.println("Filter get the return value: " + result.getValue());
        return result;
    }
}

你需要在切换业务线程前自己完成Context的传递： 

public class AsyncServiceImpl implements AsyncService {
    // 保存当前线程的上下文
    RpcContext context = RpcContext.getContext();
    public CompletableFuture<String> sayHello(String name) {
        return CompletableFuture.supplyAsync(() -> {
            // 设置到新线程中
            RpcContext.setContext(context);
            try {
                Thread.sleep(5000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return "async response from provider.";
        });
    }
}

AsyncContext也提供了signalContextSwitch()的方法来实现方便的Context切换： 

public class AsyncServiceImpl implements AsyncService {
    public String sayHello(String name) {
        final AsyncContext asyncContext = RpcContext.startAsync();
        new Thread(() -> {
            asyncContext.signalContextSwitch();
            try {
                Thread.sleep(500);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            asyncContext.write("Hello " + name + ", response from provider.");
        }).start();
        return null;
    }
} 

当一个接口有多种实现时，可以用 group 区分：

<!-- 提供者 -->
<dubbo:service group="feedback" interface="com.xxx.IndexService" />
<dubbo:service group="member" interface="com.xxx.IndexService" />

<!-- 消费者 -->
<dubbo:reference id="feedbackIndexService" group="feedback" interface="com.xxx.IndexService" />
<dubbo:reference id="memberIndexService" group="member" interface="com.xxx.IndexService" />
<!-- 不限制组 -->
<dubbo:reference id="barService" interface="com.foo.BarService" group="*" />

消费者可以同时调用不同分组中的同一服务，并将结果聚合：

<dubbo:reference interface="com.xxx.MenuService" group="*" merger="true" />

<dubbo:reference interface="com.xxx.MenuService" group="aaa,bbb" merger="true" />

当接口实现出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。版本迁移推荐步骤：

1. 在低压力时间段，先升级一半提供者为新版本
2. 再将所有消费者升级为新版本
3. 然后将剩下的一半提供者升级为新版本

如果不需要区分版本，可以这样配置消费者：

<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

报错信息：log4j:WARN No appenders could be found for logger (com.alibaba.dubbo.common.logger.LoggerFactory).
log4j:WARN Please initialize the log4j system properly.

解决方案：添加JVM参数

-Ddubbo.application.logger=slf4j

The post Dubbo知识集锦 appeared first on 绿色记忆.