caddy 实现高可用的负载均衡
2022-10-19 本文已影响0人
Newzer
背景:
今天搭好了第二个租车服务实例,第一个服务实例的访问地址是bike1,第二个服务地址是bike2,是两个不同的域名,之前公司的多实例的项目都是不同的域名,由前端去实现负载均衡,这个算法是另外一个同事实现的,大概就是如果一个地址挂了,就把这个地址从地址池中去掉,另外访问其他的地址,所有前端都是用的这个算法来访问多实例的后端服务,所以我跟他们说我多加了个实例时,公司的前端同事很习以为常地把这个bike2 加入到他们的地址列表中,但是当我告诉外包同事让他也这样做时,跟我当初的反应是一样的,认为应该服务端去做这个事情,而不是客户端去做,我没有办法说服他,但他告诉我一个事实:caddy 也能实现负载均衡,因此我决定试一试(之前我并不清楚这个,只是做了简单的反向代理)
先来一个简单配置:
版本1:
bike2 {
reverse_proxy {
to bike1 127.0.0.1:8090
}
}
测试了一下:报了一个重定向次数过多的错,因为bike1 也是caddy 的反向代理实现的,所以第二次我换了一个ip来
版本2:
bike2 {
reverse_proxy {
to ip1:8090 127.0.0.1:8090
lb_policy random //随机轮询
}
}
测试了一下:能实现负载均衡,但是当分发到 ip1的时候会502(因为ip1 的端口没开通),分发到第二个本地地址的时候是正常的,所以并不是高可用
版本3:
bike2 {
reverse_proxy {
to ip1:8090 127.0.0.1:8090
lb_policy random
lb_try_duration 2s //重试等待时间
}
}
测试一下,可以正常了,基本都能得到正确响应
啦啦啦啦