1 服务治理是什么

1.1 定义

按Anne Thomas Manes的定义是：企业为了确保事情顺利完成而实施的过程，包括最佳实践、架构原则、治理规程、规律以及其他决定性的因素。服务治理指的是用来管理SOA的采用和实现的过程。

1.2 服务治理针对的问题

服务治理中一些典型的问题是：

1. 交付价值到利益相关者，这是投入与回报的问题
2. 对标准和规则的遵从（这是和审计相关的）
3. 变更管理：变更一个服务通常会引起不可预见的后果，因为服务的消费者对服务的提供者来说是不可知的。
4. 服务质量的保证：弹性添加新服务需要对这些服务给予额外的关注。

1.3 服务治理包括的行为

服务治理的一些关键活动包括：

1. 对开发新服务和升级现有服务的计划
2. 管理服务的生命周期：确保升级服务不会影响目前的服务消费者
3. 制定方针来限制服务行为：制定所有服务都要遵从的规则，确保服务的一致性
4. 监控服务的性能：由于服务组合，服务停机和性能低下的后果是严重的。通过监控服务的性能和可用性，当问题出现的时候能马上采取应对措施。
5. 管理由谁来调用服务、怎样调用服务

接下来看具体服务治理手段。

2 节点管理

2.1 服务调用失败原因

• 服务提供者故障
  e.g. 服务器宕机、进程意外退出
• 网络故障
  e.g. 服务提供者/注册中心/服务消费者中任意两者间网络故障

2.2 解决方案

2.2.1 注册中心主动摘除机制

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

2.2.2 服务消费者摘除机制

虽然上面方案可解决服务提供者节点故障，但若因注册中心与服务提供者间网络异常，最坏情况注册中心会把服务节点全部摘除，导致服务消费者没有可用服务节点调用，但服务提供者其实正常。
所以，将存活探测机制用在服务消费者这一端更合理，如果服务消费者调用服务提供者节点失败，就将该节点从内存中保存的可用服务提供者节点列表移除。

3 负载均衡

服务提供者节点一般以集群形式存在。对于服务消费者，在从服务列表中选取可用节点时，如果能让配置较高机器多承担一些流量，就能充分利用机器性能。

3.1 常用的负载均衡算法

3.1.1 随机

从可用的服务节点中随机选取一个节点。后端服务节点无论配置好坏，最终得到的调用量都差不多。

3.1.2 轮询

按固定权重，对可用服务节点进行轮询。如果所有服务节点的权重都是相同的，则每个节点的调用量也是差不多的。但可以给某些硬件配置较好的节点的权重调大些，这样的话就会得到更大的调用量，从而充分发挥其性能优势，提高整体调用的平均性能。

3.1.3 最少活跃调用

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

3.1.4 一致性Hash

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

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

4 服务路由

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

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

4.1 为什么要制定路由规则

4.1.1 灰度发布需求

比如，服务提供者做了功能变更，但希望先只让部分人群使用，然后根据这部分人群的使用反馈，再来决定是否做全量发布。这个时候，就可以通过类似按尾号进行灰度的规则限定只有一定比例的人群才会访问新发布的服务节点。

4.1.2 多机房就近访问需求

为了业务高可用，会将业务部署在不止一个IDC。不同IDC之间的访问由于要跨IDC，通过专线访问，尤其是IDC相距比较远时延迟就会比较大，就要一次服务调用尽量选择同一个IDC内部的节点，从而减少网络耗时开销，提高性能。这时一般可以通过IP段规则来控制访问，在选择服务节点时，优先选择同一IP段的节点。

4.2 路由规则配置

4.2.1 静态配置

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

4.2.2 动态配置

路由规则存在注册中心，服务消费者定期请求注册中心来保持同步，要想改变服务消费者的路由配置，可通过修改注册中心的配置，服务消费者在下一个同步周期之后，就会请求注册中心来更新配置，从而实现动态更新。

5 服务容错

服务调用并不总是一定成功的，前面我讲过，可能因为服务提供者节点自身宕机、进程异常退出或者服务消费者与提供者之间的网络出现故障等原因。对于服务调用失败的情况，需要有手段自动恢复，来保证调用成功。

5.1 常用方案

5.1.1 FailOver

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

5.1.2 FailBack

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

5.1.3 FailCache

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

5.1.4 FailFast

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

• 幂等的调用，可以选择FailOver或者FailCache
• 非幂等的调用可以选择FailBack或者FailFast

6 总结

上面我讲的服务治理的手段是最常用的手段，它们从不同角度来确保服务调用的成功率。节点管理是从服务节点健康状态角度来考虑，负载均衡和服务路由是从服务节点访问优先级角度来考虑，而服务容错是从调用的健康状态角度来考虑，可谓是殊途同归。

参考

• https://www.zhihu.com/question/56125281

文章来源: javaedge.blog.csdn.net，作者：JavaEdge.，版权归原作者所有，如需转载，请联系作者。

原文链接：javaedge.blog.csdn.net/article/details/109103507