战旗直播基于consul服务注册与发现的GRPC服务实战与感想

ample

前言

鄙人关注consul也有一段时间了,从2017年开始了解它的一些特性,它能帮助解决哪些问题,然后怎么应用到微服务中去。随着时间的推移,微服务的发展也是非常的迅速,可以说日新月异,每天都在变化。consul工具所提供的功能也在不断地新增和完善。OK,有些扯远了,咱们还是回到主题上来吧。
在微服务领域有个重要的概念——服务注册与发现。google或baidu一下,会发现有大量的关于服务注册发现的文章、博客等,有基于consul的、也有基于etcd和zoomkeeper的,每个工具都有自己的特点和优势,也有一定的相似性,比如它们都可以实现服务注册与发现,也都可以实现kv存储等。但是它们也有一定的区别,比如consul重点是服务注册与发现,其次是kv存储;像etcd重点是处理kv存储的功能,在kv存储上来实现服务的注册与发现。侧重点不一样,感兴趣的朋友可以去google或baidu一下,这里就不在叙述了。由于侧重点不同,依据战旗直播业务的实际情况,选择了consul来实现战旗后端的服务注册与发现。

consul能解决的问题

  1. 服务注册(注销)与发现
  2. 节点/服务监控
  3. KV存储——业务服务配置统一管理
  4. consul-template
  5. ACL
  6. DNS
  7. 其他

consul集群部署

依据consul的文档,consul集群中需要部署两种类型的节点:server节点和client节点。server节点推荐部署奇数个节点,有利于leader的选举过程快速的结束(偶数个节点可能需要多个选举过程才能选举出leader)。这里有几个概念:集群,leader选举,对这些原理感兴趣同学可以去google下.
战旗部署了5个server节点,其他节点都是client,也就是说每台服务上都有一个node。然后,战旗的服务通过localhost:8500地址向consul集群注册自己。部署结构1如下图所示:
Consul dep.png

思考:这样的部署结构存在一定的缺陷,如果某个节点的consul挂了,会直接影响该节点上的所有应用服务,应为它们都是通过localhost来跟consul进行通讯的。那怎么预防这样的情况呢?
这时备选方案plan B出台了.

  1. 通过coreDNS获取consul集群状况,来自动配置一个内部DNS路由条目。当访问consul服务时,自动路由到consul集群中的某个节点。
  2. 也可以部署两个nginx(主备),由nginx路由到consul集群中的某个节点。
  3. 如果您采用的是k8s环境,那恭喜您,可以省略很多工作来,直接在k8s中部署一个service来指向consul集群。

部署结构2如下图所示:
consul dep2.jpg

小结:为了提高consul集群的高可靠性,保证服务的正常运行。在结构1的基础上,同时又部署了DNS方案。当本节点的consul不可达时,通过DNS来与consul集群通讯。这里可能有些同学会问,为什么不直接采用结构2呢?这两个结构各有千秋,结构1通迅效率高,应用服务的健康检测都在当前节点完成,检测压力小。结构2虽无单节点风险,但存在consul负载不均衡等缺点。

具体consul怎么下载,怎么安装,怎么启动server,怎么加入集群就不讲了,大家可以参考官方文档:https://www.consul.io/docs/index.html

consul与grpc实战

服务注册与注销

当应用服务启动时,将自己注册到consul中,以便其他服务能及时发现该服务。

1.导入sdk,

import (
    consul "github.com/hashicorp/consul/api"
)

2.获取consul client对象

// @param uriStr string: consul通迅地址,默认http://localhost:8500; 当localhost不可达时,需要通过服务名来访问其他consul节点,如:http://consul:8500
// @param token string: 访问控制用
func MakeClient(uriStr string, token string) (*consul.Client, error) {

    uri, err := url.Parse(uriStr)
    if err != nil {
        logs.Error("url parse error: ", err)
        return nil, err
    }

    config := consulapi.DefaultConfig()
    config.Address = uriStr

    if len(token) > 0 {
        config.Token = token
    } else {
        config.Token = defaultToken
    }

    client, err := consulapi.NewClient(config)
    if err != nil {
        logs.Error("consul: ", uri.Scheme)
        return nil, err
    }

    return client, nil
}

3.准备工作

// @param svrName string: 要注册当服务名
// @param useType string: 对应consul中的tag, 可用于过滤
// @param svrPort int: 服务对应的端口号
// @param healthPort int: http检测时需要对应端口号,tcp检测默认当前端口
// @param healthType string: http或tcp,
// @param localIp string: 当前节点的内网IP,即其他服务能访问到的IP
func Prepare(svrName string, useType string, svrPort int, healthPort int, healthType string, localIp string) *consulapi.AgentServiceRegistration {
    ip := localIp 
    // 注册配置信息
    reg := &consul.AgentServiceRegistration{
        ID:      strings.ToLower(fmt.Sprintf("%s_%d", svrName, libs.Ip2Long(ip))), // 生成一个唯一当服务ID
        Name:    strings.ToLower(fmt.Sprintf("%s", svrName)), // 注册服务名
        Tags:    []string{strings.ToLower(useType)},// 标签
        Port:    svrPort, // 端口号
        Address: ip, // 所在节点ip地址
    }
    // 健康检测配置信息
    reg.Check = &consulapi.AgentServiceCheck{
        TCP:                            fmt.Sprintf("%s:%d", ip, svrPort),
        Timeout:                        "1s",
        Interval:                       "15s",
        DeregisterCriticalServiceAfter: "30s",// 30秒服务不可达时,注销服务
        Status:                         "passing",// 服务启动时,默认正常
    }

    if healthType == "http" {
        reg.Check.HTTP = fmt.Sprintf("http://%s:%d%s", reg.Address, healthPort, "/health") // http检测默认/health路径
        reg.Check.TCP = ""
    }
    // 启动http健康检测响应
    if len(reg.Check.HTTP) > 0 {
        RunHealthCheck(reg.Check.HTTP)
    }
    p.curRegistration = reg
    return reg
}

func RunHealthCheck(addr string) error {
    uri, err := url.Parse(addr)
    if err != nil {
        return err
    }

    http.HandleFunc(uri.Path, func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("success"))
    })
    go http.ListenAndServe(uri.Host, nil)
    return nil
}

4.服务注册

var (
    // 获取consul.Client, 如果localhost不可达需要自动切换地址
    client := MakeClient("http:localhost:8500", "")
    // 配置要注册的服务信息
    registration = Prepare("ImSvr", "grpc", "10000", 30000, "http", "192.168.1.100")
)

// 
func Register() error {
    err := client.Agent().ServiceRegister(registration)
    if err != nil {
        return err
    }

    return nil
}

5.服务注销

//
func Deregister() error {
    svrId := registration.ID
    return client.Agent().ServiceDeregister(svrId)
}

小结:当这些服务注册/注销方法封装好后,在应用服务启动的时候,调用Register()方法进行注册;当应用服务退出的时候,调用Deregister()方法进行注销。当服务异常退出当时候,并不会调用Deregister()方法,那怎么办呢?放心,前面已经有说到健康检测的DeregisterCriticalServiceAfter字段,当服务不可达时,会自动注销服务。OK,到这里服务的自动化注册已经完成了。

服务发现

对于服务与服务之间的通迅有很多方式,有人直接用tcp/http;有人会考虑restfullapi,让接口处理起来更容易;有人用dubbo,抱紧ali大腿;咱们用grpc, 抱紧google大腿。通迅框架之间各有千秋,总之适合自己的才是最好的。感兴趣的盆友自己去google/百度。

google grpc框架里并没有实现如何基于consul进行服务发现(或许后期会加上),不过有DNS的服务发现。看了它的实现方式,大致懂了实现原理。OK,咱们就写个基于consul的服务发现。鄙人github中可直接用consulresolver(欢迎大家关注,如果有问题请提交issue会第一时间修改),目前只有roundrobin策略,后续会逐渐加入其他策略(如随机,权重随机,负载策略等).同时该项目
github.com/generalzgd/grpc-svr-frame
还对grpc作了一些简单的封装,有利于快速搭建grpc服务。
这里就不贴代码了。

OK,基于consul的服务发现有了,那怎么使用呢?
1.导入模块,会自动执行包中的Init方法

import (
    grpclb_consul `github.com/generalzgd/grpc-svr-frame/grpc-consul`
    ctrl `github.com/generalzgd/grpc-svr-frame/grpc-ctrl`
)

2.组合grpc的方法封装

type MyServer {
    ctrl.GrpcController
}

var (
    mySvr = MyServer{
        GrpcController:ctrl.MakeGrpcController(),
    }
)

func (p *MyServer) callSample(){
    // 设置5秒超时
    ctx, _ := context.WithTimeout(context.Background(), 5*time.Second)
    // 注意address字段,由“consul:///”字符串开头,表示要用consulresolver来解析,后面写上服务名,会自动解析到对应的服务地址。可以细看下对应的文件,然后理解是怎么运行的。
    cfg = yaml.EndpointConfig{
        Name: "ImSvr",
        Address: "consul:///imsvr", 
    }
    // 里面还封装了connection pool,以提高通迅效率
    clientConn,err := p.GetGrpcConnWithLB(cfg, ctx)
    if err != nil {
        return
    }
    // 以下是grpc框架的通用伪代码
    client := NewImSvrClient(clientConn.ClientConn)
    resp, err := client.Login(ctx, &LoginReq{})
    if err != nil {
        return
    }
    logs.Info("Got:", resp)
}

总结

至此基于consul的服务注册与发现已经整合到grpc通迅框架中,并且封装了grpc服务的一些常用方法,可用于快速的开发微服务。这个整合过程历经了很多辛酸,不仅分析了官方文档源代码,也吸收了其他在consul/grpc方面的贡献者经验,前前后后琢磨尝试了许许多多的失败,也走了很多的弯路。当然了,整个结构还是个雏形,还需要完善。例如,均衡负载策略,目前只实现了roundrobin, 后续还有随机、权重、负载策略等。

遇到的坑

咱们在部署consul的时候选择了一个老版本,以为老版本(1.4.4)会相对稳定些。在新加节点的时候,突然已有的services每隔几分钟会消失,然后又重现,然后又消失不停的重复。妈呀,出大问题了,跟运维老哥一起折腾了个吧小时,推测可能join server节点的时候,数据同步可能存在问题。期间也没做其他操作,就一个节点一个节点leave回退,发现leave最后加入的server节点后consul稳定了。稳定后再仔细分析原因,发现这个版本有bug,https://github.com/hashicorp/consul/issues/5518, 以后生产环境尽量用次新版本。这是血的教训!!!!!

阅读 3.7k
77 声望
4 粉丝
0 条评论
77 声望
4 粉丝
文章目录
宣传栏