sidecar模式有点像适配器模式或装饰者模式
微服务这块,开源的sidecar有奈飞和阿里,考虑到spring cloud剥离奈飞组件的原因,试用了一下阿里的sidecar。
采用sidecar的原因:
非java项目注册到nacos;
nacos管理项目状态;
消费者从nacos发现服务,通过feign调用接口,负载均衡、高可用性
sidecar的网络位置

项目示例:
1,非java项目:

端口5000的flask服务,其中/health是给sidecar用来维持心跳的接口,返回json对象表示状态up,这种状态会反馈在nacos里表示服务状态。
/api/parts是演示服务接口。
这样的flask服务是没法注册到spring cloud微服务框架的。
2,sidecar项目
pom:

所以sidecar项目其实也是个spring boot程序,添加2个依赖,阿里的sidecar,和nacos-discovery。
bootstrap.yml:

8088是sidecar的端口,理论上也应该是注册到nacos的端口和对外服务的端口,但是好像不是的
配置中的sidecar部分,ip和port就是非java服务的ip和端口,health-check-url就是保持心跳用来发现服务是否活着的api
项目启动后在nacos能看到这个服务

如果我把flask服务关闭后,这条服务就消失了,能看到如下日志

说明sidecar在检测服务失败后,然后去nacos注销了,默认每30秒测试一次。
如果启动flask服务后,nacos上又有服务了。
然后

然后看到服务注册就是非java项目的ip和端口

网友评论