C++博客-金庆的专栏-随笔分类-3. Golang

net.LookupSRV()查询k8s无头服务

金庆 — Mon, 22 Feb 2021 08:17:00 GMT

net.LookupSRV()查询k8s无头服务

(金庆的专栏 2021.2)

如下创建 StatefulSet 和 Headless Service: test.yaml

```
apiVersion: v1
kind: Service
metadata:
name: headless-svc
labels:
    app: headless-svc
spec:
ports:
- port: 80
    name: aaaa
- port: 20080
    name: bbbb
selector:
    app: headless-pod
clusterIP: None

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: statefulset-test
spec:
serviceName: headless-svc
replicas: 3
selector:
    matchLabels:
      app: headless-pod
template:
    metadata:
      labels:
        app: headless-pod
    spec:
      containers:
      - name: myhttpd
        image: httpd
        ports:
        - containerPort: 80
        - containerPort: 20080
```

部署：
```
kubectl apply -f test.yaml
```

然后开一个 shell:
```
kubectl run mygolang -it --image golang -- bash
If you don't see a command prompt, try pressing enter.
root@mygolang:/go#
```

先装个 vim:
```
apt install vim
```

然后写个 golang 测试程序，向 DNS 查询 bbbb 服务的地址与端口：
```
root@mygolang:/jinqing# cat main.go
package main

import (
    "fmt"
    "github.com/davecgh/go-spew/spew"
    "net"
)

func main() {
    cname, addresses, err := net.LookupSRV("bbbb", "tcp", "headless-svc.default.svc.cluster.local")
    if err != nil {
        fmt.Printf("failed: %s\n", err)
    }
    fmt.Printf("cname: %s\n", cname)
    spew.Dump(addresses)
}
root@mygolang:/jinqing#
```

运行结果为：
```
cname: _bbbb._tcp.headless-svc.default.svc.cluster.local.
([]*net.SRV) (len=3 cap=4) {
(*net.SRV)(0xc00000e220)({
Target: (string) (len=58) "statefulset-test-0.headless-svc.default.svc.cluster.local.",
Port: (uint16) 20080,
Priority: (uint16) 0,
Weight: (uint16) 33
}),
(*net.SRV)(0xc00000e1e0)({
Target: (string) (len=58) "statefulset-test-2.headless-svc.default.svc.cluster.local.",
Port: (uint16) 20080,
Priority: (uint16) 0,
Weight: (uint16) 33
}),
(*net.SRV)(0xc00000e200)({
Target: (string) (len=58) "statefulset-test-1.headless-svc.default.svc.cluster.local.",
Port: (uint16) 20080,
Priority: (uint16) 0,
Weight: (uint16) 33
})
}
```

多次运行发现结果项次序固定，并没有按权重随机。

Service yaml 定义中，必须为每个端口命名，不然没法查询。

```
    cname, addresses, err := net.LookupSRV("bbbb", "tcp", "headless-svc.default.svc.cluster.local")
```
可利用默认域名后缀简写为
```
    cname, addresses, err := net.LookupSRV("bbbb", "tcp", "headless-svc")
```
输出相同。

金庆 2021-02-22 16:17 发表评论

rpc应答太快造成请求超时

金庆 — Thu, 17 Sep 2020 07:59:00 GMT

rpc应答太快造成请求超时

(金庆的专栏 2020.9)

在压测中发现总有几个请求超时，超时时长设大也会有，而成功的请求延时远小于超时时间。
查错的第一方向是查网络库中有消息丢失。
跟踪所有消息，发现超时的消息应该是正常处理并返回了。
于是查接收应答消息后的处理，最终找到代码：
```go
func (c *Client) onRpcRet(cbIndex uint32, ...) {
   ii, ok := c.callbacks.Load(cbIndex)
   if !ok {
        // logger.Errorf("onRpcRet can not find cbIndex %d", cbIndex) // 可能是超时已删
        return
   }
```
打开日志，发现超时的请求对应有该条错误日志。
此处回调不存在的情况，正常是先超时删除回调，然后再收到应答。
现在是先收到了应答，发现找不到回调，然后过了一段时间会被判为超时无响应。

将下面代码换个次序就好了：
```go
   if err := c.Session.Send(msg); err != nil {
        ...
        return
   }
   c.callbacks.Store(cbIndex, ...)
```
改为
```go
   // 必须先设回调，然后发送，因为应答可能会很快
   c.callbacks.Store(cbIndex, ...)
   if err := c.Session.Send(msg); err...
```

压测时因为加压机CPU是满负载运转，所以 Send() 和 Store() 之间可能会间隔数毫秒，
足够 rpc 请求处理完成并返回，而应答返回时回调还没设置。

先 Send() 后 Store() 写代码会稍微简单点，因为 Send() 失败后可以直接返回。
先 Store() 后 Send() 时，Send() 失败则需要相应 Delete().

金庆 2020-09-17 15:59 发表评论

golang各数值类型的最大最小值

金庆 — Fri, 11 Sep 2020 06:55:00 GMT

# golang各数值类型的最大最小值

(金庆的专栏 2020.9)

golang 的 math 包已经定义了以下常量：

Constants

```
const (
    E   = 2.71828182845904523536028747135266249775724709369995957496696763 // https://oeis.org/A001113
    Pi = 3.14159265358979323846264338327950288419716939937510582097494459 // https://oeis.org/A000796
    Phi = 1.61803398874989484820458683436563811772030917980576286213544862 // https://oeis.org/A001622

    Sqrt2   = 1.41421356237309504880168872420969807856967187537694807317667974 // https://oeis.org/A002193
    SqrtE   = 1.64872127070012814684865078781416357165377610071014801157507931 // https://oeis.org/A019774
    SqrtPi = 1.77245385090551602729816748334114518279754945612238712821380779 // https://oeis.org/A002161
    SqrtPhi = 1.27201964951406896425242246173749149171560804184009624861664038 // https://oeis.org/A139339

    Ln2    = 0.693147180559945309417232121458176568075500134360255254120680009 // https://oeis.org/A002162
    Log2E = 1 / Ln2
    Ln10   = 2.30258509299404568401799145468436420760110148862877297603332790 // https://oeis.org/A002392
    Log10E = 1 / Ln10
)
```

Mathematical constants.

```
const (
    MaxFloat32             = 3.40282346638528859811704183484516925440e+38 // 2**127 * (2**24 - 1) / 2**23
    SmallestNonzeroFloat32 = 1.401298464324817070923729583289916131280e-45 // 1 / 2**(127 - 1 + 23)

    MaxFloat64             = 1.797693134862315708145274237317043567981e+308 // 2**1023 * (2**53 - 1) / 2**52
    SmallestNonzeroFloat64 = 4.940656458412465441765687928682213723651e-324 // 1 / 2**(1023 - 1 + 52)
)
```

Floating-point limit values. Max is the largest finite value representable by the type. SmallestNonzero is the smallest positive, non-zero value representable by the type.

```
const (
    MaxInt8   = 1<<7 - 1
    MinInt8   = -1 << 7
    MaxInt16 = 1<<15 - 1
    MinInt16 = -1 << 15
    MaxInt32 = 1<<31 - 1
    MinInt32 = -1 << 31
    MaxInt64 = 1<<63 - 1
    MinInt64 = -1 << 63
    MaxUint8 = 1<<8 - 1
    MaxUint16 = 1<<16 - 1
    MaxUint32 = 1<<32 - 1
    MaxUint64 = 1<<64 - 1
)
```
Integer limit values.

金庆 2020-09-11 14:55 发表评论

参数太灵活容易出错

金庆 — Fri, 24 Jul 2020 01:15:00 GMT

参数太灵活容易出错

(金庆的专栏 2020.7)

golang中可以将参数类型设为 interface{}, 这样就可以传入任意类型的参数，
和 C++ 中 void* 的作用相似。
但是这种万能类型应该尽量少用，尽量使用具体的类型，或者使用一个具体的接口类型。
主要的原因是, 让编译期的类型检查挡住编码错误，减少运行期的错误。

例如，go-mongo-driver 有个创建索引的参数：
```
type IndexModel struct {
    // A document describing which keys should be used for the index. It cannot be nil.
    // This must be an order-preserving type such as bson.D. Map types such as bson.M are not valid.
    Keys interface{}
    ...
}
```

其中 Keys 可以是任意类型，如 1234, "abcd", 当然不符合索引要求的类型会返回失败。
但是 bson.M 类型，会创建索引成功，但是索引的次序会有错误。
注释中已指出，不要用 bson.M, 应该使用 bson.D.

正确的 Keys 如下，表示复合索引 (field1, field2)，1表示正序，-1则反序：
```
    indexModel.Keys := bson.D{{"field1", 1}, {"field2", 1}}
```

如果使用 bson.M, 实际上是个 map：
```
    indexModel.Keys := bson.M{"field1"：1, "field2": 1}
```
因为 map 成员的次序不定，最后创建的索引可能是 (field1, field2)，也可能是 (field2, field1)。

此处类型允许 interface{} 的想法是，允许任意类型，会 bson 编码后传给 mongo 服务器，并不会进行类型检查。
这种灵活性非常容易造成错误，并且如何使用也不明确, 仅靠注释作用很小。

金庆 2020-07-24 09:15 发表评论

grpc外部负载均衡器测试

金庆 — Fri, 17 Apr 2020 02:08:00 GMT

# grpc外部负载均衡器测试

(金庆的专栏 2020.4)

grpc 对每个请求进行负载均衡。负载均衡的方式有：

* 代理模式
* 客户端实现
* 外部负载均衡

参考：gRPC LB https://blog.csdn.net/xiaojia1100/article/details/78842295

gRPC 中负载均衡的主要机制是外部负载均衡。

gRPC 定义了外部负载均衡服务的接口：https://github.com/grpc/grpc/tree/master/src/proto/grpc/lb/v1

* load_balancer.proto 客户端向 lb 服查询后端列表
* load_reporter.proto lb 服向后端服查询负载

https://github.com/bsm/grpclb 实现了一个 grpc 的外部负载均衡服。
因为其实现早于负载均衡服的接口规范，所以接口定义与 grpc 规范不同。
见 issue#26: https://github.com/bsm/grpclb/issues/26#issuecomment-613873655
grpclb 目前仅支持 consul 服务发现。

标准的 grpclb 实现目前好像只有 https://github.com/joa/jawlb。
jawlb 通过 Kubernetes API 来发现服务。

以下测试 grpc 客户端从 jawlb 服查询服务器列表，然后请求服务。
首先在本机开了多个 greeter 服实例，端口不同。
然后更改 greeter 客户端，不要直接连 greeter 服地址，而是配一个 jawlb 服地址。
同时更改 jawlb, 删除服务发现，改为固定输出本机服务列表，定时切换。

greeter 是指 grpc-go 中的例子：grpc-go\examples\helloworld\greeter

## greeter 服更改

添加参数指定服务端口。

```
package main

import (
    "fmt"
    "log"
    "net"

    "github.com/spf13/pflag"
    "github.com/spf13/viper"
    "golang.org/x/net/context"
    "google.golang.org/grpc"
    pb "google.golang.org/grpc/examples/helloworld/helloworld"
)

// GreeterServer is used to implement helloworld.GreeterServer.
type GreeterServer struct {
}

// SayHello implements helloworld.GreeterServer
func (s *GreeterServer) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {
    msg := fmt.Sprintf("Hello %s from server-%d", in.Name, viper.GetInt("port"))
    return &pb.HelloReply{Message: msg}, nil
}

func main() {
    pflag.Int("port", 8000, "server bind port")
    pflag.Parse()
    viper.BindPFlags(pflag.CommandLine)
    port := viper.GetInt("port")

    addr := fmt.Sprintf(":%d", port)
    lis, err := net.Listen("tcp", addr)
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }
    s := grpc.NewServer()
    pb.RegisterGreeterServer(s, &GreeterServer{})
    s.Serve(lis)
}
```

## greeter 客户端更改
```
package main

import (
    "context"
    "log"
    "os"
    "time"

    "github.com/sirupsen/logrus"
    "google.golang.org/grpc"
    _ "google.golang.org/grpc/balancer/grpclb"
    pb "google.golang.org/grpc/examples/helloworld/helloworld"
    "google.golang.org/grpc/grpclog"
    "google.golang.org/grpc/resolver"
    "google.golang.org/grpc/resolver/manual"
)

const (
    defaultName = "world"
)

func init() {
    grpclog.SetLogger(logrus.New())
}

func main() {
    rb := manual.NewBuilderWithScheme("whatever")
    rb.InitialState(resolver.State{Addresses: []resolver.Address{
        {Addr: "127.0.0.1:8888", Type: resolver.GRPCLB},
    }})

    conn, err := grpc.Dial("whatever:///this-gets-overwritten", grpc.WithInsecure(), grpc.WithBlock(),
        grpc.WithResolvers(rb))
    if err != nil {
        log.Fatalf("did not connect: %v", err)
    }
    defer conn.Close()
    c := pb.NewGreeterClient(conn)

    name := defaultName
    if len(os.Args) > 1 {
        name = os.Args[1]
    }

    for {
        ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
        r, err := c.SayHello(ctx, &pb.HelloRequest{Name: name})
        cancel()

        if err != nil {
            log.Fatalf("could not greet: %v", err)
            time.Sleep(time.Second)
            continue
        }

        log.Printf("Greeting: %s", r.GetMessage())
        time.Sleep(time.Second)
    }
}
```

有以下更改：
* import _ "google.golang.org/grpc/balancer/grpclb"
* grpc.Dial("whatever:///this-gets-overwritten", grpc.WithResolvers(rb))
    + 采用一个自定义解析器，用来获取 jawlb 地址
    + Scheme("whatever") 可以任意，用作解析器名字
    + 目标 this-gets-overwritten 可以任意，因为 jawlb 忽略了该名字
    + 127.0.0.1:8888 是 jawlb 地址
* 改为每秒请求一次

正常的 grpclb 是在 DNS 中设置 SRV 记录，
此处测试避免设置 DNS, 采用了一个自定义解析器，
代码上多了几行。
用 DNS 设置的好处是, 可以直接解析为后端 IP, 也可以添加 grpclb, 代码上如同直接连接后端：
```
    conn, err := grpc.Dial("dns:///myservice.domain.com", grpc.WithInsecure())
```

## jawlb 更改

### main.go

删除所有配置，改为固定本机 8888 端口监听。

* 删除 `envconfig.MustProcess("JAWLB", &cfg)`
* listen() 改为
    ```
    func listen() (conn net.Listener, err error) {
        conn, err = net.Listen("tcp", ":8888")
        return
    }
    ```

### watch.go

```
package main

import (
    "context"
    "fmt"
    "net"
    "time"
)

func watchService(ctx context.Context) (_ <-chan ServerList, err error) {
    ch := make(chan ServerList)

    go func() {
        ticker := time.NewTicker(10 * time.Second)
        i := 0
        for {
            select {
            case <-ctx.Done():
                ticker.Stop()
                close(ch)
                return
            case <-ticker.C:
                i += 1
                fmt.Printf("i = %d\n", i)
                ports := []int32{8010, 8020}
                var servers []Server
                for _, port := range ports {
                    servers = append(servers, Server{IP: net.ParseIP("127.0.0.1"), Port: port + int32(i%2)})
                }
                ch <- servers
            } // select
        } // for
    }()

    return ch, nil
}
```

删除所有服务发现代码，改为每10秒切换端口：8010,8020 <-> 8011,8021

## 运行

### jawlb
```
λ jawlb.exe
2020/04/16 15:35:17 waiting for TERM
i = 1
2020/04/16 15:35:27 endpoints:
2020/04/16 15:35:27     127.0.0.1:8011
2020/04/16 15:35:27     127.0.0.1:8021
i = 2
2020/04/16 15:35:37 endpoints:
2020/04/16 15:35:37     127.0.0.1:8010
2020/04/16 15:35:37     127.0.0.1:8020
```

### server

运行 4 个实例：
```
server --port 8010
server --port 8020
server --port 8011
server --port 8021
```

### client

```
λ client
INFO[0002] lbBalancer: handle SubConn state change: 0xc00008a590, CONNECTING
INFO[0002] Channel Connectivity change to CONNECTING
INFO[0002] lbBalancer: handle SubConn state change: 0xc00008a5f0, CONNECTING
INFO[0002] Subchannel picks a new address "127.0.0.1:8021" to connect
INFO[0002] Subchannel Connectivity change to READY
INFO[0002] lbBalancer: handle SubConn state change: 0xc00008a590, READY
INFO[0002] Channel Connectivity change to READY
INFO[0002] Subchannel Connectivity change to READY
INFO[0002] lbBalancer: handle SubConn state change: 0xc00008a5f0, READY
2020/04/16 15:37:47 Greeting: Hello world from server-8021
2020/04/16 15:37:48 Greeting: Hello world from server-8011
2020/04/16 15:37:49 Greeting: Hello world from server-8021
2020/04/16 15:37:50 Greeting: Hello world from server-8011
2020/04/16 15:37:51 Greeting: Hello world from server-8021
2020/04/16 15:37:52 Greeting: Hello world from server-8011
2020/04/16 15:37:53 Greeting: Hello world from server-8021
2020/04/16 15:37:54 Greeting: Hello world from server-8011
2020/04/16 15:37:55 Greeting: Hello world from server-8021
2020/04/16 15:37:56 Greeting: Hello world from server-8011
INFO[0012] lbBalancer: processing server list: servers: servers:
INFO[0012] lbBalancer: server list entry[0]: ipStr:|127.0.0.1|, port:|8020|, load balancer token:||
INFO[0012] lbBalancer: server list entry[1]: ipStr:|127.0.0.1|, port:|8010|, load balancer token:||
2020/04/16 15:37:57 Greeting: Hello world from server-8020
2020/04/16 15:37:58 Greeting: Hello world from server-8010
2020/04/16 15:37:59 Greeting: Hello world from server-8020
2020/04/16 15:38:00 Greeting: Hello world from server-8010
2020/04/16 15:38:01 Greeting: Hello world from server-8020
2020/04/16 15:38:02 Greeting: Hello world from server-8010
2020/04/16 15:38:03 Greeting: Hello world from server-8020
2020/04/16 15:38:04 Greeting: Hello world from server-8010
2020/04/16 15:38:05 Greeting: Hello world from server-8020
2020/04/16 15:38:06 Greeting: Hello world from server-8010
INFO[0022] lbBalancer: processing server list: servers: servers:
INFO[0022] lbBalancer: server list entry[0]: ipStr:|127.0.0.1|, port:|8021|, load balancer token:||
INFO[0022] lbBalancer: server list entry[1]: ipStr:|127.0.0.1|, port:|8011|, load balancer token:||
2020/04/16 15:38:07 Greeting: Hello world from server-8011
2020/04/16 15:38:08 Greeting: Hello world from server-8021
2020/04/16 15:38:09 Greeting: Hello world from server-8011
```

## 结论

客户端应用一个自定义 resolver 解析 "whatever:///this-gets-overwritten"，
获取到 `{Addr: "127.0.0.1:8888", Type: resolver.GRPCLB}`,
知道这是一个 grpclb，于是按 load_balancer.proto 的定义查询 jawlb 来获取后端地址列表。

jawlb 每 10s 更新一次服务器列表，每次输出多个地址。客户端在多个地址间轮换请求。

## 其他测试

* 不开 jawlb，客户端将无法成功请求，直到 jawlb 开启才成功
* 中途关闭 jawlb, 请求仍会成功，但是保持为最后的服务器列表
    + 同时会不断尝试重连 jawlb, 但是重连成功后没有切换服务，应该是个错误
* Dial() 不加 grpc.WithBlock() 参数, 报错：all SubConns are in TransientFailure

```
λ client
INFO[0000] parsed scheme: "whatever"
INFO[0000] ccResolverWrapper: sending update to cc: {[{127.0.0.1:8888 1 }] }
INFO[0000] ClientConn switching balancer to "grpclb"
INFO[0000] Channel switches to new LB policy "grpclb"
INFO[0000] lbBalancer: UpdateClientConnState: {ResolverState:{Addresses:[{Addr:127.0.0.1:8888 ServerName: Attributes: Type:1 Metadata:}] ServiceConfig: Attributes:} BalancerConfig:}
INFO[0000] parsed scheme: "grpclb-internal"
INFO[0000] ccResolverWrapper: sending update to cc: {[{127.0.0.1:8888 0 }] }
INFO[0000] ClientConn switching balancer to "pick_first"
INFO[0000] Channel switches to new LB policy "pick_first"
INFO[0000] Subchannel Connectivity change to CONNECTING
INFO[0000] blockingPicker: the picked transport is not ready, loop back to repick
INFO[0000] pickfirstBalancer: HandleSubConnStateChange: 0xc00003fb10, {CONNECTING }
INFO[0000] Channel Connectivity change to CONNECTING
INFO[0000] Subchannel picks a new address "127.0.0.1:8888" to connect
INFO[0000] CPU time info is unavailable on non-linux or appengine environment.
INFO[0000] Subchannel Connectivity change to READY
INFO[0000] pickfirstBalancer: HandleSubConnStateChange: 0xc00003fb10, {READY }
INFO[0000] Channel Connectivity change to READY
INFO[0000] lbBalancer: processing server list: servers: servers:
INFO[0000] lbBalancer: server list entry[0]: ipStr:|127.0.0.1|, port:|8010|, load balancer token:||
INFO[0000] lbBalancer: server list entry[1]: ipStr:|127.0.0.1|, port:|8020|, load balancer token:||
INFO[0000] Subchannel Connectivity change to CONNECTING
INFO[0000] Subchannel Connectivity change to CONNECTING
INFO[0000] Channel Connectivity change to TRANSIENT_FAILURE
INFO[0000] lbBalancer: handle SubConn state change: 0xc00008a220, CONNECTING
INFO[0000] Channel Connectivity change to CONNECTING
INFO[0000] lbBalancer: handle SubConn state change: 0xc00008a280, CONNECTING
2020/04/16 16:40:06 could not greet: rpc error: code = Unavailable desc = all SubConns are in TransientFailure
```

金庆 2020-04-17 10:08 发表评论

数组make参数错误

金庆 — Thu, 19 Mar 2020 05:38:00 GMT

# 数组make参数错误

(金庆的专栏 2020.3)

用 mgo 的 Bulk 接口操作 mongodb 的代码，在 mongodb 4.2 正常，
而连 mongodb 2.6 报错：
```
error parsing element 0 of field documents :: caused by :: wrong type for '0' field, expected object, found 0: null
```

代码如下：
```
func (u *Util) AddUsers(userIDs []int) error {
    docs := make([]interface{}, len(userIDs))
    for _, userID := range userIDs {
        docs = append(docs, dbdoc.UsersDoc{
            UserID:     userID,
        })
    }
    bulk := u.c().Bulk()
    bulk.Insert(docs...)
    _, err := bulk.Run()
    return err
}
```

试着改成如下调用就成功：
```
func (u *Util) AddUsers(userIDs []int) error {
    bulk := u.c().Bulk()
    for _, userID := range userIDs {
        bulk.Insert(dbdoc.UsersDoc{
            UserID:     userID,
        })
    }
    _, err := bulk.Run()
    return err
}
```

而 Insert() 无论是多个还是单个参数，底层实现是一样的。

输入单个如 []int{123} 还是出错.
将 Insert(docs...) 改成 Insert(docs[0]) 时发现元素为空。
最终找到了错误的代码行：
```
-    docs := make([]interface{}, len(userIDs))
+    docs := make([]interface{}, 0, len(userIDs))
```

高版本的mongodb结果正确应该是他忽略了空的文档。

感觉 golang make() 即可以2个参数也可以3个参数调用的设计是个错误。

金庆 2020-03-19 13:38 发表评论

go不要导出channel

金庆 — Tue, 10 Mar 2020 07:58:00 GMT

# go不要导出channel

(金庆的专栏 2020.3)

导出 channel 的包都比较难用。平常也不会将接口设计成 channel.
以下摘自：https://studygolang.com/articles/12135?fr=sidebar

不要导出并发原语

Go 提供了非常易于使用的并发原语，这也导致了它被过度的使用。我们主要担心的是 channel 和 sync package 。有的时候我们会导出一个 channel 给用户使用。另外一个常见的错误就是在使用 sync.Mutex 作为结构体字段的时候没有把它设置成私有。这并不总是很糟糕，不过在写测试的时候却需要考虑的更加全面。

当我们导出 channel 的时候我们就为这个包的用户带来了测试上的一些不必要的麻烦。你每导出一个 channel 就是在提高用户在测试时候的难度。为了写出正确的测试，用户必须考虑这些：

    什么时候数据发送完成。
    在接受数据的时候是否会发生错误。
    如果需要在包中清理使用过的channel的时候该怎么做。
    如何将 API 封装成一个接口，使我们不用直接去调用它。

金庆 2020-03-10 15:58 发表评论

go代码覆盖测试

金庆 — Sat, 29 Feb 2020 01:10:00 GMT

# go代码覆盖测试

(金庆的专栏 2020.2)

假设应用名为 MyMod, 主函数的文件为 main.go, 那就创建如下的 main_test.go 文件：
```
package main

/* 测试整个服务器。
    go test -c -covermode=count -coverpkg ./...
生成 MyMod.test.exe. 复制到 bin 目录下运行：
    MyMod.test.exe --systemTest --test.coverprofile MyMod.cov
生成代码覆盖测试结果 MyMod.cov, 需要在 go.mod 管理的目录下执行
    go tool cover -html=MyMod.cov -o MyMod.html
打开 MyMod.html 查看结果。
*/

import (
    "flag"
    "fmt"
    "testing"
)

var systemTest *bool

func init() {
    systemTest = flag.Bool("systemTest", false, "Set to true when running system tests")
}

// Test started when the test binary is started. Only calls main.
func TestSystem(t *testing.T) {
    if *systemTest {
        fmt.Println("Test system...")
        main()
    }
}
```

MyMod.cov 会积累，可加入 Git.
MyMod.cov 提交前，需对其排序，方便查看 diff.

排序脚本 sort_cov.bat 如下：
```
head -1 MyMod.cov > tmp.cov
cat MyMod.cov | sed '1d' | sort >> tmp.cov
cp tmp.cov MyMod.cov
del tmp.cov
pause
```

金庆 2020-02-29 09:10 发表评论

考察go一致性hash库

金庆 — Sat, 22 Feb 2020 04:45:00 GMT

# 考察go一致性hash库

(金庆的专栏 2020.2)

github 搜 consistent, 按星数依次察看

## stathat/consistent

Consistent hash package for Go.

688星

stathat 应该是个数据统计的云服务。consistent被认为是生产可用的。
所有文档都在 godoc. 示例和接口简洁易懂。

## lafikl/consistent

A Go library that implements Consistent Hashing and Consistent Hashing With Bounded Loads.

575 星

有界负载的一致性哈希算法

示例中是 c.GetLeast() 获取最小负载，不像是一致性hash的应用。
从代码看，应该是最近的未满载，不是最小负载。

`MaxLoad()`说明显示最大负载是自动设置为 (total_load/number_of_hosts)*1.25。

`const replicationFactor = 10`

没有一次获取多个的接口。

## serialx/hashring

Consistent hashing "hashring" implementation in golang (using the same algorithm as libketama)

367 星

是从 Python 库移植的。可以设置 weight.

示例
```
replicaCount := 3
ring := hashring.New(serversInRing)
server, _ := ring.GetNodes("my_key", replicaCount)
```
实际上是 GetN 的功能。内部实现缺少 replicationFactor

## buraksezer/consistent

Consistent hashing with bounded loads in Golang

263 星

未提供缺省hash函数。

多了一个`PartitionCount`

c.loads 仅用于查询负载，并没有用于有界负载。

结论是这个不是有界负载的一致性哈希，同时一致性哈希的实现不同寻常。

## 其他

jump hash 不能移除节点，不考虑

### dgryski/go-jump

go-jump: Jump consistent hashing

281 星

### lithammer/go-jump-consistent-hash

⚡️ Fast, minimal memory, consistent hash algorithm

138 星

金庆 2020-02-22 12:45 发表评论

将go函数指针转为接口

金庆 — Thu, 13 Feb 2020 06:38:00 GMT

# 将go函数指针转为接口

(金庆的专栏 2020.2)

golang 中的接口如下：

```
type Writer interface {
    Write func(p []byte) (n int, err error)
}
```

一般API参数要求一个接口，而不是一个函数指针，如 io.Copy() 需要输入一个 Writer 和 Reader：
```
func Copy(dst Writer, src Reader) (written int64, err error)
```

而不是这样2个函数指针：
```
func CopyWithFunc(writeFunc func([]byte) (int, error), readRunc func([]byte) (int, error)) (written int64, err error)
```

大家统一使用接口，而不是接口和函数指针混用，可以避免API复杂化。
如 io.Copy() 有2个参数，如果要支持接口和函数指针混用，就会变成4个 Copy() 重载。
golang 没有重载，就只能用4个不同的函数名。

在实际使用中，需要将函数转化成接口，才能调用 io.Copy().
如有一个函数:
```
func MyWriteFunction(p []byte) (n int, err error) {
    fmt.Print("%v",p)
    return len(p),nil
}
```
调用 io.Copy() 时需要创建一个 Writer，并将该函数指针转型为Writer后使用。
这里用 `WriteFunc` 类型实现 Writer。

```
type WriteFunc func(p []byte) (n int, err error)

func (wf WriteFunc) Write(p []byte) (n int, err error) {
    return wf(p)
}
```

WriteFunc 本身是个与 MyWriteFunction 同类型的函数类型，同时实现了 Writer 接口。
所以 MyWriteFunction 可以直接转成WriteFunc类型成为一个 Writer.
这样就可以调用 io.Copy() 了：

```
io.Copy(WriteFunc(MyWriteFunction), strings.NewReader("Hello world"))
```

参考：https://stackoverflow.com/questions/20728965/golang-function-pointer-as-a-part-of-a-struct

金庆 2020-02-13 14:38 发表评论

golang chan 关闭时的原则

金庆 — Wed, 08 Jan 2020 11:46:00 GMT

golang chan 关闭时的原则

(金庆的专栏 2020.1)

golang 程序中检测到 DATA RACE, 是 chan 关闭和发送冲突：

==================
WARNING: DATA RACE
Write at 0x00c000098010 by goroutine 68:
runtime.closechan()
      /usr/lib/golang/src/runtime/chan.go:327 +0x0
valky/common/tcp.(*Session).Close()
      /var/tmp/src/f4f4f712-7894-4d98-83dd...
valky/common/tcp.(*Session).recvloop()
      /var/tmp/src/f4f4f712-7894-4d98-83dd...

Previous read at 0x00c000098010 by goroutine 100:
runtime.chansend()
      /usr/lib/golang/src/runtime/chan.go:140 +0x0
valky/common/tcp.(*Session).Send()
      /var/tmp/src/f4f4f712-7894-4d98-83dd...
main.(*Role).sendMsg()
      /var/tmp/src/f4f4f712-7894-4d98-83dd...
==================
Found 1 data race(s)

查了一下 chan 关闭的正确做法，发现了一篇非常详细的文章：
[How to Gracefully Close Channels](https://go101.org/article/channel-closing.html)

文中指出，chan 多次关闭，或者在关闭的 chan 上发送，都会 panic.
上面的 DATA RACE 属于幸运，没有 panic。

chan 关闭时的原则是：不要在接收协程中关闭，并且，如果有多个发送者时就不要关闭chan了。

上面的DATA RACE 是在接收协程中关闭chan.

文中详细列出了多种方案关闭chan.
如果粗暴点，可以直接加个 recover. 其他方案都是要保证发送完成后再关闭。

金庆 2020-01-08 19:46 发表评论

open-match匹配流程

金庆 — Thu, 31 Jan 2019 02:21:00 GMT

# open-match匹配流程

(金庆的专栏 2019.1)

https://github.com/GoogleCloudPlatform/open-match

open-match 是一个通用的游戏匹配框架。
由游戏提供自定义的匹配算法（以docker镜像的方式提供）。

分为多个进程，各进程之间共享一个 redis.

* 前端, 接收玩家加入 redis，成功后通知玩家房间服地址
* 后端，设置一局游戏的匹配规则，设置房间服地址
* MMFOrc，启动匹配算法(MMF)
* MMF, 自定义匹配算法，读取 redis 获取玩家，匹配成功就将结果写入 redis. 仅匹配一局就退出。

游戏服中连接 open-match 的前端与后端的进程，分别称为 frontendclient 和 Director。
输入分2部份，一是玩家信息，二是对局信息。
Director 向后端输入对局信息，就会收到一个接一个的对局人员列表.
Director 需要为每个对局开房间，然后通知后端房间地址。
后端将房间地址写入 redis, 然后前端读取到房间地址，就通知 frontendclient，让玩家进入房间。

## test/cmd/frontendclient

模拟大厅服或组队服，连接前端API, 请求匹配玩家/队伍。成功后将收到房间服(DGS)的地址(Assignment)。

Player 实际上是一个队伍，其中ID字段是用空格分隔的多个ID.
虽然参数类型都是 Player, CreatePlayer() 参数为整个队伍，而 GetUpdates() 参数是单个玩家。

main() 中创建多个玩家，每个玩家调用 GetUpdates() 以获取结果，go waitForResults() 中处理结果。
waitForResult() 读取流中的匹配结果，压入 resultsChan（但好像 resultsChan 仅用于打印）。
所有玩家合并到 g 实例中，然后调用 CreatePlayer() 请求匹配。

cleanup() 调用 DeletePlayer() 来删除匹配请求，不仅需删除整个队伍，也需要删除单个玩家。

好像最后取结果没取对地方，应该从 resultChan 中获取 Assignment, 并用该地址 udpClient().

看了该示例就可以理解 frontend.proto

## examples/backendclient

MatchObject.Properties 是从 testprofile.json 读取的，应该改名为 Profile 是否更好点？
pbProfile 是 MatchObject，Profile 等同于 MatchObject?
Profile 的定义是 MMF 所需的所有参数。
`pbProfile.Properties = jsonProfile` 重复了2遍。

ListMatches()列出这个Profile的所有匹配。
收到一个匹配后，须用CreateAssignments()将房间服地址, 称为 Assignment, 发送到所有游戏客户端。

## cmd/frontendapi

CreatePlayer() 将 Player 对象写入 redis, 键值为 Player.Id, 类型为 HSET。
对 Player 的每个 attribute，添加到 ZSET 中去。
此处 Player 是一组玩家。

GetUpdates() 每隔2s读取redis, Player数据有变化时就发送。此处 Player 是单个玩家。

如果CreatePlayer()中队伍只有一个玩家，
则写入的Player与GetUpdates()中读取的玩家是同一个redis键。

## cmd/backendapi

CreateMatch() 中 profile 类型为 MatchObject, 是一个比赛的限制条件。
profile 先写入 redis, 键为 profile.Id.
`requestKey := xid() + "." + profile.Id`,
并将 requestKey 加入 redis 集合 "profileq"。
然后每2s查询 redis, 看是否有 requestKey 键出现，并返回该值。

ListMatch() 每2s调用一次 CreateMatch().

DeleteMatch() 仅仅删除 Id 这个键。

CreateAssignments() 为多个队伍设置Assignment, 即房间地址。
遍历所有Roster中的Player对象，在redis中设置Assignment.
(Assignment 更改后，会触发前端更新。)
将所有 Player.Id 从 "proposed" 移到 "deindexed"，这两个是 ZSET, 分值为加入时间。
Roster 应该是比赛中的阵营，如红方，蓝方，每个阵营中可有多个队伍。

DeleteAssignments() 仅仅遍历所有 Player 对象来删除 Assignment 字段。

## cmd/mmforc

匹配流程是由 mmforc (matchmaking function orchestrator) 控制的。

mmforc 每秒从 redis 的 profileq 中取出 100 个成员, 其中 profileq 是个set类型，
使用命令为`SPOP profileq 100`.

对每个 profile, 创建一个 k8s 任务：

```
// Kick off the job asynchrnously
go mmfunc(ctx, profile, cfg, defaultMmfImages, clientset, &pool)
```

每隔10s, 还有所有匹配任务都完成后，需要 `checkProposals`, 即创建 evaluator 任务。

profileq 中的元素 profile 为字符串，matchObjectID.profileID。
以 profileID 为键，可以从 redis 读取 profile 的内容, profile 是个 MatchObject 对象。

profile 的内容为 json 串，其中 "jsonkeys.mmfImages" 为 mmf (matchmaking function) 镜像。

如果profile读取失败，或者 mmfImages 为空，则使用默认的镜像。mmfImages 未来会支持多个镜像。

通过 MMF_* 环境变量传入各种参数.

## mmf

示例：examples\functions\golang\manual-simple

从环境变量 "MMF_PROFILE_ID" 解析出 profileID, 并向 redis 查询(HGETALL) profile，HSET 类型。

从 profile 中取 pools 字段，即匹配条件。
pools 分为多个 pool, 每个 pool 中有多个 filter, 每个 filter 向 redis 取符合的 Player.

profile 用到以下字段：

* "properties.playerPool"
json串，是一些过滤条件，如“mmr: 100-999”
* "properties.roster"
json串, 是多个队伍大小，如 “red: 4”

示例见：`examples\backendclient\profiles\testprofile.json`

### 简单匹配过程

simple mmf 的匹配过程如下：

1. 从 redis 查询 profile，获取过滤条件和各队伍大小
1. 每个过滤条件向 redis 查询，所有结果的交集为可选成员
1. 去除 ignoreList, 即最近 800s 内已匹配成功的成员，即 proposal 和 deindexed ZSET 列表。
1. 如果可选成员个数太小，则 insufficient_players 并退出
1. 分配各个队伍成员
1. 向 redis 记录结果

### 结果

profile 中添加 roster，即各阵营成员名单，存入 prososalKey.
保存不分队伍的成员名单。
然后向 "proposalq" 添加 prososalKey

### 细节

poolRosters 以 (pool名, filter attribute) 为键，值为 Player ID 列表.
保存从 redis 查询的符合条件的 Player ID.

overlaps 以 pool 名为键，保存符合该pool中所有filter的 Player ID 列表，去除 ignore list.

rosters 是 profile 中的 "properties.rosters" 字段。不知何用？
遍历 rosters, 为每个阵营的每个player找到对应pool的PlayerID, 保存到 mo.Rosters.
其中 profileRosters 好像没用。

金庆 2019-01-31 10:21 发表评论

试用 go mod

金庆 — Wed, 26 Dec 2018 02:07:00 GMT

试用 go mod

(金庆的专栏 2018.12)

Go 1.11 支持 module.

代码不需要在 GOPATH/src 目录下。

先初始化模块，生成 `go.mod`

E:\temp
λ mkdir -p testmod\hello

E:\temp
λ cd testmod\hello\

E:\temp\testmod\hello
λ go mod init github.com/jinq0123/hello
go: creating new go.mod: module github.com/jinq0123/hello

创建 `hello.go`

package main

import (
   "fmt"
   "rsc.io/quote"
)

func main() {
   fmt.Println(quote.Hello())
}

构建时报 `golang.org/x/text` 连不上：

E:\temp\testmod\hello
λ go build
go: golang.org/x/text@v0.0.0-20170915032832-14c0d48ead0c: unrecog
nized import path "golang.org/x/text" (https fetch: Get https://g
olang.org/x/text?go-get=1: dial tcp 216.239.37.1:443: connectex:
A socket operation was attempted to an unreachable network.)
go: error loading module requirements

`go.mod` 添加

replace golang.org/x/text => github.com/golang/text v0.3.0

然后构建就成功了：

E:\temp\testmod\hello
λ go build
go: finding github.com/golang/text v0.3.0
go: downloading rsc.io/sampler v1.3.0
go: downloading github.com/golang/text v0.3.0

E:\temp\testmod\hello
λ hello.exe
Hello, world.

如果不加版本号，则会报错：

go.mod:9: replacement module without version must be directory path (rooted or starting with ./ or ../)

Go 1.11.1 replace 还有问题，仍会试图连接原地址。目前版本 1.11.4 可以用。

参考：
https://github.com/golang/go/wiki/Modules

金庆 2018-12-26 10:07 发表评论

gotest 是有缓存的

金庆 — Mon, 29 Oct 2018 10:47:00 GMT

gotest 是有缓存的

(金庆的专栏 2018.10)

用 gotest 运行一个测试，往 mongodb 中插入一条，发现有时灵，有时不灵。

因为错误地怀疑 mgo 用错了，耗费了不少时间。
最终发现是因为 gotest 是有缓存的，输出的是上次运行的结果，但是并没有实际运行代码。

运行有效是因为代码刚改过，测试时会实际运行。

最终也是无意间发现的。给 mgo 开启了调试日志，然后比较2次运行，发现输出是一样的，
只有一行不同：

ok mail-server/server 0.519s
ok mail-server/server (cached)

明确显示了第2次是缓存。前面运行了几十次都忽略了 cached 这个输出。

为了禁止缓存，可加上 -count=1 参数：
go test -count=1

金庆 2018-10-29 18:47 发表评论

K8s获取NodePort

金庆 — Tue, 04 Sep 2018 07:17:00 GMT

K8s获取NodePort

(金庆的专栏 2018.9)

将服务用NodePort暴露到外网，为避免端口冲突，不指定NodePort,
而是让k8s自动选择一个端口。

$ cat get_node_port.yaml
kind: Service
apiVersion: v1
metadata:
name: jq-service
spec:
type: NodePort
selector:
app: MyApp
ports:
- protocol: TCP
port: 80

$ kubectl apply -f get_node_port.yaml
service "jq-service" configured
$ kubectl describe svc/jq-service
Name:                     jq-service
Namespace:                default
Labels:
Annotations:              kubectl...
Selector:                 app=MyApp
Type:                     NodePort
IP:                       10.104.228.187
Port:                     80/TCP
TargetPort:               80/TCP
NodePort:                 32115/TCP
Endpoints:
Session Affinity:         None
External Traffic Policy: Cluster
Events:

可以看到k8s分配了NodePort 32115。

然后需要获取这个动态的NodePort，以通知客户端连接该端口。

package main

import (
    "context"
    "fmt"
    "log"
    "io/ioutil"

    "github.com/ghodss/yaml"
    "github.com/ericchiang/k8s"
    corev1 "github.com/ericchiang/k8s/apis/core/v1"
)

func main() {
    data, err := ioutil.ReadFile("config")
    if err != nil {
        panic(err)
    }

    // Unmarshal YAML into a Kubernetes config object.
    var config k8s.Config
    if err := yaml.Unmarshal(data, &config); err != nil {
        panic(err)
    }

    client, err := k8s.NewClient(&config)
    // client, err := k8s.NewInClusterClient()
    if err != nil {
        log.Fatal(err)
    }

    var svc corev1.Service
    if err := client.Get(context.Background(), "default", "jq-service", &svc); err != nil {
        log.Fatal(err)
    }
    fmt.Printf("%d\n", *svc.Spec.Ports[0].NodePort)
}

运行时需要复制config: `cp ~/.kube/config .`

金庆 2018-09-04 15:17 发表评论

grpc中的dns负载均衡

金庆 — Wed, 29 Aug 2018 02:59:00 GMT

grpc中的dns负载均衡

(金庆的专栏 2018.8)

grpc-go 中如下连接服务器，请求将在多个IP之间轮转。

    conn, err := grpc.Dial(
       "dns:///rng-headless:8081",
       grpc.WithBalancerName(roundrobin.Name),
       grpc.WithInsecure())

标准的目标名应该是这样的：`"dns://authority/endpoint_name"`,
此处 authority 为空，详见：https://github.com/grpc/grpc/blob/master/doc/naming.md

服务器开3个实例，所有请求在3个实例上轮转：

[jinqing@host-10-2-3-4 RoundRobin]$ kubectl run -it --rm jinqing-roundrobin --image=jinq0123/roundrobin:4
If you don't see a command prompt, try pressing enter.
2018/08/28 10:18:01 request 7754383576636566559
2018/08/28 10:18:02 request 2543876599219675746
2018/08/28 10:18:03 request 927204261937181213
2018/08/28 10:18:04 request 7754383576636566559
2018/08/28 10:18:05 request 2543876599219675746
2018/08/28 10:18:06 request 927204261937181213
...

服务器返回一个随机数，不同实例的随机数不同。代码是从
https://github.com/kcollasarundell/balancing-on-k8s 修改的。

...
const (
        port = ":8081"
)

type server struct{}

var r int64

func init(){
    rand.Seed(time.Now().UnixNano())
    r = rand.Int63()
}

func (s *server) Rng(context.Context, *rng.Source) (*rng.RN, error) {
        return &rng.RN{RN: r}, nil
}

func main() {
        lis, err := net.Listen("tcp", port)
        if err != nil {
                log.Fatalf("failed to listen: %v", err)
        }
        s := grpc.NewServer()
        rng.RegisterRngServer(s, &server{})
        // Register reflection service on gRPC server.
        reflection.Register(s)

        if err := s.Serve(lis); err != nil {
                log.Fatalf("failed to serve: %v", err)
        }
}

先编译，打包成镜像，然后用 `balancing-on-k8s\backend\kube.yaml` 运行：
kubectl apply -f kube.yaml

`backend\kube.yaml` 创建了一个 ClusterIP 服务和一个 Headless 服务，部署了 3 个服务器实例。
[jinqing@host-10-2-3-4 RoundRobin]$ kubectl get svc
NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
kubernetes     ClusterIP   10.96.0.1               443/TCP             93d
rng-cluster    ClusterIP   10.111.30.205           8081/TCP            4h
rng-headless   ClusterIP   None                    8081/TCP,8080/TCP   4h

客户端是一个简单的grpc, 定时发送请求，打印返回的随机数。
`balancing-on-k8s\clientSideBalancer\RoundRobin\main.go`中的地址需要添加端口，
不然grpc会去连接 443 端口而失败。

扩容后，测到大概3分钟后才看到负载转移。缩容后会立即生效。
kubectl scale --replicas=5 deployment/rng

如果是 ClusterIP 服务, 则服务名对应一个ClusterIP;
如果是 Headless 服务，则服务名对应各个Pod的IP:

/ # nslookup rng-headless
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   rng-headless.default.svc.cluster.local
Address: 10.244.3.27
Name:   rng-headless.default.svc.cluster.local
Address: 10.244.0.108
Name:   rng-headless.default.svc.cluster.local
Address: 10.244.2.66

/ # nslookup rng-cluster
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   rng-cluster.default.svc.cluster.local
Address: 10.111.30.205

/ #

如果去除 "dns:///", 仅仅是域名加端口：

conn, err := grpc.Dial(
       "rng-headless:8081",
       grpc.WithBalancerName(roundrobin.Name),
       ...

则只会请求同一个实例。只有当该实例pod被删除后才会切换到另一个实例。
使用缩容时发现会优先删除没有客户端连接的实例。
用2个客户端连接到不同服务器实例，然后缩容为1实例，就可以看到请求切换。

如果客户端和服务器数量很大，这个dns负载均衡就不合适了，因为客户端会连接每个服务器实例。

参考：
Exploring Kubernetes Service Discovery and loadbalancing ( https://kca.id.au/post/k8s_service/ )

金庆 2018-08-29 10:59 发表评论

k8s集群外go客户端示例

金庆 — Sun, 22 Jul 2018 03:14:00 GMT

k8s集群外go客户端示例

(金庆的专栏 2018.7)

集群内客户端需要打包成docker镜像，上传镜像，然后用 kubectl run 运行，
还要设置用户角色，太麻烦，还是用集群外客户端测试比较方便。

客户端库使用 ericchiang/k8s, 比官方的 client-go 要简单许多。

集群内客户端使用`k8s.NewInClusterClient()`创建，
集群外客户端使用 `NewClient(config *Config)`, 需要输入配置，
配置就是从 ~/.kube/config 读取的。
参考 https://github.com/ericchiang/k8s/issues/79

代码如下：

package main

import (
    "context"
    "fmt"
    "log"
    "io/ioutil"

    "github.com/ghodss/yaml"
    "github.com/ericchiang/k8s"
    corev1 "github.com/ericchiang/k8s/apis/core/v1"
)

func main() {
    data, err := ioutil.ReadFile("config")
    if err != nil {
        panic(err)
    }

    // Unmarshal YAML into a Kubernetes config object.
    var config k8s.Config
    if err := yaml.Unmarshal(data, &config); err != nil {
        panic(err)
    }

    client, err := k8s.NewClient(&config)
    // client, err := k8s.NewInClusterClient()
    if err != nil {
        log.Fatal(err)
    }

    var nodes corev1.NodeList
    if err := client.List(context.Background(), "", &nodes); err != nil {
        log.Fatal(err)
    }
    for _, node := range nodes.Items {
        fmt.Printf("name=%q schedulable=%t\n", *node.Metadata.Name, !*node.Spec.Unschedulable)
    }
}

yaml 库用了 ghodss/yaml，不能用 go-yaml, 不然报错
`yaml: unmarshal errors`
见：https://github.com/ericchiang/k8s/issues/81

复制 .kube/config 到运行目录，运行列出所有节点：

[jinqing@host-10-1-2-19 out-cluster]$ cp ~/.kube/config .
[jinqing@host-10-1-2-19 out-cluster]$ ./out-cluster
name="host-10-1-2-20" schedulable=true
name="host-10-1-2-21" schedulable=true
name="host-10-1-2-22" schedulable=true
name="host-10-1-2-19" schedulable=true

name="host-10-1-2-18" schedulable=true

金庆 2018-07-22 11:14 发表评论

用目录结构表示go包依赖关系

金庆 — Mon, 25 Jun 2018 09:16:00 GMT

用目录结构表示go包依赖关系

(金庆的专栏 2018.6)

摘自：
https://www.ardanlabs.com/blog/2017/02/package-oriented-design.html

If a package wants to import another package at the same level:

* Question the current design choices of these packages.
* If reasonable, move the package inside the source tree for the package that wants to import it.
* Use the source tree to show the dependency relationships.

金庆 2018-06-25 17:16 发表评论

Golang的包名

金庆 — Mon, 25 Jun 2018 08:51:00 GMT

Golang的包名

(金庆的专栏 2018.6)

摘自：

https://talks.golang.org/2014/organizeio.slide#1

The name of a package

Keep package names short and meaningful.
Don't use underscores, they make package names long.

    io/ioutil not io/util
    suffixarray not suffix_array

Don't overgeneralize. A util package could be anything.

The name of a package is part of its type and function names.
On its own, type Buffer is ambiguous. But users see:

    buf := new(bytes.Buffer)

Choose package names carefully.

Choose good names for users.

金庆 2018-06-25 16:51 发表评论

grpc-go与actor模式

金庆 — Tue, 12 Jun 2018 03:15:00 GMT

grpc-go与actor模式

(金庆的专栏 2018.6)

grpc-go服务器的每个请求都在一个独立的协程中执行。
网游服务器中，一般请求会调用游戏房间的方法，而房间是一个独立的协程。
可以将房间实现为actor，grpc请求通过Call()或Post()方法来执行。
其中Call()会等待返回，而Post()会异步执行无返回值。

type Room struct {
   // actC 是其他协程向Room协程发送动作的Channel，协程中将依次执行动作。
   // Action 动作, 是无参数无返回值的函数.
   actC chan func()

   ...
}

// Run 运行房间协程.
func (r *Room) Run() {
   ticker := time.NewTicker(20 * time.Millisecond)
   defer ticker.Stop()

   for r.running {
       select {
       case act := <-r.actC:
           act()
       case <-ticker.C:
           r.tick()
       }
   }
}

// Call calls a function f and returns the result.
// f runs in the Room's goroutine.
func (r *Room) Call(f func() interface{}) interface{} {
   // 结果从ch返回
   ch := make(chan interface{}, 1)
   r.actC <- func() {
       ch <- f()
   }
   // 等待直到返回结果
   return <-ch
}

// Post 将一个动作投递到内部协程中执行.
func (r *Room) Post(f func()) {
   r.actC <- f
}

grpc服务方法如：

func (m *RoomService) Test(ctx context.Context, req *pb.TestReq) (*pb.TestResp, error) {
   conn := conn_mgr.GetConn(ctx)
   if conn == nil {
       return nil, fmt.Errorf("can not find connection")
   }

   room := conn.GetRoom()
   resp := room.Call(func() interface{} {
       return room.Test(req)
   })

   return resp.(*pb.TestResp), nil
}

金庆 2018-06-12 11:15 发表评论