认识达内从这里开始

随着互联网的不断发展，越来越多的人都在学习微服务架构开发等互联网技术，而本文我们就通过案例分析来简单了解一下，微服务服务治理方法分享。

为什么要服务治理呢?

因为在微服务api运行过程中，会出现一系列的问题，这些问题如下：

调用方和被调用方，被调用方因为网络暂时不可用了，怎么办?

如果一个微服务突然访问量增大，影响了与它调用相关的微服务运行状态，比如导致其他服务调用变慢，这时怎么办?

如果访问量继续增大，导致微服务A不可用了，与之调用关联的B、C服务也慢慢变得不可用了，怎么办?

如果某个服务的服务器宕机、延迟或某一服务不可用了，怎么办?

......

等等的一些微服务运行过程中会出现的问题。为了处理这些问题，就出现了服务治理的一些方法。

服务超时/重试

服务超时：

在一个规定时间内，对方没有应答，那么就可以认为请求超时。认定为超时，就可以进一步处理。比如说重试，或者直接记录错误。

服务重试：

由于网络不稳定，导致调用服务失败，或者调用超时，这时候就可以通过重试，重新调用请求，增加调用成功率。

一般情况下，服务超时和服务重试，是结合在一起使用的。

服务限流

一种：如果某一API流量变大，影响了其他服务，可以进行限流。

这个可以解决访问量变大的问题。

二种：对于某一特定请求服务有限定次数请求，比如100次/s。

服务熔断

熔断就是关掉某一个服务，使其他服务不受之影响。

如果遇到访问量很大，或系统异常或Load过高出现暂时不可用，微服务api请求的就会失败，如果失败率超过了规定的阙值，那么就可以进行熔断处理，保护其他的微服务api。

这还有一个形象的叫法：电路熔断器。日常的电路开关，就是用的这种工作模式，电流过大，就会跳闸，然后可以手工恢复。

服务降级

当访问量变大，超过了设置的阙值时，就可以将一些非重要、非核心的业务进行降级处理，暂停其对外提供服务。保护核心API访问不受影响。

依赖隔离

为什么要隔离?也是为了某一服务不可用，不影响其他服务。

比如服务A调用服务B，B又调用了服务C，如果这时候C访问量变大或机器宕机了，B调用C服务访问不了或者hang住了，那么B服务器资源消耗会上涨，如果继续上涨到不可用，那么这个条API服务可能就不能服务，为了避免这种情况出现，可以对C服务进行隔离。从而避免级联故障出现。

这种隔离方式还有一个专门的模式：舱壁隔离(BulkheadIsolation)。

在造船行业，往往使用此种模式对船舱进行隔离建造，利用舱壁将不同的船舱隔离起来，这样如果一个船舱破了进水，只损失一个船舱，其它船舱可以不受影响，而借鉴造船行业的经验，这种模式也在软件行业得到使用。

舱壁模式(Bulkhead)：

隔离了每个工作负载或服务的关键资源，如连接池、内存和CPU。使用舱壁避免了单个工作负载(或服务)消耗掉所有资源，从而导致其他服务出现故障的场景。这种模式主要是通过防止由一个服务引起的级联故障来增加系统的弹性。

fallback

这个fallback怎么译文，应急模式，备用模式，回退模式，都不是很形象。

在上面的服务超时、重试、熔断或者限流发生时，为了及时的恢复服务或不影响用户体验，可以提供回退的机制，常见的回退策略有：

自定义处理：

在这种情景下，可以使用默认数据，本地缓存数据来临时支撑，或者使用备份服务获取数据，适用于业务的关键流程与严重影响用户体验的场景，如商家/产品信息等核心服务

fail-silent

直接返回空值或缺省值，适用于可降级功能的场景，如产品推荐之类的功能，数据为空也不太影响用户体验

fail-fast快速失败

直接抛出异常，适用于数据非强依赖的场景，如非核心服务超时的处理

failsafe

失败安全，出现异常时，直接忽略，通常用于吸入日志操作的场景

failback

失败自动恢复，后台记录失败请求数据，定时重发请求。通常用于消息通知等场景

failover

失败自动切换，当出现失败，重试其他服务器

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。