一, 业务背景
es 服务当前没有专门的部门负责维护和开发, 交由各端自行负责维护, 随着公司业务查询和统计需求非常多, 会面临居多方面问题和挑战:
无人 (专业 RD 或部门) 负责
无专业的人进行维护, 遇到问题几乎无人处理
缺乏性能评估
查询和统计相关语句执行无指标评价体系
运维效率较低
无操作友好且高效的 web 管理平台
质量评估缺失
监控报警体系不完善
缺乏运维体系建设
无集群性能评估和压测报告
无容灾容错措施
无迁移扩容方案
无最佳实践(容量, 集群规模, jvm 配置等等)
无优化方案
二, 业务目标
提效率降成本, Web 自动化运维平台建设
优化性能, 服务治理体系建设(SOP, 调优)
集群性能评估, 提供性能, 压测方案
保障质量, 监控报警, 数据报表完善和 SLA
节约资源, 进行集群规划和梳理, 逐步收敛集群规模. 1. 下线富余机器 2. 相应机器降配置
新增安全性, 新增鉴权模块, 实现访问隔离和安全验证
索引同步保证, 保证数据一致性, 正确性, 实时性
三, 技术规划
es 成果落地分期进行, 每期以季度为单位, 每季度都要规划具体开发和落地任务以及完成时间
一期计划:
监控报警完善, 报警考虑与第三方组件集成, 例如运维体系, 钉钉集成等
优化性能, 集群性能调优, 部署架构调整, 集群分类.
建立各种 SOP(安装, 机器配置, jvm 配置, 重启, 迁移, 扩容等)
收敛集群规模和数量, 下线富余机器. 例如有的节点 128G 根本用不了, 纯属浪费资源
测试方案, 性能测试, 功能测试, 可靠性测试(各种容灾容错场景),es 版本升级与兼容性测试
二期计划:
建平台, 推进 Web 自动化运维平台建设
多集群管理(浏览, 增减)
节点管理(浏览, 增减)
业务接入评估公式和规范
业务申请入口
类 SQL 支持 / 统计查询性能, 集成官方 SQL 插件
三期计划:
架构升级优化, 增加代理层
通过代理层检索服务, 实现限流, 超时, 重试机制
大集群业务访问隔离
五, 开发任务
人力需求规划: 需求 2 人一期计划 1 人负责测试方案落地, 容错容灾机制, 保障集群稳定性 1 人负责各种 sop 和演练, 参与部分优化工作
引用博客地址: https://www.cnblogs.com/lizherui/p/12769878.html
来源: https://www.cnblogs.com/lizherui/p/12769878.html