黑马程序员21年微服务课程笔记三：p19-p20 nacos服务的集群以及负载均衡

学java月薪2k的小菜鸟

已于 2024-10-11 14:45:34 修改

阅读量1.6k

点赞数 25

分类专栏：微服务文章标签：微服务笔记负载均衡

于 2024-10-11 14:44:35 首次发布

本文链接：https://blog.csdn.net/weixin_63503796/article/details/142849479

版权

微服务专栏收录该内容

3 篇文章 0 订阅

订阅专栏

一、nacos服务的集群

首先我们要了解到微服务就是将一个项目中的多个模块拆分成一个个的子项目子项目在nacos中注册这么一个微服务方便微服务对所有模块进行管理和相互之间的调用

那么好一些大公司大厂的项目就拿黑马课程上的项目举例子 user模块和order模块如果我只是分别为他们注册一个微服务服务器的地点放在我的老家江西赣州那我的所有用户对我的项目进行访问如果是江西的还好因为服务器地点就在赣州访问速度很快那好如果这时候有个巴西外国友人来访问服务器距离这么远访问速度也就慢而且如果只有一个服务器的话在应对高并发的问题时不管是多nb的服务器也要崩溃所以大公司大厂通常在不同的地点设置多个服务器这样就解决了这两个问题那好同一个地方的多个服务器就叫做nacos的地域集群

不知道大家有没有玩过永劫无间游戏里就有很多节点北京节点杭州节点成都节点广州节点其实道理是类似的为什么要设置这些节点就是为了平衡游戏玩家的网络延迟如果只有一个杭州节点那么住杭州的人打游戏是不是就比住新疆的人打游戏流畅呢这就违背了游戏的公平

让我们回归代码

我们现在user模块中的yml文件中添加集群

然后userapplication 在nacos平台上查看userservice的详情

集群这块从一开始 defalut变成了我们自己定义的名字我这里是BJ

让我们修改一下user模块的yml文件换一个集群名字换成NC 然后复制两个userapplication实例修改端口号分别为8082 8083

添加好两个不同端口号的实例后分别启动

我们发现三个user服务 8081和8082在NC集群 8083在BJ集群这是不是就实现了上面结构图中所描述的呢

诶其实还差一步细心的网友可能要问那你的集群里就只有user服务吗 order服务呢

还是一样在order模块的yml文件中如上图一样配置集群名字后 order也在BJ集群里了

二、负载均衡

什么是负载均衡呢假设现在有两个集群南昌集群和北京集群分别都有一个user服务和order服务让南昌周围的用户使用南昌集群的服务让北京周围的用户使用北京集群的服务这其实就是负载均衡的一种

负载均衡不止上面的例子那么简单有时候考虑到服务器体量能力大小各不相同还有上述的地域问题这就产生了很多负载均衡的算法黑马的课程中让我们实现优先调用相同集群的服务的功能就是说北京的order优先调用北京的user

在nacos1.x的版本中呢 nacos discovery的依赖包里已经为我们写好了这种同集群优先的算法我们只需要在yml文件中引入就可以了

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule

在上面的代码中 userservice表示了当模块在调用在nacos上注册过名为userservice的服务时采用下面写好的算法的负载均衡策略

这里有一个问题那就是21年黑马的课程中使用的版本是1.x的我的nacos是2.x的所以我发现这样并没用

问题1：在网上找有评论说是因为nacos2.x的ribbon的负载均衡策略中没有同集群优先了

问题2：在笔记一中在order的service层中把端口号写死了导致只有8081端口的user服务呗调用

所以我是没有成功体现出负载均衡问题二肯定是直接原因但如果要改黑马的课程中也没有体现课程中在yml文件中加上配置就可以实现了并没有对这块的代码有修改然后视频中的同集群优先的负载均衡也确实实现了

！！！！！！！！大家是不是以为这篇笔记就要到此为止了

nonono

于是我打开了黑马最新的微服务课程 24年的版本直接跳到nacos的部分研究了一下发现 24年的版本没有讲这种区域集群而是直接引入负载均衡下面就是实现过程

首先还是一样项目中必须引入nacos的discovery的依赖

然后在queryOrderById方法中修改写死的端口号既然2.x的版本没有现成的算法用那我们就自己写嘛

负载均衡有两种最基础的策略一种是随机策略一种是轮询策略

随机好理解轮询呢就是遍历循环的意思我们先来写随机

@Autowired
    private DiscoveryClient discoveryClient;

首先注入一个discoveryClient类的变量这个变量有个方法可以让我们获取在nacos上注册过的服务你只需要提供这个服务的名字他能将所有这个名字不同端口号的不同实例化服务打包给你

既然不止一个的话是不是需要用java很方便的list集合接收一下

List<ServiceInstance> instances = discoveryClient.getInstances("userservice");

到这里大家有思路了吗随机随机生成个随机数再用list的get不就好了吗

if (!instances.isEmpty()) {
         ServiceInstance serviceInstance = instances.get(RandomUtils.nextInt(instances.size()));
         String url = "http://localhost:" + serviceInstance.getPort() + "/user/" + order.getUserId();
          User user = restTemplate.getForObject(url, User.class);
          order.setUser(user);
          order.setPort(serviceInstance.getPort());
}

代码如上需要注意的是这个最外层的if是为了防止instances中为空随机数的取值范围应从0-list集合的最大下标也就是在list.size()+1中个实例中随便选一个

到此恭喜大家已经手敲了一个负载均衡算法！！！简历上可以写精通负载均衡了

这是24年黑马课程中写的随机负载均衡我本人觉得轮询也没问题就尝试着写了一下

轮询就是遍历再重头来循环假设现在有三个端口的实例 80 81 82 轮询的策略就是这次80 下次81 下下次82 下下下次又回到80 了解了需求原理思路是不是也一下子打开了

我们可以定义一个变量index作为指针记录当前集合下标先赋值0 每获取一个实例的时候

index++ 然后对index++用实例的数量取模

回到上面的例子 80的下标是0 以此类推当用到82的时候 index为 2+1=3 然后3%3=0 又回到了80

if(!instances.isEmpty()){
            ServiceInstance serviceInstance=instances.get(serviceIndex);
            serviceIndex=(serviceIndex+1)%instances.size();  
            String url = "http://localhost:" + serviceInstance.getPort() + "/user/" + order.getUserId();
            User user = restTemplate.getForObject(url, User.class);
            order.setUser(user);
            order.setPort(serviceInstance.getPort());
        }

到这里轮询负载均衡完成了

为了方便测试我在order类中加了一个port的属性用来记录当前调用的user服务的端口号

接着在浏览器中查询订单

不断刷新你会发现端口号要么是递增要么是递减的这取决于list中是由大到小还是由小到大