以前都是手撸RPC,最近接触SpringCloud,深感痛心。主要有以下几点:
1)代码量巨大,找错误时间长,超级复杂的设计
2)版本管理混乱,经常出现莫名其妙的配置错误(所以2.0是打死不敢上生产啊)
3) Netflix公司的有些代码,实在是让人费解,根本就不考虑扩展性
4)生态链庞大,学习成本大
建议准备上微服务的同学,固定下一个版本,不要随意更新或降级。拿tomcat的basedir来说,1.5.8到1.5.13到1.5.16版本是换来换去,不小心点会出事故的。
如上,basedir先是从。换到文件:,又从文件:。换成,连兼容代码都木有,有木有想打死工程师?
今天主要谈的话题,是平滑的上下线功能。所谓平滑,指的是发版无感知,不至于等到夜深人静的时候偷偷去搞。某些请求时间可以长点,但不能失败,尤其是对支付来说,想花钱花不出去是很让人苦恼的,花了钱买不到东西是很让人恼火的。整体来说,SpringCloud功能齐全,经过一段时间的踩坑后使用起来还是非常舒服的。
我们的微服务,大体集成了以下内容。
嗯,一个庞大的生态
那么问题来了,SpringCloud到注册中心的注册是通过其他接口调用的。它不能像动物园管理员那样,有问题节点反馈及时生效。也不能像复述,那么快的去轮训,太娇贵怕轮坏了。如下图:
有三个要求:
1) ServiceA下线一台实例后,Zuul网关的调用不能失败2)ServiceB下线一台实例后,ServiceA的装调用不能失败3)服务上线下线,尤里卡服务能够快速感知
说白了就一件事,怎样尽量缩短服务下线后Zuul和其他被依赖服务的发现时间,并在这段时间内保证请求不失败。
<强>影响因子
1)尤里卡的两层缓存问题(这是什么鬼)
EurekaServer默认有两个缓存,一个是ReadWriteMap,另一个是ReadOnlyMap。有服务提供者注册服务或者维持心跳时时,会修改ReadWriteMap。当有服务调用者查询服务实例列表时,默认会从ReadOnlyMap读取(这个在原生尤里卡可以配置,SpringCloud尤里卡中不能配置,一定会启用ReadOnlyMap读取),这样可以减少ReadWriteMap读写锁的争用,增大吞吐量.EurekaServer定时把数据从ReadWriteMap更新到ReadOnlyMap中
2)心跳时间
服务提供者注册服务后,会定时心跳。这个根据服务提供者的尤里卡配置中的服务刷新时间决定。还有个配置是服务过期时间,这个配置在服务提供者配置但是在EurekaServer使用了,但是默认配置EurekaServer不会启用这个字段。需要配置好EurekaServer的扫描失效时间,才会启用EurekaServer的主动失效机制。在这个机制启用下:每个服务提供者会发送自己服务过期时间上去,EurekaServer会定时检查每个服务过期时间和上次心跳时间,如果在过期时间内没有收到过任何一次心跳,同时没有处于保护模式下,则会将这个实例从ReadWriteMap中去掉
3)调用者服务从尤里卡拉列表的轮训间隔
4)带缓存
<>强解决方式
1)禁用尤里卡的ReadOnlyMap缓存(尤里卡端)
2)启用主动失效,并且每次主动失效检测间隔为3 s(尤里卡端)
像eureka.server.responseCacheUpdateInvervalMs和eureka.server.responseCacheAutoExpirationInSeconds在启用了主动失效后其实没什么用了。默认的180年代真够把人给急疯的。
3)服务过期时间(服务提供方)
超过这个时间没有接收到心跳EurekaServer就会将这个实例剔除.EurekaServer一定要设置eureka.server.eviction-interval-timer-in-ms否则这个配置无效,这个配置一般为服务刷新时间配置的三倍。默认90年代!
