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

由于Http请求是无状态的同步交互，因此当TOP上的服务响应变慢甚至不可用的时候，TOP 的Web Container连接资源将会成为瓶颈，表现出来的结果就是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．  分流灵活，但也有所限制。只能针对Http Header和Url做业务分析，如果是Post的请求，那么分流业务参数如果处于body中，将无法实现分流。

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

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

服务隔离

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

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

图2  服务隔离部署图

服务隔离需要引入虚拟服务组的概念，虚拟服务组指的是某一些服务器被配置成为只对某部分服务（关键服务）保持持续支持，当其他服务（非关键服务）出现超时或者不可用时，可以暂时停止对那些服务（非关键服务）的支持，这样就反向的保证了被支持的服务（关键服务）和其他服务（非关键服务）的隔离。

收集服务的超时和不可用主要通过两个途径：1.普通服务产生的超时及不可用反馈。2.虚拟服务组针对负责的服务做后台异步心跳检查。最后将统计的结果记录在集中式缓存中，每次服务请求时，虚拟服务组检查是否需要隔离问题服务，直接返回错误。

服务器可以配置成为虚拟服务组或者非虚拟服务组（default），非虚拟服务组将不检查心跳及服务是否需要隔离，只是提供服务请求中的不可用和超时现象。在集群中当前配置了部分作为default，而服务分流集群中的所有服务器将都是非虚拟服务组配置。

假设trade服务中某一个API出现了严重超时，此时在缓存中也标示出此API出现问题，那么TOP虚拟服务组（product）和（user）将不再对此服务提供支持，直接返回服务不可用的错误码，保证这两类服务的有效处理。其他服务器继续支持服务。

服务虚拟组可以支持运行期修改动态配置。

服务隔离存在的问题：

1．  对缓存操作增多，对性能有部分影响。对缓存依赖大，容易在缓存出现问题时导致系统不稳定。

2．  发布比较复杂，因为配置的多样性，需要支持多个发布脚本。

3．  对服务不可用及服务超时的隔离算法和策略需要满足各种可能的需求，这个会增加复杂度。

总体上来说服务的分流简单，服务的隔离复杂，但是两者可以相互结合使用，取长补短。