云采用框架-停写不停读切换方案
停写不停读切换方案
停写不停读,主要指切换期间,为了追求较好的用户体验,保持一部分读的服务不停服,保持在线可使用状态;为了保持数据一致性,写的服务仍然采用停服方式进行切换。从业务对外体验上,多数用户感知不到停服的影响,比如某购物平台,用户仍然可以浏览商品,但是不能下单,下单时可友好的提示:系统正在升级中,预计凌晨4点恢复,请您稍后重试下单等。
- 四种停写不停读切换方案对比
停写不停读切换有4种方案可以选择:
方案 |
操作方式 |
适用场景 |
操作复杂程度 |
改造工作量 |
---|---|---|---|---|
网关拦截 |
接入层,服务网关拦截写请求,放通读请求 |
入口统一,有统一网关,网关具有拦截能力,并对拦截的接口能配置友好的提示。 |
简单 |
无需改造 |
停止写服务,读服务不停 |
写服务或对应接口shutdown,读服务或对应接口保持alive |
应用层服务已做读写分离场景,每个服务只进行单独的读操作或写操作,没有同时进行读写的服务 |
简单 |
无需改造 |
应用层先做读写分离改造,然后停止写服务,读不停 |
应用层修改代码,拆分读写服务 |
应用层服务没有读写分离的场景 |
复杂 |
大 |
中间件层/数据层直接回收写权限 |
中间件层/数据层设置业务账号只读,收回写权限 |
直接回收写权限,业务系统会报错,需要做相关轻微改造处理这些报错 |
简单 |
轻微改造 |
- 网关拦截
服务网关(Gatekeeper、Zuul、Kong等),拦截写请求,放通读请求;例如Gatekeeper网关可以拦截POST请求,只放通GET请求。这可以通过在Gatekeeper网关上配置规则来实现。可以设置一个规则,只允许GET请求通过,拒绝POST请求。图1 网关拦截方案
- 写服务关停
应用层服务已做读写分离的场景,直接关停写服务或对应接口下线shutdown,读服务或对应接口保持在线,从而达到业务只读不写的效果。
图2 写服务关停方案
- 应用改造
应用代码进行读写分离改造,改造后再按照8.4.3.3写服务关停方案实施,实现只读不写的效果。
图3 应用改造方案
- 中间件层/数据层配置只读
中间件层和数据层收回业务账号写权限,不允许服务写中间件层/数据层的操作。
图4 中间件和数据只读方案