Spring多数据源实现的方式大概有2中，一种是新建多个MapperScan扫描不同包，另外一种则是通过继承AbstractRoutingDataSource实现动态路由。今天作者主要基于后者做的实现，且方式1的实现比较简单这里不做过多探讨。

代码git地址 feature [x] 灰度服务 [x] 配置中心 [x] 动态路由 前言 上篇文章介绍了SpringCloud灰度的实现及流程，每次修改服务的元数据信息metadata-map值需要重新调用一次eureka的RestFul接口，不仅如此当服务重启后又会重新读最初的配置值，这样不仅麻烦而且还不可靠。 在经过与SpringCloud Config 、Disconf、Apollo...

​ 在平时的业务开发过程中，后端服务与服务之间的调用往往通过fegin或者resttemplate两种方式。但是我们在调用服务的时候往往只需要写服务名就可以做到路由到具体的服务，这其中的原理相比大家都知道是SpringCloud的ribbon组件帮我们做了负载均衡的功能。

如上配置,配置信息非常简单.在启动eureka-server的时候并未发现任何异常,但是在启动eureka-client的时候,控制台却输出如下信息:

限流算法 常见的限流算法 计数器算法 漏桶算法 令牌桶算法 计数器算法   顾名思义,计数器算法是指在一定的时间窗口内允许的固定数量的请求.比如,2s内允许10个请求,30s内允许100个请求等等.如果设置的时间粒度越细,那么相对而言限流就会越平滑,控制的粒度就会更细. 场景分析 试想,如果设置的粒度比较粗会出现什么样的问题...