吐槽
以前都是手撸RPC，最近接触SpringCloud，深感痛心。主要有以下几点：
1）代码量巨大，找BUG时间长，超级复杂的设计
2）版本管理混乱，经常出现莫名其妙的配置错误（所以2.0是打死不敢上生产啊）
3）Netflix公司的有些代码，实在是让人费解，根本就不考虑扩展性
4）生态链庞大，学习成本大
建议准备上微服务的同学，固定下一个版本，不要随意更新或降级。拿tomcat的basedir来说，1.5.8到1.5.13到1.5.16版本是换来换去，不小心点会出事故的
如上，basedir先是从.换到file:.，又从file:.换成.，连兼容代码都木有。有木有想打死工程师？
前言
今天主要谈的话题，是平滑的上下线功能。所谓平滑，指的是发版无感知，不至于等到夜深人静的时候偷偷去搞。某些请求时间可以长点，但不能失败，尤其是对支付来说，想花钱花不出去是很让人苦恼的；花了钱买不到东西是很让人恼火的。整体来说，SpringCloud功能齐全，经过一段时间的踩坑后使用起来还是非常舒服的。
我们的微服务，大体集成了以下内容。
嗯，一个庞大的生态
问题
那么问题来了，SpringCloud到注册中心的注册是通过Rest接口调用的。它不能像ZooKeeper那样，有问题节点反馈及时生效。也不能像Redis那么快的去轮训，太娇贵怕轮坏了。如下图：
有三个要求：1）ServiceA下线一台实例后，Zuul网关的调用不能失败 2）ServiceB下线一台实例后，ServiceA的Feign调用不能失败 3）服务上线下线，Eureka服务能够快速感知
说白了就一件事，怎样尽量缩短服务下线后Zuul和其他被依赖服务的发现时间，并在这段时间内保证请求不失败。
解决时间问题
影响因子
1 Eureka的两层缓存问题 (这是什么鬼）
心跳时间
调用者服务从Eureka拉列表的轮训间隔
Ribbon缓存
解决方式
禁用Eureka的ReadOnlyMap缓存 (Eureka端)
启用主动失效，并且每次主动失效检测间隔为3s (Eureka端)
像eureka.server.responseCacheUpdateInvervalMs和eureka.server.responseCacheAutoExpirationInSeconds在启用了主动失效后其实没什么用了。默认的180s真够把人给急疯的。
服务过期时间 （服务提供方）
服务刷新时间配置，每隔这个时间会主动心跳一次 (服务提供方）
默认30s
拉服务列表时间间隔 （客户端）
ribbon竟然也有缓存，默认30s
这些超时时间相互影响，竟然三个地方都需要配置，一不小心就会出现服务不下线，服务不上线的囧境。不得不说SpringCloud的这套默认参数简直就是在搞笑。
重试
那么一台服务器下线，最长的不可用时间是多少呢？（即请求会落到下线的服务器上，请求失败）。赶的巧的话，这个基本时间就是eureka.client.registryFetchIntervalSeconds+ribbon.ServerListRefreshInterval,大约是8秒的时间。如果算上服务端主动失效的时间，这个时间会增加到11秒。
如果你只有两个实例，极端情况下服务上线的发现时间也需要11秒，那就是22秒的时间。
理想情况下，在这11秒之间，请求是失败的。加入你的QPS是1000，部署了四个节点，那么在11秒中失败的请求数量会是 1000 / 4 * 11 = 2750，这是不可接受的。所以我们要引入重试机制。
SpringCloud引入重试还是比较简单的。但不是配置一下就可以的，既然用了重试，那么就还需要控制超时。可以按照以下的步骤：
引入pom （千万别忘了哦)
加入配置
发布系统
OK,机制已经解释清楚，但是实践起来还是很繁杂的，让人焦躁。比如有一个服务有两个实例，我要一台一台的去发布，在发布第二台之前，起码要等上11秒。如果手速太快，那就是灾难。所以一个配套的发布系统是必要的。
首先可以通过rest请求去请求Eureka，主动去隔离一台实例，多了这一步，可以减少至少3秒服务不可用的时间（还是比较划算的）。
然后通过打包工具打包，推包。依次上线替换。
市面上没有这样的持续集成哦你工具，那么发布系统就需要定制，这也是一部分工作量。
到此，仅仅是解决了SpringCloud微服务平滑上下线的功能，至于灰度，又是另外一个话题了。有条件的公司选择自研还是很明智的，不至于将功能拉低到如此的水平。
不过大体不用担心，你的公司能不能活下去，还是一个未知数。Netflix都忍了，在做的各位能比它强大么？
网友评论