随着当今云原生的发展,无状态微服务系统通过其良好的设计理念和相关技术栈的成熟,成为越来越多企业建设系统的首选,但不可避免的是随着微服务拆分系统增多,稳定性慢慢会被重视,如何保证服务7*24小时不间断服务,节点或服务级异常不会影响到整个交易链路,会成为系统开发人员和架构师需要考虑的逃避不掉的问题。
我司基于Spring Cloud微服务技术的平台也上线6、7年,支持上千个微服务系统,积累了一些经验,在隔离方面总结如下:
-
服务级隔离,适用于某一类较大的微服务,需要使用独立的API网关;
-
端口级隔离,适用于一些不稳定的微服务,在API网关上使用独立端口,防止影响其他同端口微服务;
-
线程池级隔离,为每个微服务在API网关配置单独的线程池,使每个微服务进入API网关后流量相互不受影响,当流量徒增时,通过一定的线程池、队列和丢弃策略,保护API网关和后端微服务;
-
节点隔离,基于探活技术的故障节点隔离,自动摘除故障节点,防止某些节点假死,影响交易;
-
资源隔离,为系统提供隔离在独立的运行环境,减少资源抢占相互影响。
服务级隔离
服务级隔离更多是前期规划期间进行,一般用于API网关的使用。
已上图为例,一般查询商品的流量要比购买商品流量大得多,如果查询和购买两个流量都过同一组API网关,购买商品势必会收到影响。常见的做法API网关按照服务或一定的规则进行逻辑管理,对大流量的系统可以设置专门的API网关进行支持。结合API网关压测情况+容器云自动扩散容能力,能有效支撑突发流量,同时保障其他流量不受影响。
端口级隔离
大多数情况下会将入口流量配置在同一个端口下,也没什么问题,但在出现响应时间较长、请求量较大、连接长时间不释放场景时,就有可能阻塞端口,造成其他服务也不可用。比如上图同步通讯录一般响应时间较长,也有可能集中请求较多,就很容易阻塞,影响查询通讯录请求。我们可以在设计开发时使用单独的端口,避免对其他服务造成影响。
线程池隔离
当流量进入端口后,可以为每个微服务分配独立线程池,用于将不同的任务或服务放置在独立的线程池中,以实现资源的隔离和管理。线程池隔离可以帮助提高系统的稳定性和性能,并防止某个任务或服务的问题影响整个系统。
-
通过容量控制设置每个线程池的最大线程数和队列容量,以控制并发请求的数量。通过限制线程池的容量,可以防止系统资源过度消耗,避免线程堆积和响应延迟;
-
通过独立的线程池隔离,可以防止一个线程池中的任务出现异常或错误,扩散到其他线程池和服务中,这样可以确保系统的可用性和稳定性,避免单点故障对整个系统的影响。
-
对每个线程池进行监控和性能调优,以确保其正常运行和高效利用资源。监控线程池的活动情况、任务执行时间和线程利用率等指标,及时发现潜在问题并采取相应的优化措施。
节点隔离
故障节点隔离是一种针对微服务架构中故障节点进行隔离和处理的技术。在大规模微服务系统中,节点故障是难以避免的,可能由于硬件故障、网络问题、软件错误或其他原因导致某个节点无法正常运行。为了保证整个系统的稳定性和可靠性,故障节点隔离技术可以采取以下措施:
-
快速故障检测:通过实时监控和故障检测机制,能够及时感知到节点的故障状态。这可以基于心跳机制、健康检查或其他监测手段来实现。一旦检测到节点故障,系统可以立即采取相应的措施进行隔离和处理。
-
自动隔离和切换:当故障节点被检测到时,系统可以自动将故障节点隔离,以避免其故障对整个系统的影响。这可能涉及到将故障节点从负载均衡器的轮询列表中移除,停止将请求转发给故障节点,并将流量转移到其他健康节点上。同时,系统可以自动触发切换逻辑,将请求路由到备用节点或冗余系统上,确保服务的连续性。
-
异常容错与恢复:当故障节点被隔离时,系统应该具备异常容错能力,能够处理由于节点隔离而引起的异常情况。这可能包括实现适当的错误处理和回退机制,例如返回默认值、发送错误通知或执行备用逻辑。同时,一旦故障节点恢复正常,系统应该能够自动将其重新纳入服务,并进行相应的资源分配和负载均衡。
资源隔离
使用容器化技术(如Docker)或虚拟化技术(如VMware)将不同的服务或组件隔离在独立的运行环境中,确保它们之间的资源不会互相干扰。通过为每个服务分配适当的资源限制,如CPU、内存和网络带宽,可以避免资源的竞争和冲突。
总结
在实战中,在设计阶段就需要根据预估的QPS量级,合理进行使用隔离技术。一般独立大系统建议使用独立网关,大系统中核心微服务使用独立端口,通过压力测试,合理配置线程池等参数大小,出现问题是隔离故障节点实现及时止损。
这些功能或技巧可以提升平台的稳定系,但在使用时会增加平台日常运维的复杂度,需要对多API网关进行分组管理,有时候操作不当很容易出现线上事故。解决方式是尽量提升管理平台的交互度和自动化程度,减少手工操作。在线上实践中可以逐步形成标准,统一规范,逐步赋能给支持的业务系统,提升其连续性。