微服务治理

微服务远程调用可能有以下问题：

• 注册中心宕机；

• 服务提供者B有节点宕机；

• 服务消费者A和注册中心之间的网络不通；

• 服务提供者B和注册中心之间的网络不通；

• 服务消费者A和服务提供者B之间的网络不通；

• 服务提供者B有些节点性能变慢；

• 服务提供者B短期内出现问题。

经常使用的服务治理手段：

节点管理

服务调用失败通常是由两类缘由引发的，一类是服务提供者自身出现问题，如服务器宕机、进程意外退出等；一类是网络问题，如服务提供者、注册中心、服务消费者这三者任意二者之间的网络出现问题。

不管是服务提供者自身出现问题仍是网络发生问题，都有两种节点管理手段。

1. 注册中心主动摘除机制

这种机制要求服务提供者定时的主动向注册中心汇报心跳，注册中心根据服务提供者节点最近一次汇报心跳的时间与上一次汇报心跳时间作比较，若是超出必定时间，就认为服务提供者出现问题，继而把节点从服务列表中摘除，并把最近的可用服务节点列表推送给服务消费者。

2. 服务消费者摘除机制

虽然注册中心主动摘除机制能够解决服务提供者节点异常的问题，但若是是由于注册中心与服务提供者之间的网络出现异常，最坏的状况是注册中心会把服务节点所有摘除，致使服务消费者没有可用的服务节点调用，但其实这时候服务提供者自己是正常的。因此，将存活探测机制用在服务消费者这一端更合理，若是服务消费者调用服务提供者节点失败，就将这个节点从内存中保存的可用服务提供者节点列表中移除。

负载均衡 

通常状况下，服务提供者节点不是惟一的，可能是以集群的方式存在，尤为是对于大规模的服务调用来讲，服务提供者节点数目可能有上百上千个。因为机器采购批次的不一样，不一样服务节点自己的配置也可能存在很大差别，新采购的机器CPU和内存配置可能要高一些，同等请求量状况下，性能要好于旧的机器。对于服务消费者而言，在从服务列表中选取可用节点时，若是能让配置较高的新机器多承担一些流量的话，就能充分利用新机器的性能。这就须要对负载均衡算法作一些调整。

经常使用的负载均衡算法主要包括如下几种。

1. 随机算法

顾名思义就是从可用的服务节点中随机选取一个节点。通常状况下，随机算法是均匀的，也就是说后端服务节点不管配置好坏，最终获得的调用量都差很少。

2. 轮询算法 

就是按照固定的权重，对可用服务节点进行轮询。若是全部服务节点的权重都是相同的，则每一个节点的调用量也是差很少的。但能够给某些硬件配置较好的节点的权重调大些，这样的话就会获得更大的调用量，从而充分发挥其性能优点，提升总体调用的平均性能。

3. 最少活跃调用算法

这种算法是在服务消费者这一端的内存里动态维护着同每个服务节点之间的链接数，当调用某个服务节点时，就给与这个服务节点之间的链接数加1，调用返回后，就给链接数减1。而后每次在选择服务节点时，根据内存里维护的链接数倒序排列，选择链接数最小的节点发起调用，也就是选择了调用量最小的服务节点，性能理论上也是最优的。

 4. 一致性Hash算法

指相同参数的请求老是发到同一服务节点。当某一个服务节点出现故障时，本来发往该节点的请求，基于虚拟节点机制，平摊到其余节点上，不会引发剧烈变更。

这几种算法的实现难度也是逐步提高的，因此选择哪一种节点选取的负载均衡算法要根据实际场景而定。若是后端服务节点的配置没有差别，同等调用量下性能也没有差别的话，选择随机或者轮询算法比较合适；若是后端服务节点存在比较明显的配置和性能差别，选择最少活跃调用算法比较合适。

服务路由

对于服务消费者而言，在内存中的可用服务节点列表中选择哪一个节点不只由负载均衡算法决定，还由路由规则肯定。

所谓的路由规则，就是经过必定的规则如条件表达式或者正则表达式来限定服务节点的选择范围。 

为何要制定路由规则呢？主要有两个缘由。 

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

好比，服务提供者作了功能变动，但但愿先只让部分人群使用，而后根据这部分人群的使用反馈，再来决定是否作全量发布。这个时候，就能够经过相似按尾号进行灰度的规则限定只有必定比例的人群才会访问新发布的服务节点。 

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

据我所知，大部分业务规模中等及以上的互联网公司，为了业务的高可用性，都会将本身的业务部署在不止一个IDC中。这个时候就存在一个问题，不一样IDC之间的访问因为要跨IDC，经过专线访问，尤为是IDC相距比较远时延迟就会比较大，好比北京和广州的专线延迟通常在30ms左右，这对于某些延时敏感性的业务是不可接受的，因此就要一次服务调用尽可能选择同一个IDC内部的节点，从而减小网络耗时开销，提升性能。这时通常能够经过IP段规则来控制访问，在选择服务节点时，优先选择同一IP段的节点。

那么路由规则该如何配置呢？根据个人实际项目经验，通常有两种配置方式。

1. 静态配置

就是在服务消费者本地存放服务调用的路由规则，在服务调用期间，路由规则不会发生改变，要想改变就须要修改服务消费者本地配置，上线后才能生效。

2. 动态配置

这种方式下，路由规则是存在注册中心的，服务消费者按期去请求注册中心来保持同步，要想改变服务消费者的路由配置，能够经过修改注册中心的配置，服务消费者在下一个同步周期以后，就会请求注册中心来更新配置，从而实现动态更新。

服务容错 

服务调用并不老是必定成功的，可能由于服务提供者节点自身宕机、进程异常退出或者服务消费者与提供者之间的网络出现故障等缘由。对于服务调用失败的状况，须要有手段自动恢复，来保证调用成功。

经常使用的手段主要有如下几种。

• FailOver：失败自动切换。就是服务消费者发现调用失败或者超时后，自动从可用的服务节点列表总选择下一个节点从新发起调用，也能够设置重试的次数。这种策略要求服务调用的操做必须是幂等的，也就是说不管调用多少次，只要是同一个调用，返回的结果都是相同的，通常适合服务调用是读请求的场景。

• FailBack：失败通知。就是服务消费者调用失败或者超时后，再也不重试，而是根据失败的详细信息，来决定后续的执行策略。好比对于非幂等的调用场景，若是调用失败后，不能简单地重试，而是应该查询服务端的状态，看调用究竟是否实际生效，若是已经生效了就不能再重试了；若是没有生效能够再发起一次调用。

• FailCache：失败缓存。就是服务消费者调用失败或者超时后，不当即发起重试，而是隔一段时间后再次尝试发起调用。好比后端服务可能一段时间内都有问题，若是当即发起重试，可能会加重问题，反而不利于后端服务的恢复。若是隔一段时间待后端节点恢复后，再次发起调用效果会更好。

• FailFast：快速失败。就是服务消费者调用一次失败后，再也不重试。实际在业务执行时，通常非核心业务的调用，会采用快速失败策略，调用失败后通常就记录下失败日志就返回了。

对服务容错不一样策略的描述中，能够看出它们的使用场景是不一样的，通常状况下对于幂等的调用，能够选择FailOver或者FailCache，非幂等的调用能够选择FailBack或者FailFast。