物理机架构时代

2022年，整个日志Elasticsearch拥有数十套服务集群，几百台物理机。这么多台机器耗费成本非常高，而且还要花费很大精力去维护。在人力资源有限情况下，存在非常多的弊端，运行成本高，不仅是机器折旧还有机柜等费用。

流量特征

这是来自某个业务线，如下图1，真实流量，潮汐性非常明显。好未来有很多条业务线，几乎跟这个趋势都一致的，除了个别业务有“续报”、“开课”等活动特殊情况。潮汐性带来的问题就是高峰期CPU、内存资源是可以消耗很高；低峰期资源使用量非常低，由于是物理架构，这些资源无法给其他业务线共享。

图1

降本增效-容器化改造原动力

日志服务对成本的空前的压力促使我们推进Elasticsearch进行架构改造；如何改造，改造成什么样子，这两个问题一直是推进改造原动力。业界能够同时对水平扩展和垂直扩展就是k8s，我们开始对Elasticsearch 改造成能在k8s上运行进行探索，从而提升CPU、内存利用率。

物理机时代，没办法把资源动态的扩缩，动态调配，资源隔离，单靠人力操作调度成本太高，几乎无法完成；集群对内存资源需求要比CPU资源大很多，由于机器型号配置是固定的，无法“定制”，这也会导致成本居高不下。所以，无论从那个方面来讲，容器化优势非常明显，既能够优化成本，也能够降低运维复杂度。

进行架构升级重点难点- API服务

改造过程，我们遇到了很多问题，比如容器ES版本和物理机ES版本不一致，如何让ES API能够兼容不同的ES版本，由于版本的不兼容，导致无法直接使用原有的tribenode进行服务，怎么提供一个高可用的Elasticsearch API服务。我们考虑到多个方面，比如使用官方推荐的proxy模式、第三方服务等进行选择，经过多方面对比，选择了极限网关进行tribenode替换。

原始ES API服务痛点

--  API访问没有流量控制

--  可观测性差，而且稳定性一般

--  版本兼容性差

在物理机时代ES集群，API架构如图2，可以明显看到tribe node对所有ES集群的“侵入性”是非常大的，这就带来了很多问题，比较严重的就是单个集群对ES tribenode的影响和版本升级带来的不兼容问题。

图2

通过图3，我们可以看到，极限网关对于版本兼容性很好，能够适配不同的版本。因此，最终选择极限网关作为下一代ES API服务方。

图3

在2023年3月份，通过elastic官方ECK模式，完成全部日志ES集群容器化改造，拥有数百节点，1PB+数据存储，每日新增数据100T左右。紧接着，除了日志服务外，同时支持了好未来多条业务线。

   图4

下面主要讲述了，为什么选择极限网关，以及极限网关在好未来落地、应用这些内容。

为什么选择极限网关？

学习成本低

我们可以从文档中看到极限网关，其架构简洁，语法简单，直观易懂。学习成本比较低，上手非常快，对新手友好。

性能强悍

经过压测，发现极限网关速度非常快，且针对 Elasticsearch 做了非常细致的优化，能成倍提升写入和查询的速度。

安全性高

支持多种认证方式，最简单的账号密码认证，可以给自定义多个账户密码，大大简化了Elasticsearch的安全设置，同时，还可以支持LDAP安全验证。

跨版本支持

我们容器化改造过程需要兼容不同版本的Elasticsrearch，极限网关针对不同的 Elasticsearch 版本做了兼容和针对性处理，能够让业务代码无缝的进行适配，后端 Elasticsearch 集群版本升级能够做到无缝过渡，降低版本升级和数据迁移的复杂度，非常匹配我们的业务场景。

灵活可扩展

可灵活对每个请求进行干预和路由，支持路由的智能学习，内置丰富的过滤器，通过配置动态修改每个请求的处理逻辑，也支持通过插件来进行扩展，满足我们对流量的控制，尤其是限流、用户、IP等这些功能非常实用。

痛点

在升级之前使用tribe 作为API服务提供后端，几乎相当于裸奔，没有任何认证策略；另外，tribe本身的稳定性也有问题，官方在新版本逐渐废弃这种CCS（跨集群搜索），期间出现多次服务崩溃。

极限网关解决问题

极限网关通过，“basic_auth”插件，提供最基本的安全校验，使用起来非常方便；同时，极限网关提供LDAP插件，可以接入公共的LDAP服务，对所有的访问用户进行校验，安全策略对所有的用户生效，不用担心因为IP问题泄漏数据等。

强大的过滤功能

在使用ES集群过程中，许多场景，需要对请求进行控制、限制等操作。在这方便，感受到了极限网关强大的产品力。比如下面的两个场景：

1、对异常流量进行限流

支持对IP限流

支持对hostname限流

支持header限流

2、对异常用户进行封禁

当 Elasticsearch 是通过 Basic Auth 或者 LDAP 方式来进行身份认证的时候，request_user_filter 过滤器可用来按请求的用户名信息来进行过滤。操作起来也非常简单，只需要“request_user_filter”这一个过滤器。

     - request_user_filter:          include:            - "elastic"          exclude：           - "Ryan"

总结来讲，主要有这些方面的功能：

图5

痛点

改造前经常为看不到直观的数据指标感到头疼，查看指标需要多个地方同时打开，去筛选，查找，非常繁琐，付出的成本非常大。为此，大家都再考虑如何优化这种情况，无奈优先级比较低，一直没有真正的投入时间去优化这块。

完美解决

使用了极限网关，通过收集请求日志，非常清晰的收集到想要的数据，具体如下：

总体方面：

流量曲线

状态码占比

缓存统计

每台网关请求流量

细节方面：

打印每次请求语句

可以查看请求到具体ES节点流量

可以查看过滤器的列表

通过下图，我们可以从管理视角直观的看到各种信息，这对于管理员来讲，省时省力，方便快捷。

图6

由于前期日志业务上云，受到非常好的反馈，多个业务线期望能够上云上服务，达到降本增效的目的。

支持双写

数据可以通过极限网关同时写入两个ES集群，能够保障数据完全一致，安全可靠。

无缝切换

切换很丝滑，影响非常小，能够让外界几乎感受不到服务波动。

图7

通过使用极限网关，自建 ES 集群可以无缝的迁移上云，在整个迁移的过程中，两套集群通过网关进行了解耦，在迁移的过程中还能实现版本的无缝升级，极大降低了迁移成本，提高迁移效率，多次验证服务稳定可靠。

这是其中一套极限网关的流量统计。用这部分数据进行巡检，一目了然，做到全局的掌控，提高感知力度。

图8

极限网关提供一系列高性能和高可靠性的网关服务。使用这样的服务给我们带来以下好处：

1、可观测性好：极限网关可以动态的对Elasticsearch运行过程中请求进行拦截和分析，通过指标和日志来了解集群运行状态，这些指标可以用于提升性能和业务优化。

2、增强安全性：包含先进的安全机制，如basicauth、LDAP等支持，保护用户数据不受未授权访问和各种网络威胁的侵害。

3、高稳定性：通过冗余设计和故障转移机制，极限网关能够确保网络服务的高可用性，即使在某些组件发生故障时也能保持服务不中断，单版本最长服务超过15个月。

4、易于管理：通过提供INFINI Console简洁直观的管理界面，让用户能够轻松配置和监控网络状态，提升管理效率。

5、客户支持：良好的客户服务支持可以帮助用户快速解决使用过程中遇到的问题，提供专业的技术指导。

综上所述，极限网关为用户提供了一个高速、安全、稳定且易于管理的ES网关，适合对网络性能有较高要求的个人和企业用户。

第一阶段，完成了日志ES集群，所有集群的容器化改造，合并，成功的把成本降低了60%以上。这期间积累了丰富容器化经验，为业务ES集群上容器做了良好的铺垫；成本优势和运维优势吸引越来越多的业方接入到容器化ES集群。

提升ES集群效能--新技术应用&&版本升级

极限科技官方推荐的Easysearch 在压缩率，查询速度等等方面有很多的优势，通过长时间的测试稳定性，新特性，对比云原生的ES集群，根据测试结果，给“客户”提供多种选择，这也是工作重点之一。

我们当前使用的ES版本是6.8，已经远远落后于官方版本，今年我们计划在选择合适的集群升级ES版本，拥抱更多官方提供的特性。

混合（多）云架构支持

随着越来越多的ES集群在机房的k8s集群部署，这里资源出现了紧张局面。我们尝试在云上部署自建ES集群，弥补机房资源有限，无法大规模扩容，同时能够支持多活场景，满足更多客户的不同需求。混合云主要实现以下几种能力：

1、扩缩容：满足不同业务灵活适配

混合（多）云部署，可以让负载内部私有云ES，同时部署到公有云，提升扩展IT基础设施不仅局限于CPU、内存，还有存储。比如某一个业务要做活动，预估流量“大爆发”，需要提前准备大规模资源，在机房内根本来不及采购扩容支持，然而在公有云上就能很方便扩容、缩容。在云上搭建ES集群，设置满足需求的数量、容量、配置，配合极限网关路由策略，精准的把控流量流向。

图9

2、灾备：紧急情况快速部署，恢复ES集群读写

当机房级别大规模故障，部分业务实现了多活，单一的机房故障不会影响其服务能力，而此时比如日志查看等仍有需求，为了满足这部分“客户”需求，可以在云上K8S集群，快速搭建ES集群，恢复日志读写功能。

 图10

https://infinilabs.cn/docs/latest/gateway

https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-overview.html