微服务可用性之隔离

摘要

​ 本文主要微服务场景下服务的可用性保障之隔离。隔离又分为几种情况，动静隔离、读写隔离、热点隔离、资源隔离等场景。

为什么要隔离

​ 本质上是对资源进行分割确保在出现故障的时候服务只是部分不可用，不至于系统陷入整体性瘫痪，记得左耳朵耗子大佬就曾在他的文章里面说过饿了吗在做多活之前就经常会有服务整体崩溃的情况，直到做了多活情况才有所好转，这是一个经典集群隔离场景。

隔离的类型

​ 动静隔离

​ 图片、视频等静态资源往往占用大量的带宽，我司曾经就因为一次配错静态资源的链接导致流量没有打到CDN上导致带宽打满的问题，所以一定要把静态资源放到CDN这种边缘计算结点上。

核心隔离

​ 将核心功能拆分出来单独部署成一个服务，避免因为非核心功能的故障导致系统整体不可用

热点隔离

​ 比如我们有一张数据表，有一个 text 或大varchar类型的字段，由于innodb读取数据是基于数据页进行读取，所以字段长度过大的话会导致数据页存储的数据过少从而导致innodb缓存命中率降低。我们可以考虑将这些大字段和不经常使用的单独拆分到一张扩展表里面从而提高数据库的读写性能。

读写隔离

​ 数据库：业务发展到一定程度，数据库往往都是一主一从或一主多从的架构模式，读从库写主库，当然也有特殊场景，由于数据库我们一般配置的都是异步复制模式（数据库可以配置异步、半同步、组复制模式），所以会有读延迟问题，在支付等数据一致性要求高的场景我们通常是采取强制读取主库的方案（即核心业务读取主库，非核心业务读从库）

​ 缓存：将缓存的读写放到不同的集群当中，写集群出现故障读集群依然可用，读集群出现故障还可以重试到其它集群。
​

进程隔离

​ 服务拆分：通过对单体服务进行垂直拆分，将业务部署到不同的资源上，避免服务间互相干扰，比如OOM导致的服务整体不可用

​ 容器化：容器化化部署从而更好的对服务的 CPU、内存等资源进行隔离

线程隔离

​ 通过对线程进行池化避免由于大量的慢操作导致全部线程不可用从而导致服务整体不可用，因此可以把线程池分为快慢池，确保满操作不会影响所有正常的请求。

集群隔离

​ 我们有些的服务可能都是部署在一个集群当中，流量等异常可能会由于一组服务实例影响了其他服务，因此我们可以将一些重要服务单独部署到一个集群避免被非核心服务影响。

机房隔离

​ 随着流量的增长对服务可用性要求会越来越高，通常会进行多机房部署。每个机房都有完整的服务分组，从性能考虑本机房的服务通常只调用本机房的服务分组。当机房出现故障时可通过负载均衡或者服务端自动重试到另一个机房。

总结

​ 在我们服务的开发过程中一定要多想想，资源、服务之间会不会产生相互影响。比如大促就要考虑做核心服务集群的隔离，视频转码服务就要考虑大视频和短视频的快慢隔离（大、小视频分别投递到不同队列进行处理）。总之要站在全局视角多想想，希望大家都能变的更强。

Reference

1. https://cloud.tencent.com/developer/article/1789752