阿里云Elasticsearch -- 从0到1的云产品演进之路-CSDN博客

背景

Elasticsearch作为开源界最流行的搜索与分析引擎，在日志、安全、监控等领域也都有着非常广泛的应用，而开放搜索团队在支持云上用户的过程中，也了解到有大量自建Elasticsearch服务的用户对于运维效率、性能、稳定性有着非常迫切的需求，因此我们在2017年双十一前在公有云上正式推出了阿里云Elasticsearch。

阿里云Elasticsearch的目标是解决用户的数据分析和搜索需求，产品形态上和Opensearch的SAAS产品化思路不同，我们希望给予用户最大的灵活性，能够保有原生ELK的体验，在云上提供完全的物理隔离的实例型搜索服务。加入Elasticsearch这款产品以后，我们也可以形成产品梯队，Opensearch上我们可以基于搜索事业部中台技术提供高性能、高可靠、免运维、有灵活的算法定制能力的搜索服务；ES上我们提供标准化的Elastic Stack全栈解决方案，提供低成本、灵活的分析和搜索服务。ES的PAAS产品化思路一个好处是可以减小用户迁移成本，保证用户可以无缝平滑上云，另一个是相对于多租户型实例，ES的独享型实例可以在云上基于VPC提供更安全隔离机制。

从结果上看，阿里云Elasticsearch上线一年来发展迅速，已经成为营收增长最快的大数据产品之一，我们不但支持了公有云用户相关需求，也通过诺曼底系统支持了集团内的多个BU的搜索需求，另外专有云上，ES也是3.5版本第一个All in ECS落地的产品。目前公有云产品上，Elasticsearch集群数1400+、节点数6000+、文档数据量也达到PB级。

产品演进

前面介绍了阿里云Elasticsearch产品背景和现状，作为搜索事业部第一个真正上云的产品，下面主要分享下技术上的尝试和整体架构上的演进。架构思路上，我们希望用一套架构支持公有云和专有云产品需求，另外也希望能够同时享受到搜索事业部和阿里云IAAS快速发展的红利，因此在产品立项之初，我们就坚定的选择ECS和HIPPO作为ES的基础设施。产品上，我们基于VPC和ECS做到物理隔离，提供最高的安全机制，并且优先解决了ES的自动化运维问题，开发了包括Essen和Shuttle在内的自动化运维系统；在支持用户过程中，逐步沉淀了ES上的使用的经验，基于这些经验并且结合数据分析，我们开始尝试设计和开发了智能化运维系统EYou；从生态上，除了支持Logstash和Beat的数据采集和数据处理机制外，逐步开始和搜索离线团队一起，基于离线组件平台开始打造一站式ES实时计算产品Elastichub。不多说了，下面直接上图：

从OXS到All in ECS

首先为什么要基于ECS呢，All in ECS绝对不单单是一个战略上的口号和趋势：

安全性

基于VPC内的ECS，在公有云上我们可以实现安全的物理隔离机制，而安全性是公有云产品的最基本要求。在OXS区内虽然我们也可以通过ak和secret实现用户的acl，但相对于物理隔离安全性还是无法比拟的。按照以往经验，我们的第一版架构方案就是基于OXS实现的，安全架构审核时安全同学也及时指出相关问题，让我们对数据安全有了更深的理解。

访问VPC资源的先决条件

作为搜索服务，数据上游的生态是最重要的一环。在公有云环境中，阿里云几乎所有的云产品，包括关系型数据库、NoSQL和大数据产品都在用户VPC内。在VPC内，访问用户数据是最安全和最便利的途径。网络同学也提供包括反向VPC、ENI在内的多种访问用户数据的方式。

弹性伸缩和快速部署

作为一个搜索老兵，习惯了集团内每年的资源规划，但在云上，每个财年前产品规划时哪个区域物理资源需求多少，接入时间都是未知的。而如果没有ECS，ES绝对无法做到从国内区域到国际化，从公有云到金融云10+区域的快速部署，也无法做到快速响应用户需求，及时扩容。

运维自动化到智能化

作为一个实例型的云产品，我们首先解决是运维效率的问题。从以往的经验来看，随着搜索业务的发展，包括数据量、场景增长，一个大的多租户集群很难满足业务性能和稳定性的需求；从目前产品现状分析，阿里云ES上每个用户平均都有两个以上的ES集群，因此，我们上半年的工作大部分都集中在完善自动化运维体系上，在尽量不影响灵活性的前提下，提升用户运维多ES集群的效率。我们目前已经基于Elasticsearch的搜索服务框架和分布式运维平台实现了包括弹性扩容、集群配置管理、插件管理、日志可视化等一些列功能。
在支持用户过程中，我们经常需要回答用户异常问题调查、扩容建议的问题，这些问题无论对开发同学还是云产品售后同学都是很大的工作量，而这些事情无论对于新手还是资深业务开发同学都有很大的门槛。结合了搜索中台发展的经验，我们和tisplus团队同学一起合作开发了智能化运维系统EYou，并且在售后支持上落地，取得了很好的效果。
AIOps是一个很热的词，很多人赋予多重含义。而对EYou来说，我们希望他能有以下三方面的能力：首先，从功能上讲我们希望它可以沉淀我们线上运维上千集群的经验，也能基于数据，比如用户profile、配置、监控信息，来做到集群问题的自动化诊断；其次，从效率上可以代替人工，做到集群的日常巡检和问题的智能预测集群；最后，我们希望它可以解决云上用户的痛点问题，比如成本、slow query等等。详见阿里云Elasticsearch智能化运维实践

从离线平台化到产品化

作为搜索系统，离线计算作为不可或缺的重要组成部分一直是系统演进的重点。从内网需求到弹外上云产品的离线需求，搜索场景下离线计算也一直是系统迭代的瓶颈。因此我们希望能够有一套搜索场景下相对通用独立的离线产品，能够作为Opensearch、Elasticsearch甚至是推荐产品的通用产品化组件来支持相应的离线数据处理需求。从上半年开始，开放搜索团队和离线组件平台相关同学一起紧密合作，以Elasticsearch的需求为样板，开发了新的搜索场景下离线计算产品ElasticHub。在ElasticHub中我们引入离线组件平台作为底层架构，基于bingo和dolphin实现了通用的云产品接入层，希望后续ElasticHub也能够很快支持Opensearch的离线计算需求。
在ElasticHub中，我们除了解决了数据源接入、ETL和全增量模型统一的需求外，索引全量是Elasticsearch的特有需求。和Ha3不同，Elasticsearch基于在线服务的全量索引构建易用性非常好，但在大规模数据量场景下性能和稳定性都是很大的痛点问题，因此我们希望能有一个类似BuildService的系统来解决离线全量的问题，做到在离线分离，这就是ElasticBuild。在执行引擎上，ElasticBuild非常灵活，除了支持Blink，还支持ODPS、Local等等，目前在产品上主要是和基于Blink的离线组件平台结合，在ElasticHub上提供一站式的产品体验。性能上，我们在做了一系列索引层的优化后也有相当大的提高。详见阿里云Elasticsearch离线平台化建设

展望与总结

从横向拓展看，阿里云Elasticsearch会快速补全各个场景的输出，包括公有云国内、国际化的各个区域，加速迭代专有云版本和完善专有云解决方案。技术深度上智能化运维、离线产品化和高可用建设都走在路上。内核能力上，我们会从性能和成本优化等问题入手，并且尝试新的存储系统和硬件基础设施。希望有志于开源事业的小伙伴加入。

最后作为一款新生的云产品，业务的快速发展离不开兄弟团队的大力支持，非常感谢各位老板和搜索中台团队昆仑、洪震团队，也要感谢阿里云ECS团队、安全团队、网络团队和技术支持的小伙伴们。欢迎大家使用和反馈，更多内容请参考文档，有问题请钉钉入群：阿里云Elasticsearch内网用户群。

阿里云Elasticsearch技术钉钉交流群