Cool带你学治理体系-4

兜底/容错

兜底是可能我们经常谈论的是一种降级的方案，方案是用来实施，但是这里兜底可能更多是一种思想，更多的是一种预案，每个操作都可以犯错，我们也可以接受犯错，但是每个犯错我们都必须有一个兜底的预案，这个兜底的预案其实就是我们的容错或者说最大程度避免更大伤害的措施，实际上也是一个不断降级的过程。举个例子：

例如我们首页请求的用户个性化推荐商品的接口，发现推荐系统出错，我们不应该去扩大（直接把异常抛给用户）或保持调用接口的错误，而是应该兼容调用接口的错误，做到更加柔性化，这时候可以选择获取之前没有失败接口的缓存数据，如果没有则可以获取通用商品不用个性化推荐，如果也没有可以读取一些静态文字进行展示。

由于我们架构进行了分层，分成APP，网关，业务逻辑层，数据访问层等等，在组织结构也进行了划分，与之对应的是前端组，后端业务逻辑组，甚至有中台组等等。既然有代码和人员架构的划分层级，那么每一层都必须有这样的思想：包容下一层的错误，为上一层提供尽可能无措的服务。举个例子：

商品的美元售价假设要用商品人民币售价/汇率，这个时候错误发生在低层的数据层，上一层如果直接进行除，肯定就抛出 java.lang.ArithmeticException: / by zero，本着我们对任何一层调用服务都不可信的原则，应该对其进行容错处理，不能让异常扩散，更要保证我们这一层对上一次尽可能的作出最大努力确定的服务。

负载均衡

相信负载均衡这个话题基本已经深入每个做微服务开发或设计者的人心，负载均衡的实现有硬件和软件，硬件有F5，A10等机器，软件有LVS，nginx，HAProxy等等，负载均衡的算法有 random ， RoundRobin ， ConsistentHash等等。

Nginx负载均衡故障转移

转移流程

nginx 根据给定好的负载均衡算法进行调度，当请求到tomcat1，nginx发现tomcat1出现连接错误（节点失效），nginx会根据一定的机制将tomcat1从调用的负载列表中清除，在下一次请求，nginx不会分配请求到有问题的tomcat1上面，会将请求转移到其他的tomcat之上。

节点失效

nginx默认判断节点失效是以connect refuse和timeout为标准，在对某个节点进行fails累加，当fails大于max_fails时，该节点失效。

节点恢复

当某个节点失败的次数大于max_fails时，但不超过fail_timeout,nginx将不在对该节点进行探测，直到超过失效时间或者所有的节点都失效，nginx会对节点进行重新探测。