微服务架构下服务故障处理解决方案（下）

2 单IDC故障

为保证业务的高可用，部署在不止一个IDC。整个IDC脱网的事情时有发生，多半是因为不可抗力比如机房着火、光缆被挖断。

如果业务全部部署在这个IDC，那就完全不可访问，所以采用多IDC部署。

有的采用同城双活，也就是在一个城市的两个IDC内部署

有的采用异地多活，一般是在两个城市的两个IDC内部署

支付宝这种金融级别的应用采用“三地五中心”部署，这种部署成本显然高比两个IDC要高得多，但可用性的保障要更高

采用多IDC部署的最大好处就是当有一个IDC发生故障时，可以把原来访问故障IDC的流量切换到正常的IDC，来保证业务的正常访问。

流量切换方案

基于DNS解析的流量切换

通过把请求访问域名解析的VIP从一个IDC切换到另外一个IDC。

比如访问“www.baidu.com”，正常情况下北方用户会解析到联通机房的VIP，南方用户会解析到电信机房的VIP，如果联通机房发生故障的话，会把北方用户访问也解析到电信机房的VIP，只不过此时网络延迟可能会变长。

基于RPC分组的流量切换

对于一个服务，如果是部署在多个IDC的话，一般每个IDC就是一个分组。假如一个IDC出现故障，那么原先路由到这个分组的流量，就可以通过向配置中心下发命令，把原先路由到这个分组的流量全部切换到别的分组，这样的话就可以切换故障IDC的流量了。

3 单机故障

集群中的个别机器出现故障，这种情况往往对全局没有太大影响，但会导致调用到故障机器上的请求都失败，影响整个系统的成功率。

发生概率最高的一种故障，尤其对于业务量大的互联网应用来说，上万台机器的规模也是很常见的。这种情况下，发生单机故障的概率就很高了，这个时候只靠运维人肉处理显然不可行，所以就要求有某种手段来自动处理单机故障。

处理单机故障一个有效的办法就是自动重启。

你可以设置一个阈值，比如以某个接口的平均耗时为准，当监控单机上某个接口的平均耗时超过一定阈值时，就认为这台机器有问题，这个时候就需要把有问题的机器从线上集群中摘除掉，然后在重启服务后，重新加入到集群中。

注意，需要防止网络抖动造成的接口超时从而触发自动重启。一种方法是在收集单机接口耗时数据时，多采集几个点，比如每10s采集一个点，采集5个点，当5个点中有超过3个点的数据都超过设定的阈值范围，才认为是真正的单机问题，这时会触发自动重启策略。

为了防止某些特殊情况下，短时间内被重启的单机过多，造成整个服务池可用节点数太少，最好是设置一个可重启的单机数量占整个集群的最大比例，一般这个比例不要超过10%，因为正常情况下，不大可能有超过10%的单机都出现故障。

总结

故障时，往往多手段并用，比如单IDC故障，先要快速切换流量到正常IDC，但此时可能正常IDC不足以支撑两IDC流量，所以先要降级部分功能，保证正常的IDC顺利支撑切换过来的流量。

要尽量让故障处理自动化，可大大减少故障影响时间。