本文介绍了OpenResty如何实现基于服务发现的动态Upstream，通过应用向Redis发布心跳消息，OpenResty订阅并维护服务状态，实现流量的动态转发。服务直接调用与统一网关调用的对比，以及借助Redis的实现方式，包括服务上线、下线通知，动态维护OpenResty中的服务信息，并讨论了Reload和Restart的影响，以及重试、负载均衡等策略。
从Nginx加虚拟机部署后端服务转向使用Docker部署时，Nginx配置转发可能面临一个问题：“每次运行的Docker容器的IP不固定，应如何配置Upstream让流量正确转发”。低成本的方式一般是使用docker run -p ip:hostPort:containerPort将容器端口映射到虚拟机，这样Upstream的配置几乎不变。
本文这次主要介绍另一种方式：“OpenResty基于服务发现的动态Upstream”，相比较端口映射方式在可靠性与灵活性上有所提升。
交互图
应用节点通过向Redis publish自己alive的消息，OpenResty则subscribe Redis维护应用以及其alive的节点信息，收到请求时动态转发到特定应用存活节点上。
应用即服务，后文并不明显区分两者
服务发现概述
存在中心网关场景下的服务发现在笔者的眼中并不复杂，但在阅读一些技术文章中的方案时，觉得被描述的过于高深和复杂化，从笔者角度来说，基于配置中心的服务发现内容主要有如下四点：
- 配置中心
- 服务上线，上报配置中心
- 服务离线，上报配置中心
- 健康检查
方案总结描述：“服务自身将状态（name，ip，port…）维护在配置中心（上线添加，离线删除），调用者读取配置中心确认
最低0.47元/天 解锁文章
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
