在上文章中我们已经介绍了负载均衡的相关概念以及在服务高可用架构中的重要性也了解了几种主流负载均衡算法的实现。在本文中我们将在Go微服务实例中具体使用负载均衡技术并详细说明如何基于服务发现来实现负载均衡的微服务间HTTP 调用。基于服务发现和注册的负载均衡我们仍然以之前课时提到的电商商品系统为例商品详情页面需要展示下游评论系统的具体评论信息所以商品系统通过HTP请求调用评论系统获取商品评论。下图展示了两个系统的交互情况:评论系统单实例性能欠佳需要多实例部署平均请求压力而商品系统则需要在发起请求前从所有可用的评论系统实例中挑选一个再发起请求。查看商品详情的外部请求数量往往在促销时增加因此评论系统实例的数量并不是固定的而是动态变化的请求量大时增加服务实例请求量少时则减少服务实例。所以商品系统的负载均衡机制需要基于服务注册与发现机制动态获取评论系统的可用实例列表而不是将其固化在代码或者配置文件中。下面我们就来具体看一下如何在商品系统项目中实现负载均衡。本文的相关代码在课程代码库中的section28 文件夹下地址为Account security服务初始化首先我们需要使用前面文章中讲解的基于Consul的负载均衡客户端头若是记不太清了你可以回过再温故一下。下面代码展示了商品系统在启动时的初始化过程:// 传入consul的地址和端口初始化服务注册和发现客户端 client : discovery.NewDiscoveryClient(*consulAddr, *consulPort) // 使用uuid生成客户端实例ID instanceId : *serviceName - uuid.New() .String() // 将实例自己注册到consul上包括服务名称实例ID健康检查地址host和端口等 err : client.Register(context.BackgroundO, *serviceName, instanceId, /health,*serviceAddr, *servicePort nil, nil) // 初始化负载均衡器可以初始化携带不同负载均衡策略的负载均衡器 loadbalancer : loadbalancer.NewRandomLoadBalancer() // 使用服务注册与发现客户端和负载均衡器初始化service srv : service.NewGoodsServiceImpl(client, loadbalancer)其中loadbalancer是本课时的重点它是定义负载均衡策略的接口只有一个 SelectService方法接受 Servicelnstance 也就是可用服务列表作为参数根据一定负载均衡策略人服务实例列表中选择一个服务实例返回。而可用服务列表则可以通过服务注册和发现客户端人Consu等服务注册和发现中心获取。// 负载均衡器 type LoadBalance interface { // 基于可用服务列表的负载均衡接口 selectservice(service []common.ServiceInstance) (common.Service Instance, error) // 基于可用服务列表和键值辅助的负载均衡接口 SelectServiceByKey(service []*discovery.InstanceInfo, key string) (*discovery.InstanceInfo, error) }具体的负载均衡器都要实现该接口并给出具体不同负载均衡策略的 SelectService方法的实现比如上文中介绍的随机负载均衡策略和权重平滑负载均衡策略。我们下面再讲解一下项目中使用的一致性负载均衡策略根据商品ID将不同的获取商品评价的HTTP请求分发到某一个固定的评级服务实例上这样有利于使用本地缓存等缓存机制提高系统的性能。一致性哈希负载均衡的核心思想是首先将服务器 key 进行 Hash 运算将其映射到一个圆形的哈希环上key计算出来的整数值则为该服务实例在哈希环上的位置然后再将请求的key值用同样的方法计算出哈希环上的位置按顺时针方向找到第一个大于或等于该哈希环位置的服务实例key从而得到本次请求需要分配的服务实例。如上图所示服务实例node1~4 都计算出 Hash值并映射到哈希环上而请求的key值也能计算出Hash值并映射到环上如图右侧的键值然后按照顺时针方向找到了服务实例node2则该请求就被负载转发到服务实例上。一致性哈希负载均衡策略能够很好地应对服务实例上线或者下线的场景以防止大量请求被负载转发到不同的服务实例减少其对整体系统带来的影响而一般的哈希负载均衡策略就很难满足这点。比如说服务实例node2 突然宕机下线按照该算法只有Hash 值落在在服务实例node1和node2之间的请求受到了影响被负载转发到了服务实例node4上其他的大部分请求不受影响。一致性哈希负载均衡策略的具体实现如下所示:type HashLoadBalancer struct { } func (loadBalance *HashLoadBalancer) SelectServiceByKey(services []*discovery.InstanceInfo, key string) (*discovery.InstanceInfo, error) { // 检查可用服务实例列表不为空 lens : len(services) if services nil ll lens 0 { return nil, errors.New(service instances are not exist) } // 使用crc32将key值算出hash值 crcTab1e : crc32.MakeTab1e(crc32.IEEE) hashVal : crc32.Checksum([]byte(key), crcTable) // 根据hash值和列表长度取余获得服务实例 index : int(hashVal) % lens return services[index],nil }在使用该负载均衡策略时我们就将商品 ID 作为 key 值传递进来该算法会使用crc32 计算该商品 ID对应的Hash值然后根据取余结果从可用服务列表选出本次负载均衡的目标实例。发起网络请求商品系统服务和评论系统初始化启动好之后对外建立HTP服务当有用户查看详情时商品系统会向评论系统发起网络请求具体代码如下所示func service *GoodsDetailserviceImpl) GetGoodsComments(ctx context.Context, id string) (common.CommentResult, error) { var result common.CommentResult // 使用服务注册和发现客户端从consul中获取名为comment的可用服务实例列表 serviceName : comment instances, err : service.discoveryclient.DiscoverServices(ctx, serviceName) .... // 省略异常检查 // 使用负载均衡器根据商品id和可用服务实例列表获取本次网络调用的目标comment服务实例 selectedInstance, err2 : service.loadbalancer.Selectservice(instances,id) if err2 ! nil { log.Printf(loadbalancer get selected instance err: %s, err2) return result, ErrLoadBalancer } call_err : hystrix.Do(serviceName, func) error { // 使用选中comment服务实例的信息来拼接HTTP请求 requesturl : url.uRL{ Scheme: http, Host: selectedInstance.Address : strconv.Itoa(selectedInstance.Port), Path: /comments/detail, RawQuery: id id, } resp, err : http.Get(requesturl.String()) .... // 省略 }, func(e error) error { // 断路器打开时的处理逻辑本示例是直接返回错误提示 return errors.New(Http errors! ) }) .... //省略 }所以每次发起查询商品评论信息的网络请求前都会先调用服务注册和发现客户端的DiscoverServices方法来获取当前 comment可用的服务实例列表然后调用负载均衡器的SelectService方法根据商品的ID从可用列表中选中一个服务实例最后根据该服务实例的信息构建网络请求比如 host 和 port信息等。整个过程如下图所示:基于服务发现和注册的负载均衡示意图以上就是在 Go微服务中实现客户端负载均衡的主流实现原理很多开源负载均衡器比如Ribbon等都是以这套原理实现的不过这个过程还是有许多可以优化的细节比如负载均衡客户端可以使用缓存可用服务列表数据等方式来避免每次都从Consu处获取可用服务列表数据以此提高效率。运行展示下面我们就来具体运行和展示一下本课时的案例项目。首先我们启动一个商品系统服务good和三个评论系统服务comment它们都会将自己注册到服务注册和发现中心Consul上。如下是 Consul相关的截图:我们可以从Consul 的服务列表页面发现有三个comment 服务实例和一个商品服务实例这三个comment服务实例的具体信息如下图所示从图中可以看出它们的host信息都是127.0.0.1但是端口号不同你也可以将这三个 comment服务实例部署在不同IP 地址的服务器上这样它们的 host信息就不一样了。接着我们使用 postman 或者 curl向good 发起查看多个商品详情的网络请求请求多次具体命令如下所示:cur1 http://127.0.0.1:12313/goods/detai1?id1 curl http://127.0.0.1:12313/goods/detai1?id2 cur1 http://127.0.0.1:12313/goods/detai1?id3然后我们到good服务实例的日志中进行查看可以看到如下日志信息get good 1 comment from comment service host:127.0.0.1 port 13312 get good 2 comment from comment service host:127.0.0.1 port 11312 get good 3 comment from comment service host:127.0.0.1 port 12312 get good 1 comment from comment service host:127.0.0.1 port 13312 get good 2 comment from comment service host:127.0.0.1 port 11312 get good 3 comment from comment service host:127.0.0.1 port 12312从日志中可以看出不同ID的商品会请求不同的comment服务实例并且不会改变请求的实例这正是使用一致性哈希负载均衡策略想要得到的效果。接下来我们将端口号为11312的comment 服务下线此时就只有两个comment服务实例我们再次发起上述的查询商品详情的请求可以看到如下日志:get good 1 comment from comment service host:127.0.0.1 port 13312 get good 2 comment from comment service host:127.0.0.1 port 13312 get good 3 comment from comment service host:127.0.0.1 port 12312 get good 1 comment from comment service host:127.0.0.1 port 13312 get good 2 comment from comment service host:127.0.0.1 port 13312 get good 3 comment from comment service host:127.0.0.1 port 12312从这段日志我们可以看出原来 ID为1的商品详情会向端口为13312的comment服务实例进行请求现在也是如此而且ID 为3的商品详情也跟原来一样都是向端口为12312 的服务实例进行请求二者没有发生变化这也是一致性哈希负载均衡策略的功效。小结在本文我为你讲述了在 Go微服务中使用基于服务注册和发现的负载均衡机制通过该机制可以很方便地为下游集群增加和删除服务实例上游服务也可以对其进行自动适配和负载均衡。除此之外我们还以商品详情为例给出了Go微服务负载均衡机制的具体实现向你展示了使用一致性哈希负载均衡策略将请求发送给不同评论服务实例的场景。