作者回复: Consul没办法对你的节点做健康检查,所以认为节点不能使用,消费者自然也就无法获取到waiter-service,你试试关了健康检查,应该就能获取到服务提供者了,management.health.consul.enabled=false
作者回复: 分布式事务方面,JTA这样的还是挺重的,一般都不太会用,你可以了解一下BASE、TCC等理论,不少实践都是基于它们来的。
作者回复: 我们连的是本地的Consul Agent,Agent负责去连接Consul的集群,而不是我们的程序直接去连接Consul集群,关于这点可能是我没能在课程中讲的太明白,可以访问Consul Agent的文档看看 https://www.consul.io/docs/agent/basics.html
作者回复: Consul的集群是Consul自己的事情,在本地启动一个Consul Agent,Spring Cloud Consul连接这个Agent就行了。这个问题有人提过,Spencer Gibb的答复可以看这里 https://github.com/spring-cloud/spring-cloud-consul/issues/307
作者回复: 关于这个问题可以参考一下第111讲中ABC同学的留言
作者回复: 客户端没有从服务注册中心获取到可用的watier-service,检查下Consul的控制台,看看是不是这样的,健康检查没通过。
作者回复: 不同环境用不同的consul集群是否可以满足你的要求呢?不过我觉得你直接在一套consul里用不同profile来区分环境应该也是可以的吧。一般在实践中,我们还是会把生产环境和非生产的环境完全分开,不混在一起。
作者回复: 1. 你可以先了解一下SOA,然后再来理解一下微服务。前后端分离是前端和后端拆开,后端为了实现某一个功能,还可以组合多个服务来实现。然后你说的每个服务都部署若干个,事实上也是这么做的,不管是不是微服务,我们其实都要求集群化部署。
2. 这几讲都是在介绍注册中心,Eureka、ZK、Consul这些都是不同的注册中心,在Spring Cloud的封装下,看起来用法很接近,你根据你的场景挑选一个用就好了。
作者回复: 不用,这样就太麻烦了,没人会这样么搞的
作者回复: 我倒是觉得你可以把为什么没注册上的问题搞搞明白可能会更有帮助一些,毕竟维护两套不同的东西也有成本,我相信你的问题是能解决的。
作者回复: 无法注册上去的报错信息能提供一下么?配置还是要持久化的,我们线上成千上万的配置,不持久化丢失了就是个灾难。
作者回复: 你指的APP是指什么呢?手机应用?如果是的话,那你可能理解错了,手机APP访问后端REST服务的接口,那应该是先经过服务网关或者一层对外的负载均衡,比如Nginx,Nginx把请求发到后端的内部服务A上,你的内部服务用的Consul做服务发现和注册,服务A通过Consul再找到服务B去调用。