es技术规划

一、业务背景

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