Docker安装consul + go使用consul + consul知识

🕗 发布于 2024-09-30 06:32 docker consul 容器

1. 什么是服务注册和发现

假如这个产品已经在线上运行，有一天运营想搞一场促销活动，那么我们相对应的【用户服务】可能就要新开启三个微服务实例来支撑这场促销活动。而与此同时，作为苦逼程序员的你就只有手动去 API gateway 中添加新增的这三个微服务实例的 ip 与port ，一个真正在线的微服务系统可能有成百上千微服务，难道也要一个一个去手动添加吗？有没有让系统自动去实现这些操作的方法呢？答案当然是有的。
当我们新添加一个微服务实例的时候，微服务就会将自己的 ip 与 port 发送到注册中心，在注册中心里面记录起来。当 API gateway 需要访问某些微服务的时候，就会去注册中心取到相应的 ip 与 port。从而实现自动化操作。

1. 技术选型

Consul 与其他常见服务发现框架对比

名称	优点	缺点	接口	一致性算法
zookeeper	1.功能强大，不仅仅只是服务发现 2.提供 watcher 机制能实时获取服务提供者的状态 3.dubbo 等框架支持	1.没有健康检查 2.需在服务中集成 sdk，复杂度高 3.不支持多数据中心	sdk	Paxos
consul	1.简单易用，不需要集成 sdk 2.自带健康检查 3.支持多数据中心 4.提供 web 管理界面	1.不能实时获取服务信息的变化通知	http/dns	Raft
etcd	1.简单易用，不需要集成 sdk 2.可配置性强	1.没有健康检查 2.需配合第三方工具一起完成服务发现 3.不支持多数据中心	http	Raft

2.consul的安装和配置

2.1. 安装

docker run -d -p 8500:8500 -p 8300:8300 -p 8301:8301 -p 8302:8302 -p 8600:8600/udp consul consul agent -dev -client=0.0.0.0

docker container update --restart=always 容器名字

2.2. 访问

浏览器访问 127.0.0.1:8500

2.3. 访问dns

consul提供dns功能，可以让我们通过，可以通过dig命令行来测试，consul默认的dns端口是8600，命令行：
linux下的dig命令安装：
yum install bind-utils

dig @192.168.1.103 -p 8600 consul.service.consul SRV

windows下载dig命令： BIND9.17.2.x64.zip

3.consul的api接口

3.4. 同一个服务注册多个实例

3.5. 获取服务

https://www.consul.io/api-docs/agent/service#list-services

4.go操作consul

package main
import (
    "fmt"
    "github.com/hashicorp/consul/api"
    )
func Register(address string, port int, name string, tags []string, id string) error {
    cfg := api.DefaultConfig()
    cfg.Address = "192.168.1.103:8500"
    client, err := api.NewClient(cfg)
    if err != nil {
        panic(err)
    }
    //生成对应的检查对象
    check := &api.AgentServiceCheck{
        HTTP: "http://192.168.1.102:8021/health",
        Timeout: "5s",
        Interval: "5s",
        DeregisterCriticalServiceAfter: "10s",
    }
    //生成注册对象
    registration := new(api.AgentServiceRegistration)
    registration.Name = name
    registration.ID = id
    registration.Port = port
    registration.Tags = tags
    registration.Address = address
    registration.Check = check
    err = client.Agent().ServiceRegister(registration)
    if err != nil {
        panic(err)
    }
    return nil
}
func AllServices(){
    cfg := api.DefaultConfig()
    cfg.Address = "192.168.1.103:8500"
    client, err := api.NewClient(cfg)
    if err != nil {
        panic(err)
    }
    data, err := client.Agent().Services()
    if err != nil {
        panic(err)
    }
    for key, _ := range data{
        fmt.Println(key)
    }
}
func FilterSerivice(){
    cfg := api.DefaultConfig()
    cfg.Address = "192.168.1.103:8500"
    client, err := api.NewClient(cfg)
    if err != nil {
        panic(err)
    }
    data, err := client.Agent().ServicesWithFilter(`Service == "user-web"`)
    if err != nil {
        panic(err)
    }
    for key, _ := range data{
        fmt.Println(key)
    }
}
func main(){
    //_ = Register("192.168.1.102", 8021, "user-web", []string{"mxshop", "bobby"}, "user-web")
    //AllServices()
    FilterSerivice()
}

5.grpc下的健康检查

5.1. grpc的健康检查规范

官方文档
grpc健康检查重要点:

check = {
“GRPC”: "ip:port",
“GRPCUseTLS”: False,
“Timeout”: “5s”,
“Interval”: “5s”,
“DeregisterCriticalServiceAfter”: “5s”,
}

一定要确保网络是通的
一定要确保srv服务监听端口是对外可访问的（公网ip地址不是本地的127.0.0.1）
GRPC一定要自己填写

5.2. go配置grpc的健康检查

//注册服务健康状态检查
grpc_health_v1.RegisterHealthServer(g, health.NewServer())

6.动态获取可用端口号

package utils
import (
    "net"
)
func GetFreePort() (int, error) {
    addr, err := net.ResolveTCPAddr("tcp", "localhost:0")
    if err != nil {
        return 0, err
    }
    l, err := net.ListenTCP("tcp", addr)
    if err != nil {
        return 0, err
    }
    defer l.Close()
    return l.Addr().(*net.TCPAddr).Port,  nil
}

7.负载均衡策略

1. 什么是负载均衡

7.负载均衡策略 - 图1

2. 负载均衡策略

1. 集中式load balance

集中式LB方案，如下图。首先，服务的消费方和提供方不直接耦合，而是在服务消费者和服务提供者之间有一个独立的LB（LB通常是专门的硬件设备如F5，或者基于软件如LVS，HAproxy等实现）。

7.负载均衡策略 - 图2

LB上有所有服务的地址映射表，通常由运维配置注册，当服务消费方调用某个目标服务时，它向LB发起请求，由LB以某种策略（比如Round-Robin）做负载均衡后将请求转发到目标服务。
LB一般具备健康检查能力，能自动摘除不健康的服务实例。
服务消费方如何发现LB呢？通常的做法是通过DNS，运维人员为服务配置一个DNS域名，这个域名指向LB。
这种方案基本可以否决，因为它有致命的缺点：所有服务调用流量都经过load balance服务器，所以load balance服务器成了系统的单点，一旦LB发生故障对整个系统的影响是灾难性的。为了解决这个问题，必然需要对这个load balance部件做分布式处理（部署多个实例，冗余，然后解决一致性问题等全家桶解决方案），但这样做会徒增非常多的复杂度。

2. 进程内load balance

进程内load balance。将load balance的功能和算法以sdk的方式实现在客户端进程内。先看架构图：

7.负载均衡策略 - 图3

可看到引入了第三方：服务注册中心。它做两件事：

维护服务提供方的节点列表，并检测这些节点的健康度。检测的方式是：每个节点部署成功，都通知服务注册中心；然后一直和注册中心保持心跳。
允许服务调用方注册感兴趣的事件，把服务提供方的变化情况推送到服务调用方。

这种方案下，整个load balance的过程是这样的：

服务注册中心维护所有节点的情况。
任何一个节点想要订阅其他服务提供方的节点列表，向服务注册中心注册。
服务注册中心将服务提供方的列表（以长连接的方式）推送到消费方。
消费方接收到消息后，在本地维护一份这个列表，并自己做load balance。

可见，服务注册中心充当什么角色？它是唯一一个知道整个集群内部所有的节点情况的中心。所以对它的可用性要求会非常高，这个组件可以用Zookeeper实现。
这种方案的缺点是：每个语言都要研究一套sdk，如果公司内的服务使用的语言五花八门的话，这方案的成本会很高。第二点是：后续如果要对客户库进行升级，势必要求服务调用方修改代码并重新发布，所以该方案的升级推广有不小的阻力。

3. 独立进程load balance

该方案是针对第二种方案的不足而提出的一种折中方案，原理和第二种方案基本类似，不同之处是，他将LB和服务发现功能从进程内移出来，变成主机上的一个独立进程，主机上的一个或者多个服务要访问目标服务时，他们都通过同一主机上的独立LB进程做服务发现和负载均衡。如图

7.负载均衡策略 - 图4

这个方案解决了上一种方案的问题，不需要为不同语言开发客户库，LB的升级不需要服务调用方改代码。
但新引入的问题是：这个组件本身的可用性谁来维护？还要再写一个watchdog去监控这个组件？另外，多了一个环节，就多了一个出错的可能，线上出问题了，也多了一个需要排查的环节。

8.常见的负载均衡算法

在分布式系统中，多台服务器同时提供一个服务，并统一到服务配置中心进行管理，消费者通过查询服务配置中心，获取到服务到地址列表，需要选取其中一台来发起RPC远程调用。如何选择，则取决于具体的负载均衡算法，对应于不同的场景，选择的负载均衡算法也不尽相同。负载均衡算法的种类有很多种，常见的负载均衡算法包括轮询法、随机法、源地址哈希法、加权轮询法、加权随机法、最小连接法等，应根据具体的使用场景选取对应的算法。

1. 轮询（Round Robin）法

轮询很容易实现，将请求按顺序轮流分配到后台服务器上，均衡的对待每一台服务器，而不关心服务器实际的连接数和当前的系统负载。

2. 随机法

通过系统随机函数，根据后台服务器列表的大小值来随机选取其中一台进行访问。由概率概率统计理论可以得知，随着调用量的增大，其实际效果越来越接近于平均分配流量到后台的每一台服务器，也就是轮询法的效果。

3. 源地址哈希法

源地址哈希法的思想是根据服务消费者请求客户端的IP地址，通过哈希函数计算得到一个哈希值，将此哈希值和服务器列表的大小进行取模运算，得到的结果便是要访问的服务器地址的序号。采用源地址哈希法进行负载均衡，相同的IP客户端，如果服务器列表不变，将映射到同一个后台服务器进行访问。

4. 加权轮询（Weight Round Robin）法

不同的后台服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不一样。跟配置高、负载低的机器分配更高的权重，使其能处理更多的请求，而配置低、负载高的机器，则给其分配较低的权重，降低其系统负载，加权轮询很好的处理了这一问题，并将请求按照顺序且根据权重分配给后端。

5. 加权随机（Weight Random）法

加权随机法跟加权轮询法类似，根据后台服务器不同的配置和负载情况，配置不同的权重。不同的是，它是按照权重来随机选取服务器的，而非顺序。

6. 最小连接数法

前面我们费尽心思来实现服务消费者请求次数分配的均衡，我们知道这样做是没错的，可以为后端的多台服务器平均分配工作量，最大程度地提高服务器的利用率，但是，实际上，请求次数的均衡并不代表负载的均衡。因此我们需要介绍最小连接数法，最小连接数法比较灵活和智能，由于后台服务器的配置不尽相同，对请求的处理有快有慢，它正是根据后端服务器当前的连接情况，动态的选取其中当前积压连接数最少的一台服务器来处理当前请求，尽可能的提高后台服务器利用率，将负载合理的分流到每一台服务器。

9.grpc的负载均衡策略

9.1. grpc的负载均衡策略

文档

9.2. go使用grpc负载均衡

grpc-consul-resolver地址

9.3. 关于serverconfig

官方文档

9.4. go的grpc测试

package main
import (
    "OldPackageTest/grpclb_test/proto"
    "context"
    "fmt"
    "log"
    _ "github.com/mbobakov/grpc-consul-resolver" // It's important
    "google.golang.org/grpc"
)
func main() {
    conn, err := grpc.Dial(
        "consul://192.168.1.103:8500/user-srv?wait=14s&tag=srv",
        grpc.WithInsecure(),
        grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy": "round_robin"}`),
    )
    if err != nil {
        log.Fatal(err)
    }
    defer conn.Close()
    for i := 0; i<10; i++{
        userSrvClient := proto.NewUserClient(conn)
        rsp, err := userSrvClient.GetUserList(context.Background(), &proto.PageInfo{
            Pn:    1,
            PSize: 2,
        })
        if err != nil {
            panic(err)
        }
        for index, data := range rsp.Data{
            fmt.Println(index, data)
        }
    }
}

原文地址：https://blog.csdn.net/zwl153910/article/details/142578914

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！

上一篇：基于VirtualBox和Ubuntu的虚拟环境搭建
下一篇：uniapp在线打包的ios后调用摄像头失败的解决方法

MySQL数据库基础
在过去的mysql中主要是使用的utf8mb3，但是mysql显示的就是utf8，中mysql8中区分显示了。类似于不同的编译器，虽然C/C++的代码是一样的，但是预处理、编译、汇编、链接这些过程却不
阅读更多2024-09-30
Percona Monitoring and Management
Percona Monitoring and Management (PMM)是一款开源的专用于管理和监控MySQL、MongoDB、PostgreSQL。
阅读更多2024-09-30
鸿蒙开发（NEXT/API 12）【已连接穿戴设备查询】手机侧应用开发
Wear Engine提供查询用户已连接的穿戴设备列表（即支持Wear Engine能力且与手机侧运动健康App处于连接状态的穿戴设备）的接口。
阅读更多2024-09-30
Redis数据库
本篇文章介绍了redis的相关知识，并使用springboot集成redis，实现缓存和分布式锁，后续会对文章勘误及更新~~
阅读更多2024-09-30
旧版的存档
【代码】旧版的存档。
阅读更多2024-09-30
Spring Boot 封装统一返回结果及全局异常处理
为了更细致地控制异常处理，我们可以定义一些自定义异常。然后，在全局异常处理器中添加对自定义异常的处理。通过封装统一的返回结果和全局异常处理，我们可以让Spring Boot应用更加健壮和易于维护。这种
阅读更多2024-09-30
【C++】IO流
C++IO流，包含输入输出流、文件流、字符流
阅读更多2024-09-30
低至1元/小时：国庆七天，30元通关《黑神话：悟空》！
随着《黑神话：悟空》自8月20日全球同步上线，正式登陆PC、PS5平台以来，以其精湛的画面和流畅的战斗体验，在发售三天后，该作的全平台销量超过1000万套，打破中国游戏历史记录，被媒体称为“中国首款3
阅读更多2024-09-30
阿里巴巴国际站获取商品详情item_get接口技术分享
item_get API接口是阿里巴巴开放平台提供的一个重要接口，它允许商家通过API调用，获取阿里巴巴平台上的商品详细信息。这些信息包括商品标题、价格、库存、属性、描述等，为商家提供了全面、准确的商
阅读更多2024-09-30
软件测试谣言二三事，认真你就输了
软件测试的职业寿命，取决于互联网行业能存活多久，至少目前看来，这个职业没有消失的风险，至于你能在这个职业待多久，那取决于你自己的能力，我见过不少超过35岁的老员工还在测试的职位上兢兢业业。以广州为例，
阅读更多2024-09-30