小程序开发安全管理的最佳实践与合规要求
969
2022-11-27
【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小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~