关于BI:新功能坚如磐10Smartbi如何实现724小时不宕机

47次阅读

共计 1040 个字符,预计需要花费 3 分钟才能阅读完成。

随着企业业务规模的扩充,零碎服务的稳定性受到很大的挑战。为了应答刻薄的生产工作负载,在 V10 新版本中,咱们产品反对分布式 session 共享、负载平衡优化、扩大包热加载、产品补丁包疾速修复等性能,实现 7 *24 小时不宕机,进步了产品零碎的稳定性,无效晋升了用户的体验。

1、分布式 session 共享,实现无状态化

V10 版本通过分布式 Session 共享实现产品无状态化:即便服务器在宕机、断电、切换等状况下,都毋庸用户从新登录,保障业务操作不中断、数据 / 模板不失落,无效晋升用户体验。

Smartbi 产品通过将会话信息对立存储在分布式缓存数据库 Redis 中,实现多个应用服务器共享会话信息,保障服务器重启或切换后,依然能够失常操作,不会跳转至登录页面,也不会呈现 HTTP 400 和 HTTP 500 谬误。常见部署模式如图所示:

2、负载平衡调整优化,反对衰弱汇报

当零碎面临少量用户拜访、负载过高问题的时候,零碎性能以及稳定性问题就会凸显进去。通常会思考减少多台机器进行横向扩大以此进步整个零碎的解决能力。此时,负载平衡是实现零碎高可用性和稳定性的一个要害组件。

新版本中咱们对负载平衡服务器 Smartbi proxy 进行了优化:用前后端拆散的框架,保障申请被散发到衰弱的服务器上。这种优化在大流量多元化场景下对保障用户业务的继续稳固运行起到至关重要的作用。

衰弱汇报

各服务器节点定时向 smartbi proxy 汇报本身的衰弱状态信息,如果节点属于“断开”状态的话,则将此节点长期从待选取列表中剔除,以进步零碎的可用性。

能者多劳

依据各服务器节点内存、CPU 等差异性判断各节点可用性、服务能力,从而影响申请散发的倾向性,实现“能者多劳”保障申请被散发到衰弱的服务器上,晋升零碎的稳定性。

主动正告

若节点的资源使用率达到了设置的阈值,那么会触发告警,最初以发送邮件模式实现对异样节点进行前端揭示。

3、反对扩大包热加载,无需重启

咱们晓得扩大包通常用于实现客户现场要求的特定需要,如减少功能模块、删除性能点等等。在产品 V10 版本中咱们还实现了反对扩大包热加载,即运维人员调试或更换扩大包时能间接上传,无需重启服务器,还能通过可视化界面迅速理解扩大包的加载状态,还能在线启用、禁用和从新加载,实现客户零碎稳定性运行。

4、反对补丁包手动上传,实现疾速修复

V10 版本反对以产品补丁包的形式来实现疾速修复。通过可视化界面手动上传补丁包,不须要重新部署 war 包,实现问题的疾速修复,缩短了更新版本的周期,进步了运维人员工作效率!

正文完
 0