赵弘扬：阿里云Elasticsearch技术演进之路

Posted 2023-05-03

参考技术A

导读： 全文将围绕以下三方面内容介绍阿里云Elasticsearch技术。

01

阿里云Elasticsearch业务

1. 业务规模

阿里云Elasticsearch业务（简称ES），从2017年至今已经服务了几千个客户，数据规模达20PB，在公共云上拥有10000+集群，10W+节点规模，是一个成熟的云原生服务。

2. Elasticsearch在日志场景通常会遇到的问题

在企业的数字化转型过程中会生成大量日志数据，企业通过Elasticsearch满足日志检索、存储、归档审计的需求，而这些需求归根结底都会落到成本的增加，体现在以下三个方面：

3. 风险解读

在正常情况下，流量到ES协调节点，然后将数据写入Data Node；当流量变成正常情况的10倍时，对ES集群的压力就变得很大，一系列问题会接踵而来。

这种情况可以通过集群扩容的方式进行缓解，但扩容的同时又会产生新的问题：

① 稳定性风险

② 运维复杂度风险

③ 成本风险

--

02

阿里云Elasticsearch日志Serverless服务

1. 日志Serverless服务能力解读

基于上述问题和风险，阿里云引入了 两个新功能 ：

① Indexing Service

Indexing Service是一个超大的ES集群阵列，专做Indexing Build，每个客户可灵活使用， 它具有以下特性：

图中灰色虚线内是用户的ES集群，当流量洪峰到来时，用户可以将流量转发至Indexing Service的SLB中进行build index，然后通过segment merge的方式，回到用户ES集群的Data Node。这样通过外部的云上弹性服务，减轻了用户ES集群压力，实现秒级弹性扩缩容的需求。

② 智能海量存储引擎

2. 日志Serverless服务价值解读

① Serverless日志写入服务：Indexing Service

通过读写分离架构，ES集群的数据写入在云端服务进行托管加速，为用户实例和云端服务搭建桥梁，依托云端弹性计算能力，突破本地集群的物理资源限制。

对比开源ELK生态：

② Serverless日志存储服务：智能海量存储引擎

基于计算存储分离架构及多层存储介质混合，提供可靠的海量弹性低成本存储并保证查询性能，无须提前预留集群存储容量，根据实际数据的存储量按量计费。

3. Elasticsearch日志Serverless服务发布

全球范围内首个在云上提供Serverless能力的云原生Elasticsearch服务， 其核心价值体现在三个方面：

4. 真实案例收益

①客户场景描述

汽车 行业的IT系统，大多是分批建设，技术架构及系统复杂有 历史 包袱，IDC、多云架构比较普遍。新兴的业务部门，一方面需要满足政策合规要求，一方面希望对整体日志数据进行价值挖掘，通常会遇到如下问题：

②方案构架及价值点

--

03

阿里云Elasticsearch技术演进之路

阿里云Elasticsearch技术演进图

Elasticsearch未来的发展会继续在云原生Serverless上进行演进和迭代，在日志场景下优化成本，通过服务化的能力提升日志场景中的ES产品的易用性，帮助客户解决日志场景下前置日志链路上的问题。

同时，与ES社区就Elasticsearch TSDB时序引擎进行共建，相信很快可以在未来的ES新版本中推出TSDB能力。

今天的分享就到这里，谢谢大家。

分享嘉宾：赵弘扬 阿里云 高级产品专家

出品平台：DataFunTalk

01/ 分享嘉宾

02/ 报名看直播 免费领PPT

04/ 关于我们

欢迎转载分享评论，转载请私信。

云原生时代，应用架构将如何演进？

阿里妹导读：IaaS上云和PaaS上云有什么区别？如何借助云原生技术来提升交付的速度？云原生时代背景下，研发的关注点又会有哪些转变？阿里云高级技术专家许晓斌通过本文分享从IaaS上云时代到PaaS上云时代的应用架构演进方向，以及云原生技术与应用架构演进的关系。

文末福利：阿里云云原生DevOps解决方案重磅发布。

 

云原生已经进入了PaaS上云为主的阶段

阿里巴巴已经经历了IaaS上云的阶段，迈进到了PaaS上云的时代。在去年的“双11”，阿里巴巴就已经实现了电商核心系统的全面上云，这里的上云主要是在IaaS层。所谓IaaS主要就是对计算、网络、存储的虚拟化，经过了这个阶段，阿里巴巴就进入了PaaS上云的阶段。在PaaS上云这个阶段就需要使用更多的云产品，包括中间件、存储、缓存甚至是应用托管平台等。

IaaS阶段和PaaS阶段其实存在很大的差别。在IaaS阶段，对于应用研发来说，所关心的往往就是基础设施和资源，通俗来讲就是虚拟机或者容器等，这些对应用架构几乎没有任何侵入。但是在PaaS上云阶段，当你使用云产品，比如云Redis、云RDS、云OSS、云RabbitMQ等的时候，都会对于应用架构产生比较强的侵入。那么，这样的侵入会对应用架构产生什么样的影响，是所有研发架构师所需要思考的一个问题。

云原生技术

如果大家尝试去搜索云原生技术，就会看到Google Cloud的定义、CNCF的定义以及其他很多的云产商以及开源软件的定义，而这些定义看法都各有不同。简单归纳可以分为如下图所示的几类，纵向来看，分为了应用架构、生命周期管理、流量管理，以及基础设施及依赖四个维度；横向来看，又分为了微服务、12 Factor Apps、容器、BaaS、GitOps/IaC以及Service Mesh几个维度。

今天，大家都会谈到基于微服务架构做云原生，而不是基于巨石应用架构或者简单的CS架构。Quarkus提出了12 Factor Apps，意思就是说如果在今天想要让应用跑在Quarkus等这些应用托管平台上，对于应用具有一定的要求，大概是12条原则，比如配置和代码分离等，当然后续还有很多的扩展。这些原则中的很多条目的意思都是说只要你符合这些原则，那么应用托管平台就能够为你提供更多的能力，比如免运维等。容器的核心是使用一种标准的交互方式让平台能够管理应用的生命周期，包括发布、扩容以及自愈等。

BaaS——Backend as a Service，能够尽量使用现有的服务来构建应用程序。Service Mesh的本质是管理流量，今天的应用程序都在接收流量，提供服务时流量又需要出去，在这个过程中如何管理服务发现、流量路由规则等都需要Service Mesh技术。最后需要重点介绍的就是GitOps和IaC（Infrastructure as Code），这些技术如今在行业里面得到了越来越多的关注，尽管还没有事实上的标准，但是很多云计算公司正在不断努力。其含义是说今天在使用基础设施的时候，可以用代码去声明这些基础设施的需求。总而言之，上述这些内容都是围绕应用架构、生命周期管理、流量管理，以及基础设施及依赖这四个维度的。

业务关心的是交付速度

对于业务而言，最关心的往往是交付速度。如果你和业务总监或者CTO去聊，他们就会问你，拥有这么多的技术对于业务有什么好处？可能会谈到成本的优势、管理的优势，但是对于几乎所有业务而言，最核心的是研发效率的提升。所以我们应该思考云原生技术如何才能帮助实现更快的交付。

借助云原生技术来提升交付服务的速度可以大致分为三个步骤。

标准化平台/服务和应用的协议

将平台/服务和应用之间的协议进行标准化。如果IaaS层用云的话协议就是机器，就是虚拟机、容器等，对于业务应用而言，看到的就是一个操作系统，这样应用就可以使用操作系统上的各种资源，这样做的好处在于不需要关心物理机以及机器的故障等问题。

与业务无关能力进一步解耦至平台

对于业务应用而言，看到的就不是一个操作系统了，会给到一个更加上层的协议，让平台帮助应用实现自动伸缩以及自愈等，还可以帮助应用实现自动腾挪，当底层基础设施发生故障的时候，可以将应用从一台机器迁移到另外一台机器，也就是生命周期管理。 基于上述协议，平台的很多能力就能够下沉，比如原本需要手工管理的事情只需要通过代码声明就可以很好地实现了，有了这些协议之后，业务应用就能够将相关的生命周期管理托管给平台。

应用架构升级

除了上述两点之外，第三步就是让应用架构需要通过升级来适应，这样才能让相关能力下沉到云平台。

IaaS上云阶段到云原生上云阶段的转变

进一步细化就会发现，在原来的IaaS上云阶段，除了需要关心业务逻辑之外，还需要关心业务应用的生命周期管理、流量管理，还需要自己进行搭建和配置中间件，比如在云环境中搭建Redis、kafka等，也就是说花费了大量时间在应用依赖管理的事情上，无法让云平台进行管理。今天，在PaaS上云或者云原生上云的阶段，想要做到的就是尽量使用云平台提供的能力，将更多的精力集中在业务本身，而将业务无关的通用技术能力都交给云来管理。

核心问题：

• 业务无关能力如何解耦至平台？

• 平台和业务（应用）之间的协议如何定义？

• 应用架构需要如何适应？

以前在IaaS上云阶段，应用和操作系统进行交互存在标准的协议，而今天在PaaS上云阶段，这样的协议应该是什么，需要被重新定义。此外，基于这样的协议如何实现能力下沉，也是很多包括阿里云在内的很多云厂商所做的事情，比如阿里云基于RocketMQ做了RocketMQ Service，基于容器的一些协议提供容器服务等等。当然，现在只是一个开始，未来这部分内容将会更加丰富和完整。

例子1：Service Mesh把服务发现和流量从业务剥离

与此同时，应用架构也需要去适应。这里以Service Mesh为例，之前在应用内部的流量是SDK的形式，那么在演进的过程中如何将服务发现和流量等从业务SDK中剥离出来放到Sidecar里面去，进而交给云平台处理，这就是应用架构演进的一个例子。

• 服务注册 & 发现

• 流量路由

• 流量回放

• 发布过程中流量控制

例子2：轻量化容器把日志采集从业务中剥离

以前在做日志采集的时候，需要在各个虚拟机中开启一个日志采集进程，并将采集到的日志传输到日志采集平台，并通过可视化界面进行分析。而今天，在云原生时代，更好的做法是让容器服务从stdout来抓取日志，也可以通过配置的方式去特定日志目录获取日志数据。但是采集这个事情需要搬到Sidecar里面去实现Agent的升级。所以轻量化容器把日志采集从业务中剥离也是一个架构演进的例子。

• 资源隔离

• 独立升级

例子3：业务提供探针，让平台实现生命周期管理

生命周期管理对于应用架构的要求就是原来的应用程序启动之后是健康的还是不健康的，都是应用程序的运维或者研发需要负责和关心的。而在云原生时代，希望将这种协议固定住，通过业务提供探针，来判断应用程序是健康的还是不健康的，这就需要在应用内部通过HTTP协议或者Shell来提供健康信息，这样才能够应用生命周期管理落到平台中去。

• 自动弹性

• 自动腾挪

• 自动重启（自愈）

协议（Contract）=API+Configuration

统筹来看，协议就是API+配置。对于API而言，如果大家使用缓存，那么基本会将开源的协议当做API，这样的协议通常会比闭源的协议更加友好。对于RPC协议，开源的GRPC和DUBBO会优于私有的HSF。此外还有对于基础设施的协议，比如Terraform、Pulumi这些其实是在定义一种开源的配置语言，这些配置语言能够帮助声明所需要的基础设施，比如容器、磁盘、网络、存储等，虽然现在的配置语言种类比较多，但是未来最终会形成1到2种语言，就像是Java的SDK一样，未来使用云资源必然会呈现出一套SDK来，这个SDK必然是根据一套配置代码化语言来构建的。进一步的，GitOps等将发布流程、发布策略也定义成了一套语言，而这在未来将会应用程序与云之间的标准协议。

• Docker (& OCI) 是标准的软件交付 API。

• 作为 RPC 协议，开源的 GRPC/DUBBO 优于私有的 HSF。

• 作为缓存协议，开源的 Redis 优于私有的 Tair。

• 微软的 Dapr 尝试基于 sidecar 架构将 API 标准化到 HTTP/GRPC 层，以去 SDK，并支持多语言。

• Terraform，Pulumi 等 IaC 产品，通过配置语言声明基础设施。

• GitOps 进一步的使用代码声明环境、发布流程、发布策略内容。

研发关注点的转变

原来的时候，应用程序所需要关心的东西太多，比如各种SDK、各种运维事件，但是这些东西实际上都可以被抽象成一种模型，并且使用一种新的语言来定义，这也是整个云产业所关心的事情。

之所以一直强调新语言和新协议，是因为定义了新的语言或者协议之后，应用程序所需要关心的就是这些了。对于开发者而言，最关心的就是代码，那么如果能够用代码来描述应用对于基础设施、运维、托管的需求，那么就会对应用程序非常友好。应用程序只需要能够对接这个协议，那么就能够在专有云、公有云、阿里云上同时运行。

总结

未来，云上的资源会越来越丰富，在基础设施之上，云平台提供了更多的PaaS能力，就像是操作系统在提供了进程这些能力之上，还有很多的SDK。但是，这些能力目前在使用上还非常低效和不标准，使用过程也比较麻烦。今天我们在以类似汇编的形式使用云，云原生则在重新定义应用程序与云平台之间的契约，并围绕这个契约来构建更高级的编程语言和工具。 这就是云原生时代背景下，应用架构演进非常重要的一个方向。

---

阿里云云原生DevOps解决方案发布

如何借助云原生技术实现企业DevOps转型“超车”？阿里云新品发布会第110期，发布四大解决方案：云原生应用持续交付解决方案、微服务持续交付解决方案、函数计算持续交付解决方案、企业级互联网架构持续交付解决方案，手把手带你玩转云原生DevOps，还可领取限时优惠！

2020年10月21日下午14:00-15:00，不见不散！点击“阅读原文”，立即预约直播吧~

加「阿里妹」 微信 好友

免费领取海量学习资料

戳我，预约直播。