【K8S运维知识汇总】第5天6:交付dubbo服务的消费者集群到K8S

网友投稿 951 2022-11-27

k8s运维知识汇总】第5天6:交付dubbo服务的消费者集群到K8S

【K8S运维知识汇总】第5天6:交付dubbo服务的消费者集群到K8S

把dubbo服务的提供者和monitor都交付给k8s里了

下面交付dubbo服务的消费者,需要借助Jenkins的持续集成

这一条流水线,可以构建dubbo服务的提供者又可以用来构建dubbo服务的消费者

构建dubbo服务的消费者consumer,消费者是要用到ssh公钥,因为要去和git链接

public是consumer,private是web

如果要去拖dubbo-demo-web的项目的时候,需要用ssh通道

暂且用master分支,-e -q输出的就少

开始构建了

**先 git clone,然后checkout **

repository是本地缓存。第二次编译,有这些jar包就快了

到blue ocean看第二次构建

现在要交付消费者,就要准备资源配置清单。套路就是把项目构建成,打个包扔到harbor仓库,然后准备资源配置清单。

需要三个资源配置清单

改一下时间

env是,jar_ball是dubbo-client.jar

第二步,创建svc.yaml

docker容器了是监听的8080,映射的clusterip也是8080

docker-monitor,是在172.7.21.8

docker-monitor,是监听在clusterip192.168.117.64 8080端口上。jenkins是80端口监听在了192.168.88.235上

k8s最核心的资源,三种:pod控制器,svc,ingress,往k8s交付都是这种套路

用的域名是demo.od.com

解析域名,前滚serial

现在还要依次应用资源配置清单

起来了

消费者启动

docker-monitor刷新就有consumer了

这里有consumer的这样一个接口

去zk注册了订阅一个方法

这就是dubbo-demo消费者端

这个hello就是从请求的消费者端,里面去调用helloService.hello,就好像在调用本地的方法一样

提供者才真正实现hello方法

消费者在调用hello方法的时候就好像在调用本地方法

pod控制器,有dubbo服务的消费者和提供者,可以分别扩容

加入高并发来了,可以直接扩容3份

pod里dubbo service就有3个了

dubbo服务的service和consumer,就是典型的没有状态的服务,可以随便扩容

前端根本毫无感觉,dubbo内部就会做负载均衡

这里的负载均衡是k8s做的,consumer可以扩容2份

traefik就对应了两个dubbo-demo-consumer,相当于traefik帮你找到了两个后端真实的server,对应podip,实际上抗前端的流量,帮你分成2个,再帮你调用后端service的时候,就变成3个,这个负载均衡机制是dubbo做的

dubbo可以在内网替代负载均衡,软负载均衡及容错机制,实际上是消费者靠dubbo软负载机制,可以前后端分别扩容

点点鼠标就完成了资源扩容和回收

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:【K8S运维知识汇总】第5天5:交付dubbo-monitor到K8S集群
下一篇:SpringMVC框架中使用Filter实现请求日志打印方式
相关文章

 发表评论

暂时没有评论,来抢沙发吧~