微服务架构在某些应用场景,特别是医院繁琐的业务中可以将业务剥离,形成微服务模式,数据存储的分散性是微服务的一个特点,但优于分散存储导致的数据读取,交互,也是其应用过程中的一个难点,根据其数据存取得特点,此类应用该如何考虑容灾?
您描述的场景比较难以判断。
我从常规的容灾思路来解释一下。
微服务部署在VM上,参照传统应用部署一套,做主备或双活即可。数据备份依托专业备份软件实现。
微服务部署在容器上,借助容器平台自身的高可用性,实现多集群多实例部署。例如,将挂号系统部署在集群A内,在集群B中也部署1套,通过负责实现应用双活或主备。这样就可以在单数据中心内应用高可用。数据库建议放到K8s集群外面,通过传统方式实现数据库的容灾。
我们最近在做核心系统的灾备方案的时候,也面临着一套微服务的架构如何建设灾备。我们目前的方案是通过集群的方式共享注册中心、配置中心以及网关等基础内容,确保主节点和备份节点无论哪一个节点挂掉,后端的服务都可以正常使用。
我觉得应用级别的灾备,特别是微服务之后的除了考虑服务本身外,还要重点考虑微服务的基础服务,主要有注册中心、配置中心、网关、链路监控等信息。
微服务的基本容灾模式:
1.主动超时
调用依赖的时候设置好超时时间,出问题的时候主动超时,最简单有效的处理方式。
2.限流
限制最大并发数,限制访问数量。好比长假期间高速公里的限流。
3.熔断
错误达到阈值时,类似保险丝熔断。如果后端系统出现大规模延时,需要暂时的熔断保护后端系统。一般熔断不是所有都拒绝,可以通过少量请求判断是否恢复正常,如果恢复则结束熔断动作。
4.隔离
隔离不同的依赖调用,凡是系统资源都是有限制的,如果不隔离很容易因为一个服务的延迟,把所有资源都给耗尽。如果服务都是隔开的,那出问题不会印象其他服务。
5.降级
服务降级,比如某个高峰时期,服务器处理不了全部的请求,那优先处理VIP用户,对普通用户可以导入到一个错误提示页面进行处理。
收起