
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
高可用性架构编程开发技术随着互联网的不断发展而得到广泛的应用,今天我们就通过案例分析来简单了解一下,高可用性架构实践常见问题分析。
1、架构高可用
交易这边进行在进行重构。将原有的核心交易从职责上划分为交易收单、交易保障和数据中心三个大块。
从高可用上,交易收单要保证实时交易现场的可用。除了交易现场必需的事情,其他什么都不做。除了发号器、加密器、监控报警等自身必需的中间件外,不使用其他与其他端通信的中间件。核心策略是去依赖。主要考虑点在MTBF。
交易保障的定位是交易现场完成后一切让交易数据正确的工作都是交易保障的工作。为了可以高效的及时修补数据、检测交易数据与各个端的一致性就需要适当用到一些中间件和交易收单进行通信。这就有依赖关系了。有依赖就要容灾。如果一个中间件出现问题了,就切换另外一个中间件。用的是同一个中间件,只是在不同的机房,这就是机房互备容灾。如果是不同的中间件,就是旁路容灾。都行不通怎么办?数据库轮询兜底,这属于降级容灾。对交易来说,交易保障为后续结算提供准确的数据,只要定时结算的时候数据是准确的,主要考虑点在MTTR。
交易除了完成交易现场和为结算提供准确数据外,一定还会有其他的产品上的需求。各种查询需求、统计需求、营销需求,商家消费成功语音提示等。各方都会需要各种形式的和实时性要求不同的数据。数据中心的定位是所有交易不干的活儿它都干。所以它才是对高可用需要考虑多的,对MTBF和MTTR都要考虑和权衡。但是在对高可用要求上交易收单和交易保障是基本职责,指标就是稳定、稳定和稳定。数据中心关乎的用户体验,是可以持续优化的,但是对高可用是有一定容忍度的:比如页面会加载慢,或者一次加载不了刷新就成功了。
2、强依赖高可用
比如数据库的密码,不仅是加密的,而且是在中央集群秘钥管理中心统一管理的。中央集群的就会有秘钥获取不到的风险。按照API,如果获取不到则会抛出指定异常。
这是强依赖,需要容灾。先,中央集群的,服务端有可能会升级。升级如果出现问题,在转换的时候没有抛出约定的异常怎么办?比如实际上获取不到抛出了空指针。空指针是非检查异常,不需要被显示处理。所以对这种中央集群的我们都全部捕获Exception父类,所有的异常。
出了异常了怎么办?一种是秘钥我们在客户端缓存一份,重启时服务端获取不到则加载本地的。如果安全性要求高,不允许堆栈外本地缓存呢?我们的策略是一损俱损。就是如果任何依赖加密器的都是启动时加载。如果加载失败则服务根本启动不起来。我们发版启动都是在低峰期,服务器有足够的余量。发版的并行执行机器数不超过3台。3台服务启动不起来对系统没有影响。实现了无损容灾的目的。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。