由于TOP上的服务业务形态不同，实现架构的差异加之网络环境的不确定性导致了TOP上的服务处理响应时间最小可以到十几毫秒，最大可以到几秒，当服务不稳定的时候还常常出现超时或者连接无法建立的错误。

由于Http请求是无状态的同步交互，因此当TOP上的服务响应变慢甚至不可用的时候，TOP的WebContainer连接资源将会成为瓶颈，表现出来的结果就是TOP本身处理能力降低，其他服务受到某些问题服务的影响，也变得不稳定。

解决思路：

服务分流

分流是一种静态或者半静态的解决方法，通过配置将不同的服务定向到不同的服务器处理。

分流可以通过三种方式实现：硬件的负载均衡、DNS轮询、软负载。硬件负载均衡的优势就是简单，高效，劣势就是价格比较昂贵，同时对于7层协议解析分流支持的一般。DNS轮询的优势就是简单，效率尚可（遇到DNS被攻击也会成为瓶颈），劣势就是需要多个外网IP，代价比较大。软负载指的是通过软件方式实现负载均衡，优势是价格低廉，充分利用了服务器本身一些特性（LVS利用Linux系统对硬件方面的一些支持操作），效率比较高（4层），使用方便灵活（7层支持的较好，HA-Proxy），劣势是会带来部分性能损失，存在由于软负载架构带来的一些不稳定性。

TOP分流服务需要对Http层协议作解析，因此选择了软负载实现分流，当前选择了HA-Proxy，对于软负载的详细说明和介绍参看另一篇文章《软负载均衡学习点滴》。

TOP集群被分成了两组，一组叫做TOP快速响应集群，还有一组叫做TOP分流服务集群。分成两部分的作用就是考虑到软负载对于性能以及挂接节点的限制，快速响应集群和原来的TOP结构一样，通过F5作负载均衡，直接响应服务请求，而TOP服务分流集群作用就是当服务进入该集群时，通过配置将不同业务类型的服务分发给不同的服务器，起到服务分流的效果。当然可以通过软负载前端机自动（根据规则监控服务状况做出判断）或者手动的修改分流策略，直接生效。

服务分流还存在着一些问题：

1.粒度比较粗，运行期比较僵化。通常配置粒度为ISP级别，同时在出现问题时无法及时防止某一个服务对于TOP及其他API的影响。

2.分流灵活，但也有所限制。只能针对HttpHeader和Url做业务分析，如果是Post的请求，那么分流业务参数如果处于body中，将无法实现分流。

3.效率有所牺牲，负载前端对于后端挂接节点数量的限制导致需要较多的前端软负载，使得资源浪费。

详细的测试报告及说明参看最后的附录。

服务隔离

服务隔离是在运行期，通过监控服务状态和质量，按照一定的算法和策略隔离问题服务，减小问题服务对TOP或者其他服务的影响。

服务隔离的实现无需外部应用或者服务器的支持，只需要基于现有TOPRouter作功能增强。可以部分解决服务分流的1，3问题。