（1） 相关博文地址：

但这些框架都有类似的问题：进入了维护模式 或者 功能不完善（使用场景有限，无法很好地适应新需求） 模块置于维护模式意味着 Spring Cloud 团队不再向模块添加新功能。仅修复拦截器漏洞和安全问题。 SpringCloud 版本迭代速度挺快的，这就导致了一个问题： 一些旧版本出现的问题还未解决就推出了一个新的版本。 而某模块进入了维护模式，即不再开发新功能，其使用价值有限，使用人数也就逐渐减少，相当于 打入冷宫，难有翻身余地。 一个旧技术的没落，必定有一个新技术取而代之。 而 SpringCloudAlibaba 就是这个新技术之一，有必要重点学习一下。 此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。 依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

【如何使用 Nacos：】
 而想要使用 Nacos，仅需在 微服务当中引入 client 相关依赖即可。
 

 
 
 

 
 

 
 

 
 
 

 
 

 
 
 

 （3）根据微服务名进行 路由（动态路由）
　　实际开发中，一个服务通常以集群的方式部署，若 uri 配置固定的地址进行跳转，肯定是不合适的。而 微服务注册在 注册中心中，网关 只需要通过 注册中心 提供的 微服务名 找到真实的 微服务，进行路由即可。
 
 

 修改的配置如下：
　　在 uri 中使用 lb://微服务名 进行配置即可。lb 表示负载均衡。
　　确保能根据 微服务名 进行路由，需配置 
 带有指定方法的请求才能匹配路由。
 
 带有指定路径的请求才能匹配路由。多路径使用逗号隔开。
 
 带有指定参数的请求才能匹配路由。
 
 
 
 

 
 
 

 

 
 

 
 
 

 
 
 StripPrefix 用于跳过 路径前缀（数值型）。
 

 其余 Filter 可自行参考文档。也可以自定义 Filter。后续有时间再来补充。
 

看一下专业的负载均衡软件是什么样的：PCL负载均衡软件

详细内容，大家可以自己去看。简单讲，专业负载均衡软件大概有以下特点：

1、它是基于IP隧道的，而不是象URL重定向方式那样。所以，它是独立于应用的

2、它支持不同平台，即应用可以是基于LINUX，WINDOWS或SOLARIS的，而不是象LVS只能在LINUX上

3、它是实时的，这点与DNS方式有极大的差别。

4、它能够根据系统、应用的情况来决定负载，这一点与硬件负载均衡设备有很大差别。

5、专业负载均衡软件，适用于企业级应用，无论从其可靠性，还是从其服务保障上，都不是象LVS那样的开源软件可比的。

总结一下，如果是象YAHOO那样的网站应用，可以考虑DNS方式，参见：
负载均衡软件实现方式之二 - 基于DNS

如果是特别简单的应用，可以考虑URL重定向方式，参见：负载均衡软件实现方式之一 - URL重定向方式

如果是不太重要的纯LINUX应用，可以考虑LVS，参见：
负载均衡软件实现方式之三 - LVS

如果是重要、流量大、应用简单、预算充足的情况，可以考虑硬件方式（比如用F5）（一定要做双机啊！），参见：软件与硬件负载均衡的比较

而如果是重要的企业应用，两台或几十台服务器，应用比较复杂，包括有可能跨平台，则应该考虑专业的负载均衡软件。参见：PCL负载均衡软件-应用集群的理想选择