网站建设 统一质量标准,嵌入式培训,好看的响应式网站,苏州保洁公司多少钱一个平方文章目录 什么是服务注册和发现技术选型 Consul 的安装和配置1. 安装2. 访问3. 访问dns Consul 的api接口go操作consulgrpc下的健康检查grpc的健康检查规范动态获取可用端口号 负载均衡策略1. 什么是负载均衡2. 负载均衡策略1. 集中式load balance2. 进程内load balance3. 独立… 文章目录 什么是服务注册和发现技术选型 Consul 的安装和配置1. 安装2. 访问3. 访问dns Consul 的api接口go操作consulgrpc下的健康检查grpc的健康检查规范动态获取可用端口号 负载均衡策略1. 什么是负载均衡2. 负载均衡策略1. 集中式load balance2. 进程内load balance3. 独立进程load balance 常见的负载均衡算法1. 轮询Round Robin法2. 随机法3. 源地址哈希法4. 加权轮询Weight Round Robin法5. 加权随机Weight Random法6. 最小连接数法 grpc负载均衡策略为什么需要分布式配置中心分布式配置中心选型nacos的基本使用gin集成nacos如何将nacos中的配置映射成go的struct 什么是服务注册和发现
假如这个产品已经在线上运行有一天运营想搞一场促销活动那么我们相对应的【用户服务】可能就要新开启三个微服务实例来支撑这场促销活动。而与此同时作为苦逼程序员的你就只有手动去 API gateway 中添加新增的这三个微服务实例的 ip 与port 一个真正在线的微服务系统可能有成百上千微服务难道也要一个一个去手动添加吗有没有让系统自动去实现这些操作的方法呢答案当然是有的。 当我们新添加一个微服务实例的时候微服务就会将自己的 ip 与 port 发送到注册中心在注册中心里面记录起来。当 API gateway 需要访问某些微服务的时候就会去注册中心取到相应的 ip 与 port。从而实现自动化操作。
技术选型
Consul 与其他常见服务发现框架对比 Consul 的安装和配置
1. 安装
docker run -d -p 8500:8500 -p 8300:8300 -p 8301:8301 -p 8302:8302 -p 8600:8600/ud
docker container update --restartalways 容器名字2. 访问
浏览器访问 127.0.0.1:8500
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命令 dig.zip
Consul 的api接口
添加服务 https://www.consul.io/api-docs/agent/service#register-service删除服务 https://www.consul.io/api-docs/agent/service#deregister-service设置健康检查 https://www.consul.io/api-docs/agent/check同一个服务注册多个实例获取服务 https://www.consul.io/api-docs/agent/service#list-services
go操作consul
package mainimport (fmtgithub.com/hashicorp/consul/api)
func Register(address string, port int, name string, tags []string, id string) ercfg : api.DefaultConfig()cfg.Address 192.168.1.103:8500client, 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 nameregistration.ID idregistration.Port portregistration.Tags tagsregistration.Address addressregistration.Check checkerr client.Agent().ServiceRegister(registration)if err ! nil {panic(err)}return nil}
func AllServices(){cfg : api.DefaultConfig()cfg.Address 192.168.1.103:8500client, 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:8500client, 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}//AllServices()FilterSerivice()
}grpc下的健康检查
grpc的健康检查规范
官方文档
grpc健康检查重要点:
1. check {
“GRPC”: f’{ip}:{port}’,
“GRPCUseTLS”: False,
“Timeout”: “5s”,
“Interval”: “5s”,
“DeregisterCriticalServiceAfter”: “5s”,
}一定要确保网络是通的一定要确保srv服务监听端口是对外可访问的GRPC一定要自己填写
动态获取可用端口号
package utilsimport (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
}负载均衡策略
1. 什么是负载均衡 2. 负载均衡策略
1. 集中式load balance
集中式LB方案如下图。首先服务的消费方和提供方不直接耦合而是在服务消费者和服务提供者之间有一个独立的LBLB通常是专门的硬件设备如F5或者基于软件如LVSHAproxy等实现。 LB上有所有服务的地址映射表通常由运维配置注册当服务消费方调用某个目标服务时它向LB发起请求由LB以某种策略比如Round-Robin做负载均衡后将请求转发到目标服务。
服务消费方如何发现LB呢通常的做法是通过DNS运维人员为服务配置一个DNS域名这个域名指向LB。 这种方案基本可以否决因为它有致命的缺点所有服务调用流量都经过load balance服务器所以load balance服务器成了系统的单点一旦LB发生故障对整个系统的影响是灾难性的。为了解决这个问题必然需要对这个load balance部件做分布式处理部署多个实例冗余然后解决一致性问题等全家桶解决方案但这样做会徒增非常多的复杂度。
2. 进程内load balance
进程内load balance。将load balance的功能和算法以sdk的方式实现在客户端进程内。先看架构图 可看到引入了第三方服务注册中心。它做两件事
维护服务提供方的节点列表并检测这些节点的健康度。检测的方式是每个节点部署成功都通知服务注册中心然后一直和注册中心保持心跳。允许服务调用方注册感兴趣的事件把服务提供方的变化情况推送到服务调用方。这种方案下整个load balance的过程是这样的服务注册中心维护所有节点的情况。任何一个节点想要订阅其他服务提供方的节点列表向服务注册中心注册。服务注册中心将服务提供方的列表以长连接的方式推送到消费方。消费方接收到消息后在本地维护一份这个列表并自己做load balance。
可见服务注册中心充当什么角色它是唯一一个知道整个集群内部所有的节点情况的中心。所以对它的可用性要求会非常高这个组件可以用Zookeeper实现。 这种方案的缺点是每个语言都要研究一套sdk如果公司内的服务使用的语言五花八门的话这方案的成本会很高。第二点是后续如果要对客户库进行升级势必要求服务调用方修改代码并重新发布所以该方案的升级推广有不小的阻力。
3. 独立进程load balance
该方案是针对第二种方案的不足而提出的一种折中方案原理和第二种方案基本类似不同之处是他将LB和服务发现功能从进程内移出来变成主机上的一个独立进程主机上的一个或者多个服务要访问目标服务时他们都通过同一主机上的独立LB进程做服务发现和负载均衡。如图 这个方案解决了上一种方案的问题不需要为不同语言开发客户库LB的升级不需要服务调用方改代码。 但新引入的问题是这个组件本身的可用性谁来维护还要再写一个watchdog去监控这个组件另外多了一个环节就多了一个出错的可能线上出问题了也多了一个需要排查的环节。
常见的负载均衡算法
在分布式系统中多台服务器同时提供一个服务并统一到服务配置中心进行管理消费者通过查询服务配置中心获取到服务到地址列表需要选取其中一台来发起RPC远程调用。如何选择则取决于具体的负载均衡算法对应于不同的场景选择的负载均衡算法也不尽相同。负载均衡算法的种类有很多种常见的负载均衡算法包括轮询法、随机法、源地址哈希法、加权轮询法、加权随机法、最小连接法等应根据具体的使用场景选取对应的算法。
1. 轮询Round Robin法
轮询很容易实现将请求按顺序轮流分配到后台服务器上均衡的对待每一台服务器而不关心服务器实际的连接数和当前的系统负载。
2. 随机法
通过系统随机函数根据后台服务器列表的大小值来随机选取其中一台进行访问。由概率概率统计理论可以得知随着调用量的增大其实际效果越来越接近于平均分配流量到后台的每一台服务器也就是轮询法的效果。
3. 源地址哈希法
源地址哈希法的思想是根据服务消费者请求客户端的IP地址通过哈希函数计算得到一个哈希值将此哈希值和服务器列表的大小进行取模运算得到的结果便是要访问的服务器地址的序号。采用源地址哈希法进行负载均衡相同的IP客户端如果服务器列表不变将映射到同一个后台服务器进行访问。
4. 加权轮询Weight Round Robin法
不同的后台服务器可能机器的配置和当前系统的负载并不相同因此它们的抗压能力也不一样。跟配置高、负载低的机器分配更高的权重使其能处理更多的请求而配置低、负载高的机器则给其分配较低的权重降低其系统负载加权轮询很好的处理了这一问题并将请求按照顺序且根据权重分配给后端。
5. 加权随机Weight Random法
加权随机法跟加权轮询法类似根据后台服务器不同的配置和负载情况配置不同的权重。不同的是它是按照权重来随机选取服务器的而非顺序。
6. 最小连接数法
前面我们费尽心思来实现服务消费者请求次数分配的均衡我们知道这样做是没错的可以为后端的多台服务器平均分配工作量最大程度地提高服务器的利用率但是实际上请求次数的均衡并不代表负载的均衡。因此我们需要介绍最小连接数法最小连接数法比较灵活和智能由于后台服务器的配置不尽相同对请求的处理有快有慢它正是根据后端服务器当前的连接情况动态的选取其中当前积压连接数最少的一台服务器来处理当前请求尽可能的提高后台服务器利用率将负载合理的分流到每一台服务器。
grpc负载均衡策略 grpc的负载均衡策略 文档 go使用grpc负载均衡 文档 关于serverconfig 官方文档 go的grpc测试
package mainimport (OldPackageTest/grpclb_test/protocontextfmtlog_ github.com/mbobakov/grpc-consul-resolver // Its importantgoogle.golang.org/grpc)
func main() {conn, err : grpc.Dial(consul://192.168.1.103:8500/user-srv?wait14stagsrv,grpc.WithInsecure(),grpc.WithDefaultServiceConfig({loadBalancingPolicy: round_robin}),)if err ! nil {log.Fatal(err)}defer conn.Close()for i : 0; i10; i{userSrvClient : proto.NewUserClient(conn)rsp, err : userSrvClient.GetUserList(context.Background(), proto.PageInPn: 1,PSize: 2,})if err ! nil {panic(err)}for index, data : range rsp.Data{fmt.Println(index, data)}}
}为什么需要分布式配置中心
我们现在有一个项目使用gin进行开发的配置文件的话我们知道是一个叫做config.yaml的文件。 我们也知道这个配置文件会在项目启动的时候被加载到内存中进行使用的。 考虑两种情况 a. 添加配置项 ⅰ. 你现在的用户服务有10个部署实例那么添加配置项你得去十个地方修改配置文件还得重新启动等。 ⅱ. 即使go的viper能完成修改配置文件自动生效那么你得考虑其他语言是否也能做到这点其他的服务是否也一定会使用viper b. 修改配置项 大量的服务可能会使用同一个配置比如我要更好jwt的secrect这么多实例怎么办 c. 开发、测试、生产环境如何隔离 前面虽然已经介绍了viper但是依然一样的问题这么多服务如何统一这种考虑因素
分布式配置中心选型
目前最主流的分布式配置中心主要是有spring cloud config、 apollo和nacosspring cloud属于java的spring体系我们就考虑apollo和nacos。apollo与nacos 都为目前比较流行且维护活跃的2个配置中心。 apollo是协程开源nacos是阿里开源
apollo大而全功能完善。nacos小而全可以对比成django和flask的区别部署nacos更加简单。nacos不止支持配置中心还支持服务注册和发现。都支持各种语言不过apollo是第三方支持的nacos是官方支持各种语言
两者都很活跃不过看得出来nacos想要构建的生态野心更大不过收费意图明显。 nacos的基本使用
文档
命名空间 可以隔离配置集将某些配置集放到某一个命名空间之下。 命名空间我们一般用来区分 微服务组 抛出一个问题 你现在确实能够隔离微服务但是不同的微服务的开发、测试、生产环境如何区别组可以用来区别区别开发、测试、生产环境dataid - 配置集 一个配置集就是一个配置文件 实际上可以更灵活
gin集成nacos
nacos-sdk-go地址
go操作nacos
package mainimport (fmttimegithub.com/nacos-group/nacos-sdk-go/clientsgithub.com/nacos-group/nacos-sdk-go/common/constantgithub.com/nacos-group/nacos-sdk-go/vo)
func main(){sc : []constant.ServerConfig{{IpAddr: 192.168.1.103,Port: 8848,},
}cc : constant.ClientConfig {NamespaceId: c1872978-d51c-4188-a497-4e0cd20b97d5, // 如果需要⽀持TimeoutMs: 5000,NotLoadCacheAtStart: true,LogDir: tmp/nacos/log,CacheDir: tmp/nacos/cache,RotateTime: 1h,MaxAge: 3,LogLevel: debug,
}
configClient, err : clients.CreateConfigClient(map[string]interface{}{serverConfigs: sc,clientConfig: cc,
})
if err ! nil {panic(err)
}content, err : configClient.GetConfig(vo.ConfigParam{DataId: user-web.yaml,Group: dev})if err ! nil {panic(err)}fmt.Println(content)err configClient.ListenConfig(vo.ConfigParam{DataId: user-web.yaml,Group: dev,OnChange: func(namespace, group, dataId, data string) {fmt.Println(配置⽂件变化)fmt.Println(group: group , dataId: dataId , data: dat},})time.Sleep(3000 * time.Second)
}如何将nacos中的配置映射成go的struct
转换地址 https://www.json2yaml.com/convert-yaml-to-json
