微服务-服务治理

微服务-服务治理

在一个RPC调度中心中，可能会出现以下几种服务出错原因：

1.注册中心宕机

2.服务提供者有节点宕机

3.服务消费者和注册中心网络不通

4.服务提供者和注册中心网络不通

5.服务提供者和服务消费者网络不通

6.服务提供者性能或代码出现问题

 

服务节点管理

1. 注册中心主动摘除服务节点

这种方式需要服务提供者定时向注册中心发送一个心跳包，如果超过一定时间才收到下一个心跳包或者没有收到心跳包则注销该节点，将新的请求列表更新至服务消费者。

2. 服务消费者摘除机制

由于可能出现注册中心发生网络中断而服务提供者存活的情况，导致服务消费者无法获取相应的服务。因此，如果把激活机制放着在服务消费者中，服务消费者先从注册中心获取列表(在网络ok时)，在调用请求时，按照列表进行请求，如果请求失败或者超时了，则将该服务器从列表中移除。

 

负载均衡

一般情况下某个服务是有许多个节点的，那么如何合理的调用相应的节点，将每个节点的性能发挥到极致，这就需要一个合理的负载均衡算法。

1. 随机算法

从服务列表中随机选择一个节点，而随机算法符合均匀分布，因此，每个节点会分配到的请求数量是差不多的。

2. 轮询算法

按照固定的权重，对所有节点进行循环调用，权重大的在一轮请求中分配的多，权重小的在一轮请求中分配的少。

3. 最少活跃调用算法

在服务消费者中维护一个列表记录每个服务节点的正在连接数，每次选择连接数最少的节点进行调用，并更新列表。

4. 一致性hash算法

将hash值相同的请求总是发送到同一个节点上。如果某个结点出现了故障这，将请求分摊到其他节点上。

 

服务路由

路由规则，就是通过一定的规则或条件来限定服务节点的选择范围。

为什么要路由选择？

1. 业务存在灰度发布的需求

更新的服务只希望给一部分人进行使用，需要按照一定的规则对请求进行区分，将请求发送到不同的机器上。

2. 多机房就近访问的需求

每个服务可能会在多地有部署，那么如果需要跨地方进行调用，为了减少延时，则需要选择一个就近的数据中心调用相应的服务。

有哪些配置方式？

1. 静态配置

消费者本地存放固定的匹配规则，如果需要修改则需要重启服务。

2. 动态配置

匹配规则存放在注册中心中，如果规则发送了改变则由注册中心将规则分发给各个服务节点。

 

服务容错

当我们的服务提供者，服务消费者，注册中心发生了一些错误，如何处理这些错误？

注：什么是幂等？同一个接口反复调用，得到的结果是一致的。

1. FailOver

失败自动切换。如果服务消费者发现调用失败或者超时后，自动按照列表的下一个节点重试(适合接口幂等的情况)

2. FailBack

失败通知。调用失败或者超时后，不能简单的重试，要根据不同的情况使用不同的处理策略。

3. FailCache

失败缓存。调用失败或者超时后，不立即发起重试，缓存请求，过一段时间才重试。

4. FailFast

快速失败。调用失败或者超时后，不再重试。一般记录后，则直接返回。(非核心业务)