企業級 RPC 框架 zRPC

近期比較火的開源專案go-zero是一個整合了各種工程實踐的包含了 Web 和 RPC 協議的功能完善的微服務框架，今天我們就一起來分析一下其中的 RPC 部分zRPC。

zRPC 底層依賴 gRPC，內建了服務註冊、負載均衡、攔截器等模組，其中還包括自適應降載，自適應熔斷，限流等微服務治理方案，是一個簡單易用的可直接用於生產的企業級 RPC 框架。

zRPC 初探

zRPC 支援直連和基於 etcd 服務發現兩種方式，我們以基於 etcd 做服務發現為例演示 zRPC 的基本使用：

配置

建立 hello.yaml 配置檔案，配置如下：

Name: hello.rpc           // 服務名
ListenOn: 127.0.0.1:9090  // 服務監聽地址
Etcd:
  Hosts:
    - 127.0.0.1:2379      // etcd服務地址
  Key: hello.rpc          // 服務註冊key

建立 proto 檔案

建立 hello.proto 檔案，並生成對應的 go 程式碼

syntax = "proto3";

package pb;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

生成 go 程式碼

protoc --go_out=plugins=grpc:. hello.proto

Server 端

package main

import (
    "context"
    "flag"
    "log"

    "example/zrpc/pb"

    "github.com/tal-tech/go-zero/core/conf"
    "github.com/tal-tech/go-zero/zrpc"
    "google.golang.org/grpc"
)

type Config struct {
    zrpc.RpcServerConf
}

var cfgFile = flag.String("f", "./hello.yaml", "cfg file")

func main() {
    flag.Parse()

    var cfg Config
    conf.MustLoad(*cfgFile, &cfg)

    srv, err := zrpc.NewServer(cfg.RpcServerConf, func(s *grpc.Server) {
        pb.RegisterGreeterServer(s, &Hello{})
    })
    if err != nil {
        log.Fatal(err)
    }
    srv.Start()
}

type Hello struct{}

func (h *Hello) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {
    return &pb.HelloReply{Message: "hello " + in.Name}, nil
}

Client 端

package main

import (
    "context"
    "log"

    "example/zrpc/pb"

    "github.com/tal-tech/go-zero/core/discov"
    "github.com/tal-tech/go-zero/zrpc"
)

func main() {
    client := zrpc.MustNewClient(zrpc.RpcClientConf{
        Etcd: discov.EtcdConf{
            Hosts: []string{"127.0.0.1:2379"},
            Key:   "hello.rpc",
        },
    })

    conn := client.Conn()
    hello := pb.NewGreeterClient(conn)
    reply, err := hello.SayHello(context.Background(), &pb.HelloRequest{Name: "go-zero"})
    if err != nil {
        log.Fatal(err)
    }
    log.Println(reply.Message)
}

啟動服務，檢視服務是否註冊：

ETCDCTL_API=3 etcdctl get hello.rpc --prefix

顯示服務已經註冊：

hello.rpc/7587849401504590084
127.0.0.1:9090

執行客戶端即可看到輸出：

hello go-zero

這個例子演示了 zRPC 的基本使用，可以看到通過 zRPC 構建 RPC 服務非常簡單，只需要很少的幾行程式碼，接下來我們繼續進行探索

zRPC 原理分析

下圖展示 zRPC 的架構圖和主要組成部分

zRPC 主要有以下幾個模組組成：

• discov: 服務發現模組，基於 etcd 實現服務發現功能
• resolver: 服務註冊模組，實現了 gRPC 的 resolver.Builder 介面並註冊到 gRPC
• interceptor: 攔截器，對請求和響應進行攔截處理
• balancer: 負載均衡模組，實現了 p2c 負載均衡演算法，並註冊到 gRPC
• client: zRPC 客戶端，負責發起請求
• server: zRPC 服務端，負責處理請求

這裡介紹了 zRPC 的主要組成模組和每個模組的主要功能，其中 resolver 和 balancer 模組實現了 gRPC 開放的介面，實現了自定義的 resolver 和 balancer，攔截器模組是整個 zRPC 的功能重點，自適應降載、自適應熔斷、prometheus 服務指標收集等功能都在這裡實現

Interceptor 模組

gRPC 提供了攔截器功能，主要是對請求前後進行額外處理的攔截操作，其中攔截器包含客戶端攔截器和服務端攔截器，又分為一元 (Unary) 攔截器和流 (Stream) 攔截器，這裡我們主要講解一元攔截器，流攔截器同理。

客戶端攔截器定義如下:

type UnaryClientInterceptor func(ctx context.Context, method string, req, reply interface{}, cc *ClientConn, invoker UnaryInvoker, opts ...CallOption) error

其中 method 為方法名，req，reply 分別為請求和響應引數，cc 為客戶端連線物件，invoker 引數是真正執行 rpc 方法的 handler 其實在攔截器中被呼叫執行

服務端攔截器定義如下:

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

其中 req 為請求引數，info 中包含了請求方法屬性，handler 為對 server 端方法的包裝，也是在攔截器中被呼叫執行

zRPC 中內建了豐富的攔截器，其中包括自適應降載、自適應熔斷、許可權驗證、prometheus 指標收集等等，由於攔截器較多，篇幅有限沒法所有的攔截器給大家一一解析，這裡我們主要分析兩個，自適應熔斷和 prometheus 服務監控指標收集：

內建攔截器分析

自適應熔斷 (breaker)

當客戶端向服務端發起請求，客戶端會記錄服務端返回的錯誤，當錯誤達到一定的比例，客戶端會自行的進行熔斷處理，丟棄掉一定比例的請求以保護下游依賴，且可以自動恢復。zRPC 中自適應熔斷遵循《Google SRE》中過載保護策略，演算法如下：

requests: 總請求數量

accepts: 正常請求數量

K: 倍值 (Google SRE 推薦值為 2)

可以通過修改 K 的值來修改熔斷髮生的激程式度，降低 K 的值會使得自適應熔斷演算法更加激進，增加 K 的值則自適應熔斷演算法變得不再那麼激進

熔斷攔截器定義如下：

func BreakerInterceptor(ctx context.Context, method string, req, reply interface{},
    cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error {
    // target + 方法名
    breakerName := path.Join(cc.Target(), method)
    return breaker.DoWithAcceptable(breakerName, func() error {
        // 真正執行呼叫
        return invoker(ctx, method, req, reply, cc, opts...)
    }, codes.Acceptable)
}

accept 方法實現了 Google SRE 過載保護演算法，判斷否進行熔斷

func (b *googleBreaker) accept() error {
     // accepts為正常請求數，total為總請求數
   accepts, total := b.history()
   weightedAccepts := b.k * float64(accepts)
   // 演算法實現
   dropRatio := math.Max(0, (float64(total-protection)-weightedAccepts)/float64(total+1))
   if dropRatio <= 0 {
      return nil
   }
     // 是否超過比例
   if b.proba.TrueOnProba(dropRatio) {
      return ErrServiceUnavailable
   }

   return nil
}

doReq 方法首先判斷是否熔斷，滿足條件直接返回 error(circuit breaker is open)，不滿足條件則對請求數進行累加

func (b *googleBreaker) doReq(req func() error, fallback func(err error) error, acceptable Acceptable) error {
   if err := b.accept(); err != nil {
      if fallback != nil {
         return fallback(err)
      } else {
         return err
      }
   }

   defer func() {
      if e := recover(); e != nil {
         b.markFailure()
         panic(e)
      }
   }()

   // 此處執行RPC請求
   err := req()
   // 正常請求total和accepts都會加1
   if acceptable(err) {
      b.markSuccess()
   } else {
     // 請求失敗只有total會加1
      b.markFailure()
   }

   return err
}

prometheus 指標收集

服務監控是瞭解服務當前執行狀態以及變化趨勢的重要手段，監控依賴於服務指標的收集，通過 prometheus 進行監控指標的收集是業界主流方案，zRPC 中也採用了 prometheus 來進行指標的收集

prometheus 攔截器定義如下：

這個攔截器主要是對服務的監控指標進行收集，這裡主要是對 RPC 方法的耗時和呼叫錯誤進行收集，這裡主要使用了 Prometheus 的 Histogram 和 Counter 資料型別

func UnaryPrometheusInterceptor() grpc.UnaryServerInterceptor {
    return func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (
        interface{}, error) {
    // 執行前記錄一個時間
        startTime := timex.Now()
        resp, err := handler(ctx, req)
    // 執行後通過Since算出執行該呼叫的耗時
        metricServerReqDur.Observe(int64(timex.Since(startTime)/time.Millisecond), info.FullMethod)
    // 方法對應的錯誤碼
        metricServerReqCodeTotal.Inc(info.FullMethod, strconv.Itoa(int(status.Code(err))))
        return resp, err
    }
}

新增自定義攔截器

除了內建了豐富的攔截器之外，zRPC 同時支援新增自定義攔截器

Client 端通過 AddInterceptor 方法新增一元攔截器：

func (rc *RpcClient) AddInterceptor(interceptor grpc.UnaryClientInterceptor) {
    rc.client.AddInterceptor(interceptor)
}

Server 端通過 AddUnaryInterceptors 方法新增一元攔截器：

func (rs *RpcServer) AddUnaryInterceptors(interceptors ...grpc.UnaryServerInterceptor) {
    rs.server.AddUnaryInterceptors(interceptors...)
}

resolver 模組

zRPC 服務註冊架構圖：

zRPC 中自定義了 resolver 模組，用來實現服務的註冊功能。zRPC 底層依賴 gRPC，在 gRPC 中要想自定義 resolver 需要實現 resolver.Builder 介面：

type Builder interface {
    Build(target Target, cc ClientConn, opts BuildOptions) (Resolver, error)
    Scheme() string
}

其中 Build 方法返回 Resolver，Resolver 定義如下：

type Resolver interface {
    ResolveNow(ResolveNowOptions)
    Close()
}

在 zRPC 中定義了兩種 resolver，direct 和 discov，這裡我們主要分析基於 etcd 做服務發現的 discov，自定義的 resolver 需要通過 gRPC 提供了 Register 方法進行註冊程式碼如下：

func RegisterResolver() {
    resolver.Register(&dirBuilder)
    resolver.Register(&disBuilder)
}

當我們啟動我們的 zRPC Server 的時候，呼叫 Start 方法，會像 etcd 中註冊對應的服務地址：

func (ags keepAliveServer) Start(fn RegisterFn) error {
  // 註冊服務地址
    if err := ags.registerEtcd(); err != nil {
        return err
    }
    // 啟動服務
    return ags.Server.Start(fn)
}

當我們啟動 zRPC 客戶端的時候，在 gRPC 內部會呼叫我們自定義 resolver 的 Build 方法，zRPC 通過在 Build 方法內呼叫執行了 resolver.ClientConn 的 UpdateState 方法，該方法會把服務地址註冊到 gRPC 客戶端內部：

func (d *discovBuilder) Build(target resolver.Target, cc resolver.ClientConn, opts resolver.BuildOptions) (
    resolver.Resolver, error) {
    hosts := strings.FieldsFunc(target.Authority, func(r rune) bool {
        return r == EndpointSepChar
    })
  // 服務發現
    sub, err := discov.NewSubscriber(hosts, target.Endpoint)
    if err != nil {
        return nil, err
    }

    update := func() {
        var addrs []resolver.Address
        for _, val := range subset(sub.Values(), subsetSize) {
            addrs = append(addrs, resolver.Address{
                Addr: val,
            })
        }
    // 向gRPC註冊服務地址
        cc.UpdateState(resolver.State{
            Addresses: addrs,
        })
    }
  // 監聽
    sub.AddListener(update)
    update()
    // 返回自定義的resolver.Resolver
    return &nopResolver{cc: cc}, nil
}

在 discov 中，通過呼叫 load 方法從 etcd 中獲取指定服務的所有地址：

func (c *cluster) load(cli EtcdClient, key string) {
    var resp *clientv3.GetResponse
    for {
        var err error
        ctx, cancel := context.WithTimeout(c.context(cli), RequestTimeout)
    // 從etcd中獲取指定服務的所有地址
        resp, err = cli.Get(ctx, makeKeyPrefix(key), clientv3.WithPrefix())
        cancel()
        if err == nil {
            break
        }

        logx.Error(err)
        time.Sleep(coolDownInterval)
    }

    var kvs []KV
    c.lock.Lock()
    for _, ev := range resp.Kvs {
        kvs = append(kvs, KV{
            Key: string(ev.Key),
            Val: string(ev.Value),
        })
    }
    c.lock.Unlock()

    c.handleChanges(key, kvs)
}

並通過 watch 監聽服務地址的變化：

func (c *cluster) watch(cli EtcdClient, key string) {
    rch := cli.Watch(clientv3.WithRequireLeader(c.context(cli)), makeKeyPrefix(key), clientv3.WithPrefix())
    for {
        select {
        case wresp, ok := <-rch:
            if !ok {
                logx.Error("etcd monitor chan has been closed")
                return
            }
            if wresp.Canceled {
                logx.Error("etcd monitor chan has been canceled")
                return
            }
            if wresp.Err() != nil {
                logx.Error(fmt.Sprintf("etcd monitor chan error: %v", wresp.Err()))
                return
            }
            // 監聽變化通知更新
            c.handleWatchEvents(key, wresp.Events)
        case <-c.done:
            return
        }
    }
}

這部分主要介紹了 zRPC 中是如何自定義的 resolver，以及基於 etcd 的服務發現原理，通過這部分的介紹大家可以瞭解到 zRPC 內部服務註冊發現的原理，原始碼比較多隻是粗略的從整個流程上進行了分析，如果大家對 zRPC 的原始碼比較感興趣可以自行進行學習

balancer 模組

負載均衡原理圖：

避免過載是負載均衡策略的一個重要指標，好的負載均衡演算法能很好的平衡服務端資源。常用的負載均衡演算法有輪訓、隨機、Hash、加權輪訓等。但為了應對各種複雜的場景，簡單的負載均衡演算法往往表現的不夠好，比如輪訓演算法當服務響應時間變長就很容易導致負載不再平衡， 因此 zRPC 中自定義了預設負載均衡演算法 P2C(Power of Two Choices)，和 resolver 類似，要想自定義 balancer 也需要實現 gRPC 定義的 balancer.Builder 介面，由於和 resolver 類似這裡不再帶大家一起分析如何自定義 balancer，感興趣的朋友可以檢視 gRPC 相關的文件來進行學習

注意，zRPC 是在客戶端進行負載均衡，常見的還有通過 nginx 中間代理的方式

zRPC 框架中預設的負載均衡演算法為 P2C，該演算法的主要思想是：

1. 從可用節點列表中做兩次隨機選擇操作，得到節點 A、B
2. 比較 A、B 兩個節點，選出負載最低的節點作為被選中的節點

虛擬碼如下：

主要演算法邏輯在 Pick 方法中實現：

func (p *p2cPicker) Pick(ctx context.Context, info balancer.PickInfo) (
    conn balancer.SubConn, done func(balancer.DoneInfo), err error) {
    p.lock.Lock()
    defer p.lock.Unlock()

    var chosen *subConn
    switch len(p.conns) {
    case 0:
        return nil, nil, balancer.ErrNoSubConnAvailable
    case 1:
        chosen = p.choose(p.conns[0], nil)
    case 2:
        chosen = p.choose(p.conns[0], p.conns[1])
    default:
        var node1, node2 *subConn
        for i := 0; i < pickTimes; i++ {
      // 隨機數
            a := p.r.Intn(len(p.conns))
            b := p.r.Intn(len(p.conns) - 1)
            if b >= a {
                b++
            }
      // 隨機獲取所有節點中的兩個節點
            node1 = p.conns[a]
            node2 = p.conns[b]
      // 效驗節點是否健康
            if node1.healthy() && node2.healthy() {
                break
            }
        }
        // 選擇其中一個節點
        chosen = p.choose(node1, node2)
    }

    atomic.AddInt64(&chosen.inflight, 1)
    atomic.AddInt64(&chosen.requests, 1)
    return chosen.conn, p.buildDoneFunc(chosen), nil
}

choose 方法對隨機選擇出來的節點進行負載比較從而最終確定選擇哪個節點

func (p *p2cPicker) choose(c1, c2 *subConn) *subConn {
    start := int64(timex.Now())
    if c2 == nil {
        atomic.StoreInt64(&c1.pick, start)
        return c1
    }

    if c1.load() > c2.load() {
        c1, c2 = c2, c1
    }

    pick := atomic.LoadInt64(&c2.pick)
    if start-pick > forcePick && atomic.CompareAndSwapInt64(&c2.pick, pick, start) {
        return c2
    } else {
        atomic.StoreInt64(&c1.pick, start)
        return c1
    }
}

上面主要介紹了 zRPC 預設負載均衡演算法的設計思想和程式碼實現，那自定義的 balancer 是如何註冊到 gRPC 的呢，resolver 提供了 Register 方法來進行註冊，同樣 balancer 也提供了 Register 方法來進行註冊：

func init() {
    balancer.Register(newBuilder())
}

func newBuilder() balancer.Builder {
    return base.NewBalancerBuilder(Name, new(p2cPickerBuilder))
}

註冊 balancer 之後 gRPC 怎麼知道使用哪個 balancer 呢？這裡我們需要使用配置項進行配置，在 NewClient 的時候通過 grpc.WithBalancerName 方法進行配置：

func NewClient(target string, opts ...ClientOption) (*client, error) {
    var cli client
    opts = append(opts, WithDialOption(grpc.WithBalancerName(p2c.Name)))
    if err := cli.dial(target, opts...); err != nil {
        return nil, err
    }

    return &cli, nil
}

這部分主要介紹了 zRPC 中內中的負載均衡演算法的實現原理以及具體的實現方式，之後介紹了 zRPC 是如何註冊自定義的 balancer 以及如何選擇自定義的 balancer，通過這部分大家應該對負載均衡有了更進一步的認識

總結

首先，介紹了 zRPC 的基本使用方法，可以看到 zRPC 使用非常簡單，只需要少數幾行程式碼就可以構建高效能和自帶服務治理能力的 RPC 服務，當然這裡沒有面面俱到的介紹 zRPC 的基本使用，大家可以檢視相關文件進行學習

接著，介紹了 zRPC 的幾個重要組成模組以及其實現原理，並分析了部分原始碼。攔截器模組是整個 zRPC 的重點，其中內建了豐富的功能，像熔斷、監控、降載等等也是構建高可用微服務必不可少的。resolver 和 balancer 模組自定義了 gRPC 的 resolver 和 balancer，通過該部分可以瞭解到整個服務註冊與發現的原理以及如何構建自己的服務發現系統，同時自定義負載均衡演算法也變得不再神祕

最後，zRPC 是一個經歷過各種工程實踐的 RPC 框架，不論是想要用於生產還是學習其中的設計模式都是一個不可多得的開源專案。希望通過這篇文章的介紹大家能夠進一步瞭解 zRPC

專案地址

https://github.com/tal-tech/go-zero

框架地址

https://github.com/tal-tech/go-zero/tree/master/zrpc

文件地址

https://www.yuque.com/tal-tech/go-zero/rhakzy

微信交流群