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和端口
