服务发现
实现方式
-
ServiceRegistry
通过Lifecycle进行服务的启动
-
DiscoveryClient
通过服务的id获取服务列表
注意看：springCloud-Commos模块
使用
选型：consul或者Nacos
consul
启发
-
建立在KV存储、一致性理论基础上的服务
-
DNS网络部分
dig命令
问答
问：
当把eureka server 部署到K8S后，因为不需要外部访问它，所以不用配ingress，但是怎么能看到那个spring cloud eureka 页面呢？比如你在本地eureka server 启动起来后，可以通过http://localhost:8761来访问，如果是部署到K8S 后，该如何访问？可能我理解的不对，请指正，多谢
答：
偷懒的话可以直接用nodePort把这个pod的eureka端口暴露出来，如果真的要在产线使用，最好还是配置下ingress吧
问：
如果consul是集群，是不是我只需要配置 spring.cloud.consul.host 为集群中的一个节点即可，连接集群时会把其他节点信息也相互进行同步， 如果只连接集群的一个节点，如果连接的这个节点宕机了，会不会导致整体consul集群不可用。
答：
我们连的是本地的Consul Agent，Agent负责去连接Consul的集群，而不是我们的程序直接去连接Consul集群，关于这点可能是我没能在课程中讲的太明白，可以访问Consul Agent的文档看看 https://www.consul.io/docs/agent/basics.html
问：
请问下springcloud支持consul 这个 spring.cloud.consul.host 配置只支持单个节点？ 集群要怎么配置？ 我查了些资料说 consul还有个严重的问题，就是不能自动剔除掉已经失效的服务? 这个是否修复了？
答:
Consul的集群是Consul自己的事情，在本地启动一个Consul Agent，Spring Cloud Consul连接这个Agent就行了。这个问题有人提过，Spencer Gibb的答复可以看这里 https://github.com/spring-cloud/spring-cloud-consul/issues/307
问：
我想问下这些Eureka，nacos等做注册中心，客户端先从服务中心拉去具体服务实例地址然后服务调用和直接用集群管理工具，比如说K8S来管理所有docker上跑的java实例，然后对外只暴露一个域名，客户端完全不用关心服务在哪，只需要调用这个域名对应的服务就行，K8S会自动做负载均衡，滚动发布等处理，这两种方式有什么区别？各有什么优劣呢？如果用第二种的话，完全不用在客户端引入注册发现的依赖是不是挺好的，相当于简化开发。
答:
你说的是在K8S里内部访问可以走Service，Pod起来健康检查通过后就会加入到Service里，由K8S来维护负载均衡，外部访问服务用Ingress。这只在K8S里能用，而Eureka、Nacos这些不受限于环境。
服务配置
服务提供方
客户方
-
客户端
Spring-Cloud-starter-config
-
服务发现方式
spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.service-id=configserver
-
配置刷新
@RefreshScope
refresh是通过actuator来触发的， curl -X POST http://localhost:8080/actuator/refresh
还有一种：SpringCloud Bus - RefreshRemoteApplicationEvent
SpringCloudConfig的抽象
-
SpringCloud提供了了一套与Spring应用中Environment与PropertySource相兼容的抽象
PropertySource：
SpringCloudConfigClient - CompositePropertySource
Consul - ConsulPropertySource / ConsulFilesPropertySource
这些PropertySource在本地配置文件的PropertySource之前
PropertySourceLocator：
从Environment中找到PropertySource
-
BootstrapConfiguration
-
Stream.of
-
Environment与配置文件之间的关系
Consul
服务熔断
基本概念
circuitbreaker断路器也是在客户端做的，将错误的调用指向制定的返回
custom-Service（客户端）会做bulkhead隔舱控制，控制并发与等待
watier-Service（服务端）会做rateLimiter，控制一段时间的访问量
问答
问：
老师您好，请教下如果我一个服务有多个节点，其中一个节点down 掉了，但是注册中心没有及时发现，这个时候用户进行访问刚好路由到了这个down 的节点，这个时候如果做断路由那不是其他没有问题的节点也访问不到了。请问这种情况怎么 处理？
答：
给个思路，我们是可以知道具体调用的目标节点的，如果发现单个节点连续失败，只需对单节点触发熔断就行了，无需每次都对整体熔断。
问：
熔断只在gateway服务做就可以了吧，没必要每个服务都做吧
答：
gateway负责对外的熔断，内部系统之间也会需要保护，所以如果可以的话，内部也要加。
问：
我们这门课程是不是少了个网关模块呀
答：
的确是没有设计这个环节，因为Zuul2虽然有了，但Spring官方也不集成了，自己搞了Spring Cloud Gateway。但网关有点特殊，很多企业都会结合自己情况又去开发定制，或者选择Spring Cloud Gateway以外的东西，所以设计课程时，我思考了一下，就没纳入大纲。
消息中间件
基本概念
问答
问：
老师您好，消息的防重和顺序有哪些好的解决方案吗？
答：
关于重复的问题，建议让业务逻辑自己来做幂等性控制，总有什么ID能做幂等控制的。顺序，不管怎么样，我建议你都认为消息可能会乱序，消费者这里要考虑乱序的情况，比如处理某个订单的消息时有状态机之类的设计，已经推进到后面的状态了，这时再来个之前状态的消息，就直接忽略掉这个消息。
答：
幂等表是一种常见的做法，因为幂等是和业务有紧密关系的，所以幂等表也是跟着业务走的，而不是千篇一律都是一样的。对于消息而言，不仅要考虑重复，还要考虑乱序，有时一条消息后续还有别的消息，后续的消息处理过了，那前面那条到晚了，也不能按原先逻辑处理，所以这些都要由业务系统来实现这些功能，MQ本身不应该介入在其中。
服务链路追踪
why
- 服务依赖图
- 常见请求的执行路径
- 每个环节的执行是否正常
基本概念Dapper
可选：
sleuth
zipkin