腾讯云scf（腾讯云scf onedrive）

本文目录一览：

• 1、网易云云函数自动签到为啥不能账号密码登陆
• 2、未来已来：从信通院 Serverless 标准，看无服务器发展趋势
• 3、腾讯云函数不支持C#
• 4、腾讯数据库版和腾讯云函数版区别
• 5、以 Serverless 应用的形式交付 SaaS 服务
• 6、PB级大规模Elasticsearch集群运维与调优实践

网易云云函数自动签到为啥不能账号密码登陆

网易云密码要填写MD5加密密码，不能直接使用密码。

使用腾讯云免费的云函数服务搭建网易云自动打卡，无需手动网页登录打卡，网易云密码要一定要填写MD5加密密码。

云函数（Serverless Cloud Function，SCF）是腾讯云为企业和开发者们提供的无服务器执行环境，帮助用户在无需购买和管理服务器的情况下运行代码。

未来已来：从信通院 Serverless 标准，看无服务器发展趋势

无服务器架构（Serverless）是一种将应用与基础设施彻底分离的架构理念，开发人员无需关心基础设施的运维工作，只需专注于应用逻辑的开发，真正实现了弹性伸缩与按需付费。当前各大云服务商和头部互联网企业的内部业务 Serverless 化升级改造已经开始小范围试水；中小企业基于 Serverless 的业务应用也初见端倪，已然可见初具规模的企业级应用，未来可期。Serverless 生态已初具规模，可以预见，Serverless 将成为下一代云计算服务形态的趋势。

在此背景下， 云函数（SCF）、弹性微服务（TEM）和弹性容器服务（EKS）联合其他相关产品，在 2021 年 Serverless 平台技术能力评估中，共同获得国内首批 Serverless 平台技术能力最高先进级认证。

今年 7 月，在中国信息通信研究院、中国通信标准化协会联合主办的 “2021 可信云大会” 上， 腾讯云拿下了 5 项大奖和 10 项可信云认证，在云存储、Serverless 等各细分领域评测中，获得 54 项可信云认证，数量位居中国云厂商第一 。腾讯云云函数（SCF）、弹性微服务（TEM）和弹性容器服务（EKS）深度参与了此次 Serverless 标准制定和实施过程，腾讯云的 Serverless 产品矩阵所提供的平台技术能力也得到了同行的一致认可。

通过本次 Serverless 标准，为大家带来以下几方面关于 Serverless 发展趋势的解读：

当我们把 Serverless 理念和这些产品结合时，Serverless 化的文件系统（CFS）、数据库（TDSQL-C）、网关（API Gatgeway）和中间件（TDMQ）等可大幅度降低 Serverless 应用的开发和运维成本，让开发者真正聚焦于业务的核心能力，把核心的研发力量和IT投资最大化企业的核心差异化竞争力。通过最终的需求驱动，我们可以预见到，各个云服务产品的 Serverless 化或许是未来云计算发展的必经之路。

过去场景化的 FaaS 是 Serverless 较为主流的应用形态，落地案例也以轻量级的站点、SSR 和云上“云上粘合剂”居多。在本次 Serverless 标准制定过程中，对于如何评估企业实际的 Serverless 落地形式大家展开了丰富的讨论和交流。我们认为 Serverless 的应用形态可以是 FaaS、微服务甚至是单体应用；运行环境可以是原生的运行时，也可以是容器镜像；具体落地时，可以用来对外提供 API 接口，也可以用来运行 音视频转码、直播推流 等计算任务，还可以用来完成 站点压测、AI 推理 等任务。

但是现有存量系统的 Serverless 化无法一蹴而就，这是一个不断设计和矫正的过程，应用 Serverless 化也需要经历迁移、优化和云原生架构改造的几个阶段，不同阶段之间需要有一个较为平滑的切换过程，借助于云函数的 Web Function 的功能可以让迁移过程更加平滑，只有实际负载运行在 Serverless 上之后，才能基于生产环境的实际运行结果、采集定量的指标持续进行 Serverless 应用的优化和云原生改造，进一步发挥出 Serverless 的价值。

当构建应用所依赖的服务逐渐向云上迁移的时候，开发环境也进一步“云”化，和本地开发相比也面临一些新的挑战，比如代码生效时间、本地测试、远程调试和离线开发等等，这些都是影响开发者效率的关键环节。在本次的 「Serverless 平台技术能力」标准中，单独把对于工具链的支持作为衡量 Serverless 平台技术能力的重要维度之一。一个成熟的 Serverless 开发者平台需要能够提供比较友好的IDE支持，让开发者使用熟悉的开发工具进行 Serverless 应用的开发，降低开发者的切换成本；除此之外从本地或者远程测试的时候，需要有良好的工具支持，可以方便地发起调用，触发应用执行并快速返回结果，当结果不符合预期的时候也需要有一系列监控、日志等排障手段帮助开发者快速定位问题。

作为 Serverless 社区最流行的一站式开发者工具， Serverless Framework 拥有百万级别的活跃应用程序以及 50000+ 的日下载量。Serverless Framework 早在 2019 年就已经和腾讯达成了大中华区独家的战略合作，和腾讯云的云函数等 Serverless 产品深度集成，同时社区也有大量开箱即用的插件和模板，帮助开发者快速上手 Serverless 应用开发。除此之外，云开发也是国内最大的微信小程序应用开发平台， 四川天府 健康 通、深圳机场智慧航旅服务等小程序应用都是运行在腾讯云的 Serverless 平台之上。

云函数（Serverless Cloud Function，SCF）是腾讯云为企业和开发者们提供的无服务器执行环境，帮助您在无需购买和管理服务器的情况下运行代码。只需编写核心代码并设置代码运行的条件，即可在腾讯云基础设施上弹性、安全地运行代码。

只需简单修改监听端口，即可将目前流行的 Node.js 框架直接部署上云，享受 Serverless 技术带来的免运维、低成本、按需扩缩容的众多优势。

突破传统 FaaS 形态产品的执行时长的限制， 首家支持运行长达 24 小时的长时任务的 FaaS 产品 ，支持体积较大的音视频文件处理、直播推流、数据分析等多种场景。

业界首发支持分配 120GB(122,880MB) 大内存环境，可以更加轻松地处理具有更高内存或更密集计算需求的工作负载，如音视频处理、大数据分析等。

通过 Web Function、容器化镜像等方式平滑把应用迁移至云函数之上，支持托管 H5 页面、API、SSR 应用、小程序等多种形态的应用形式，缩短研发周期，快速收集市场反馈从而加速产品迭代。

无需运维虚拟机或者其他计算集群，利用云函数提供的极致弹性、按量计费等特性，高效、低成本地进行音视频的录制、转码、混流、剪辑和推流等操作，让企业聚焦于音视频处理逻辑本身，从而不断提升内容质量，优化视听体验。

可以通过触发器连接其他的云服务，如对象存储（COS）、日志服务（CLS）等其他服务，当上游的数据发送变化的时候自动触发函数执行计算逻辑，典型的使用场景包括：CDN 刷新和预热、中间件消息转存、文件备份等。

支持定时、消息队列等多种形式触发函数执行输出处理逻辑，进行数据采集、数据清洗、ETL 等数据处理操作，处理之后的数据可以直接存储至下游的数据仓库、业务数据库或者 BI 分析系统等。

腾讯云弹性微服务 (Tencent Cloud Elastic Microservice, TEM) 是面向微服务应用的 Serverless PaaS 平台，实现 Serverless 与微服务的完美结合，应用零改造上云，按量付费，免运维，提供开箱即用的微服务应用托管服务。

弹性微服务拥抱开源，支持 Spring Cloud 等微服务应用零改造上云，提供应用运行托管、服务注册发现、微服务治理、多维度监控等能力，满足 Consul、Eureka 等多种注册中心需求。弹性微服务帮助您创建和管理云资源，并提供秒级弹性伸缩，您可按需使用、按量付费，极大降低资源和运维成本，让您充分聚焦企业核心业务逻辑，助力业务成功。

弹性微服务通过应用托管、服务注册与发现、服务治理、调用链与多维度监控等功能力，为客户提供开箱即用的微服务解决方案。帮助企业用户快速构建微服务应用，大幅提升运维效率，降低服务治理的复杂度与技术门槛，让企业聚焦核心业务本身，助力客户成功。

在业务呈现潮汐特性、突发流量等场景下，容易出现访问响应超时、错误率提升等问题。腾讯云弹性微服务提供秒级弹性伸缩能力，帮助企业客户轻松应对流量高峰。

腾讯云弹性微服务帮助客户持续集成与交付，实现微服务应用快速迭代。从代码开发到应用交付，弹性微服务提供 IDE 插件、灰度发布等多发布策略的能力，助力企业客户快速验证业务价值。

弹性容器服务 EKS（Elastic Kubernetes Service）是腾讯云容器团队的推出的 Serverless 化 Kubernetes 服务 ，无须用户购买节点，直接部署工作负载。其完全兼容原生 Kubernetes，支持使用原生方式购买及管理资源，按照容器真实使用的资源量计费。

无论是自建 K8s 集群，还是腾讯云 TKE 托管集群，只要网络互通，即可通过部署 EKS 虚拟节点的方式，几乎无成本扩展集群资源池。在扩容 Pod 时可自动或手动快速将 Pod 调度到「虚拟节点」对应的腾讯云公有云资源上。

相比传统的通过扩缩服务器去调度资源（流程重，耗时久），虚拟节点提供一种直接调度 Pod 的能力，可以更快、更高效的弹性。

使用弹性容器服务 EKS 来运行微服务，免除用户对计算节点的运维工作。服务可根据负载情况自动伸缩，使用最合理的资源量来承载应用，降低资源使用成本。

使用弹性容器服务 EKS 运行离线计算任务，只需准备容器镜像，即可快速部署任务负载。另外，弹性容器服务 EKS 仅收取任务真实运行时间所使用算力的费用，任务结束 Pod 自动释放即结束计费。

弹性容器服务 EKS 支持使用 CPU、GPU 以及 vGPU 来运行在线推理服务，丰富的资源规格和弹性伸缩的负载，使运行服务更高效、更经济。

立即体验腾讯云 Serverless Demo，领取 Serverless 新用户礼包 腾讯云 Serverless 新手体验

腾讯云函数不支持C#

C#语言由于需要编译后才可以在 CoreCLR 虚拟机中运行。因此在 SCF 中的使用方式，和 Python、Node.js 这类脚本型语言不同，和Java一样有如下限制：

不支持上传代码：使用 C# 语言，仅支持上传已经开发完成，编译打包后的 zip 包。SCF 环境不提供 C# 的编译能力。

不支持在线编辑：不能上传代码，所以不支持在线编辑代码。CoreCLR 运行时的函数，在代码页面仅能看到再次通过页面上传或 COS 提交代码的方法。

自定义.NET Custom runtime

Custom Runtime的封装工作就是要把各种trigger 的事件封装一个.NET Standard库，开发云函数。自 .NET Core 2.0 开始， 提供了名为 IHostedService 的新接口，有助于轻松实现托管服务，文章《ASP.NET Core 3.x控制IHostedService启动顺序浅探》有深入的实现分析，基于IHostedService 实现一个SCFHostService：

这里我们把SCF的Custom Runtime 抽象到ISCFHost 中

在SCFHost 类中完成Custom Runtime的业务处理，接收来自SCF 的事件，转发给函数进行处理，函数处理的接口 IFunctionInvoker：

默认实现了FunctionInvoker 把请求信息 返回给 SCF：

responseBody 代表了SCF函数的不同Trigger事件信息，我们可以根据不同的Trigger 定义不同的处理函数，例如我们处理HttpTrigger的函数为HttpFunctionInvoker：

上面我们已经完成了最小的MVP封装，利用.NET Core的依赖注入容器封装起来，我们定义了一个ISCFBuilder 来组装函数的配置和服务：

SCF 云函数开发

我们使用.NET Core的控制台程序来开发云函数，创建一个控制台程序, 引用Yhd.TencentCloud.SCF 包，把Program.cs 替换成类似代码：

using Microsoft.Extensions.Configuration;

using Microsoft.Extensions.DependencyInjection;

using Microsoft.Extensions.Hosting;

using Microsoft.Extensions.Logging;

using System.Threading.Tasks;

using Yhd.FindJob;

using Yhd.TencentCloud.SCF.Executors;

public class Index

{

static async Task Main(string[] args)

{

var builder = new HostBuilder()

.ConfigureSCF((context, scfbuilder) =

{

var configuration = scfbuilder.Configuration;

scfbuilder.Services.AddFindJob(configuration);

scfbuilder.Services.AddEasyCaching(options =

{

options.UseInMemory();

//use redis cache that named redis

options.UseRedis(configuration)

.WithJson()

;

});

scfbuilder.Services.AddTransientIFunctionInvoker, JobsHttpFunctionInvoker();

})

.UseConsoleLifetime();

var host = builder.Build();

using (host)

{

await host.RunAsync();

}

}

}

通过ConfigureSCF 可以添加函数的依赖服务，例如上面例子中的EasyCaching 以及函数的服务， 关键的一句是  scfbuilder.Services.AddTransientIFunctionInvoker, JobsHttpFunctionInvoker();  把函数的处理逻辑使用JobsHttpFunctionInvoker 进行注入。把函数的配置放到appsettings.json。

现在SCF 云函数有个问题是本地Windows开发问题，本地的函数逻辑的测试可以通过单元测试进行。还有函数打包必须在Linux环境下进行。

云函数部署

创建 bootstrap 文件

bootstrap 是运行时入口引导程序文件，Custom Runtime 加载函数时固定检索 bootstrap 同名文件，并执行该程序来启动 Custom Runtime 运行时。Custom Runtime 支持任意语言及版本开发运行函数，主要基于 bootstrap 引导程序由开发者自定义实现。其中，bootstrap 需具备以下条件：

需具有可执行权限。

能够在 SCF 系统环境（CentOS 7.6）中运行。

下面这个是 .NET Core 3.1的云函数 bootstrap 文件

#!/bin/sh

echo "Start dotnet bootstrap ~~~"

export DOTNET_ROOT=/opt/rt

export PATH=$(pwd):/opt/rt:${PATH}

dotnet ./index/bin/Release/netcoreapp3.1/index.dll

index.dll 就是我们开发的函数文件。

成功创建 bootstrap 和 函数文件 后，目录结构如下所示：

├ bootstrap

└ index

需要在Linux 下执行以下命令，设置文件可执行权限，并将其添加至 ZIP 包

部署包准备好后，可以通过 云函数控制台 来创建和发布函数

在腾讯云云函数计算上部署.NET Core 3.1的更多相关文章

阿里云函数计算上部署.NET Core 3.1

使用阿里云ECS或者其他常见的VPS服务部署应用的时候,需要手动配置环境,并且监测ECS的行为,做补丁之类的,搞得有点复杂.好在很多云厂商(阿里云.Azure等)提供了Serverless服务,借助于 ...

IIS上部署Net.Core

部署: 1.安装vc_redist.x64vc_redist.x64 2.安装DotNetCore.1.0.0.RC2-WindowsHosting 3.安装DotNetCore.1.0.0-SDK. ...

So Easy - 在Linux服务器上部署 .NET Core App

.NET Core 是微软提供的免费.跨平台和开源的开发框架,可以构建桌面应用程序.移动端应用程序.网络应用程序.物联网应用程序和游戏应用程序等.如果你是 Windows 平台下的 dotnet 开发 ...

在IIS上部署 .Net Core 3.0 项目踩坑实录

在IIS上部署 .Net Core 3.0 项目的主要流程有: 安装并启用IIS 安装AspNetCoreModuleV2 添加.配置网站 设置应用程序池 通过VS发布 一.安装并启用IIS: 安装了 ...

在CentOS 8 上 部署 .Net Core 应用程序

在Centos 8 上 部署 .Net Core 应用程序     -- 记录篇 1.更新dnf 源 1 dnf update 2.安装 Asp.Net Core 运行时 1 dnf install ...

在腾讯云amp;阿里云上部署JavaWeb项目（Tomcat+MySQL）

之前做项目都是在本地跑,最近遇到需要在在云服务器(阿里云或者腾讯云都可以,差不多)上部署Java Web项目的问题,一路上遇到了好多坑,在成功部署上去之后写一下部署的步骤与过程,一是帮助自己总结记忆, ...

ASP.NET Core学习之四 在CentOS上部署.net core

一.安装CentOs 以前在大学学过linux,但是对命令行总是有一种深深的排斥感,几年之后,还是又回来了. 1.下载 现在没法FQ,就算是FQ网速也是蜗牛一样慢,我使用阿里云的镜像站进行下载速度还是 ...

【netcore入门】在Windows IIS上部署.NET Core 2.1项目

部署之前先检查下面2个先决条件是否满足 1.安装了 IIS 模块 win7 在 控制面板→程序和功能→打开或关闭Windows功能→勾选Internet 信息服务(Internet Informati ...

CentOS7系统上部署.net core程序

一.准备工作 首先安装 xshell 和 xftp ,前者用于SSH连接Linux服务器,后者用于FTP上传下载文件. xshell和xftp个人使用是免费的,下载地址 之后分别输入用户名和密码登录主 ...

腾讯数据库版和腾讯云函数版区别

前者为提供云数据库的服务平台，后者为免费运行代码的计算平台。

腾讯云数据库（TencentDB）是腾讯提供的高可靠、高可用、可弹性伸缩的云数据库服务产品的总称。可轻松运维主流开源及商业数据库（MySQL、Redis、MongoDB、MariaDB、SQL Server、PostgreSQL等），它更拥有容灾、备份、恢复、监控、数据传输服务、安全服务、灾备和智能 DBA 等全套服务。

云函数（Serverless Cloud Function，SCF）是腾讯云为企业和开发者们提供的无服务器执行环境，帮助您在无需购买和管理服务器的情况下运行代码。您只需使用平台支持的语言编写核心代码并设置代码运行的条件，即可在腾讯云基础设施上弹性、安全地运行代码。云函数是实时文件处理和数据处理等场景下理想的计算平台。

如果是海量数据存储，可以考虑市面上的对象存储，比如杉岩海量对象存储MOS，为解决海量非结构数据存储提供整体解决方案。

以 Serverless 应用的形式交付 SaaS 服务

随着 2013 年 Serverless 概念的提出，FaaS 函数即服务的开发范式因以下特点逐渐成为开发首选：

1. 快速开发，快速部署；

2. 按量付费，降低成本；

3. 自动扩容，无需维护。

腾讯云 SCF 云函数于 2017 年推出，到现在已服务超百万开发者，随着业务规模增长，业务逻辑的复杂度变高，开发者往往需要通过编排组合多个函数，结合 COS 对象存储、API 网关、DB 数据库等云上资源才能完成一个完整的应用开发。因此我们于 2019 年联合业界广受欢迎的无服务器应用框架 Serverless Framework 推出了一体化管理函数及相关资源的开发方式 - Serverless 应用。

通过 Serverless 应用，开发者可以方便地：

随着云计算的发展，越来越多的软件运行在了云端，软件从服务开发方交付给消费方的方式也随之升级，目前主流的交付方式有两种：

服务开发商将应用开发完成后，制作成 CVM 虚机镜像，发布到镜像市场，消费方在创建 CVM 虚机时选择镜像完成部署使用。而一些需要多台机器节点组合成服务集群的应用，则需要通过多个镜像和运维脚本进行批量创建配置最终完成服务的上线使用。这个过程对服务开发方以及消费方都不太友好，而且服务上线后，需要消费方对服务进行运维，这对消费方是个严峻的考验——选择购买第三方服务，就是因为本身 IT 团队资源不足，现在反而需要投入运维资源。如此种种，该交付方式逐渐被 SaaS 取代。

SaaS，Software as a service，软件即服务，已经逐步发展成云上服务交付的主流形态。它由服务开发方提供统一的线上服务运维管理，通过多租户机制为消费方提供服务。消费方开箱即用，无需管理承载服务的架构和资源运维，只需要为服务本身付费即可。该模式为服务消费方提供了非常好的使用体验，也对服务开发方提出了很高的要求——随着服务的客户增多，服务集群的运维要求也越来越高。然而，SaaS 服务提供商往往是因为对某一个行业或某一个具体的问题场景有核心竞争力，针对性的开发出了解决方案，现在却为了实现交付给客户使用这一过程，被迫投入过多成本维护一个庞大的 SaaS 服务集群。与此同时，由于业务跑在开发商的服务集群里，越来越多的客户开始担心数据安全问题。

那么，有没有一种方式，既可以让服务开发商专注于服务业务的实现，又可以让消费方享受开箱即用免运维同时不担心数据安全问题呢？

答案是肯定的 — Serverless 应用中心 。

Serverless 应用为开发商（Service Provider）提供了便捷的开发范式，更提供了免运维的应用托管平台，承担了开发商到消费方（Service Comsumer）中间的云上桥梁，加速交付效率，统一交付质量，加速企业数字化转型。

服务开发商通过 Serverless 应用中心，提交应用模板，经审核通过后，正式发布到模板中心，供消费方选择。消费方可通过 Serverless Framework CLI，也可通过控制台可视化操作，简单的配置之后，即可完成应用的部署上线。部署过程全程发生在消费方的云上环境中，因此服务运行中产生的数据也都在消费方自己的手上，无需担心数据安全问题。在 Serverless 平台的弹性扩容服务的保驾护航之下，服务可以一直保持高可用。同时按量计费模型只根据业务的实际使用量收费，真正实现服务的稳定、省心、省钱。

部署完成后，消费方可通过控制台对应用的资源进行管理。

随着开发商后续对应用的迭代更新，消费方也能非常方便得通过控制台对应用进行升级。

腾讯云实时音视频 TRTC 联合 Serverless 云函数，推出 「全景录制」一站式录制方案。所见即所得的录制模式，以观众视角实现全景录制，高度还原互动效果，免后期合成，即录即得，录制完成后输出一份完整 mp4 文件，稳定支持高并发业务需求，以更低的成本加速业务迭代。我们在这篇文章里面为大家详细介绍了 《全景录制，一站式录制解决方案》 ，还有专属特惠资源包，低至 1 元，欢迎大家前去体验使用。

腾讯旗下顶尖的音视频通信和处理研发团队，专注于实时音视频通信、音视频编解码前沿算法研究、音视频国际标准、计算机视觉图像处理、端到端音视频质量评测。在实时音视频通信和处理技术、音视频国际标准等领域积累了完整的解决方案和领先的技术水平。Serverless 作为智媒服务底座，提供基础计算能力及相关云服务的整合能力，提供弹性可伸缩的计算能力。（即将上线与大家见面，敬请期待。）

近期发布的应用能力提升，支撑了 Serverless 应用交付过程，主要是以下几个方面：

1. Serverless Framework 多函数组件

在 《Serverless 多函数开发示例》 中为大家详细介绍了多函数组件的开发。

2. 函数的闭源特性

部分服务商希望将应用服务的能力开放出来，但同时又因商业机密或专利保护等原因无法开放源代码，例如音视频的编解码器、机器学习算法等。服务开发商可以通过 Serverless 应用中心提交应用服务模板，将需要闭源的函数以镜像形式发布，即可实现开放能力的同时保护源代码。

3. 应用平滑升级

在小步快跑的互联网时代，服务往往伴随着不断的迭代升级。现在，无论是增加新的功能还是提升服务性能或稳定性，服务开发商都可在 Serverless 应用模板随时提交发布新的版本。新版本经审核发布后，消费方可在控制台收到应用更新提示，点击「升级应用」即可完成在线更新。

Serverless 应用支持提交复杂业务代码，形成一体化的业务模板供用户部署使用，便捷、安全、稳定，大幅降低研发成本周期，快速验证应用服务的 PMF。现开启服务开发商入驻预招募，如果您当前也有套成熟的应用服务代码，您可以通过入驻 Serverless 应用的方式，以更低的成本快速交付使用。 点击提交相关信息 ，我们将在应用市场开放入驻时第一时间与您取得联系。

立即体验腾讯云 Serverless Demo，领取 Serverless 新用户礼包 腾讯云 Serverless 新手体验

PB级大规模Elasticsearch集群运维与调优实践

某中型互联网公司的游戏业务，使用了腾讯云的Elasticsearch产品，采用ELK架构存储业务日志。因为游戏业务本身的日志数据量非常大(写入峰值在100w qps)，在服务客户的几个月中，踩了不少坑，经过数次优化与调整，把客户的ES集群调整的比较稳定，避免了在业务高峰时客户集群的读写异常，并且降低了客户的资金成本和使用成本。下面把服务客户过程中遇到的典型问题进行梳理，总结经验，避免再次踩坑。

解决方案架构师A: bellen, XX要上线一款新游戏，日志存储决定用ELK架构，他们决定在XX云和我们之间二选一，我们首先去他们公司和他们交流一下，争取拿下！

bellen: 好，随时有空！

。。。

和架构师一起前往该公司，跟负责底层组件的运维部门的负责人进行沟通。

XX公司运维老大：不要讲你们的PPT了，先告诉我你们能给我们带来什么！

bellen: 。。。呃，我们有很多优势。。。比如灵活地扩容缩容集群，还可以一键平滑升级集群版本，并且提供有跨机房容灾的集群从而实现高可用。。

XX公司运维老大：你说的这些别的厂商也有，我就问一个问题，我们现在要存储一年的游戏日志，不能删除数据，每天就按10TB的数据量算，一年也得有个3PB多的数据，这么大的数量，都放在SSD云盘上，我们的成本太高了，你们有什么方案既能够满足我们存储这么大数据量的需求，同时能够降低我们的成本吗？

bellen: 我们本身提供的有冷热模式的集群，热节点采用SSD云硬盘，冷节点采用SATA盘，采用ES自带的ILM索引生命周期管理功能定期把较老的索引从热节点迁移到冷节点上，这样从整体上可以降低成本。另外一方面，也可以定期把更老的索引通过snapshot快照备份到COS对象存储中，然后删除索引，这样成本就更低了。

XX公司运维老大：存储到COS就是冷存储呗，我们需要查询COS里的数据时，还得再把数据恢复到ES里？这样不行，速度太慢了，业务等不了那么长时间，我们的数据不能删除，只能放在ES里！你们能不能给我们提供一个API, 让老的索引数据虽然存储在COS里，但是通过这个API依然可以查询到数据，而不是先恢复到ES， 再进行查询？

bellen: 。。。呃，这个可以做，但是需要时间。是否可以采用hadoop on COS的架构，把存量的老的索引数据通过工具导入到COS，通过hive去查询，这样成本会非常低，数据依然是随时可查的。

XX公司运维老大：那不行，我们只想用成熟的ELK架构来做，再增加hadoop那一套东西，我们没那么多人力搞这个事!

bellen: 好吧，那可以先搞一个集群测试起来，看看性能怎么样。关于存量数据放在COS里但是也需要查询的问题，我们可以先制定方案，尽快实施起来。

XX公司运维老大：行吧，我们现在按每天10TB数据量预估，先购买一个集群，能撑3个月的数据量就行，能给一个集群配置的建议吗？

bellen: 目前支持单节点磁盘最大6TB, cpu和内存的话可以放到8核32G单节点，单节点跑2w qps写入没有问题，后面也可以进行纵向扩容和横向扩容。

XX公司运维老大：好，我们先测试一下。

N 天后，架构师A直接在微信群里反馈："bellen, 客户反馈这边的ES集群性能不行啊，使用logstash消费kafka中的日志数据，跑了快一天了数据还没追平，这是线上的集群，麻烦紧急看一下吧。。"

我一看，一脸懵, 什么时候已经上线了啊，不是还在测试中吗？

XX公司运维小B: 我们购买了8核32G*10节点的集群，单节点磁盘6TB, 索引设置的10分片1副本，现在使用logstash消费kafka中的数据，一直没有追平，kafka中还有很多数据积压，感觉是ES的写入性能有问题。

随后我立即查看了集群的监控数据，发现cpu和load都很高，jvm堆内存使用率平均都到了90%，节点jvm gc非常频繁了，部分节点因为响应缓慢，不停的离线又上线。。

经过沟通，发现用户的使用姿势是filebeat+kafka+logstash+elasticsearch, 当前已经在kafka中存储了有10天的日志数据，启动了20台logstash进行消费，logstash的batch size也调到了5000，性能瓶颈是在ES这一侧。客户8核32G*10节点的集群，理论上跑10w qps没有问题，但是logstash消费积压的数据往ES写入的qps远不止10w，所以是ES扛不住写入压力了，所以只能对ES集群进行扩容，为了加快存量数据的消费速度，先纵向扩容单节点的配置到32核64GB，之后再横向增加节点，以保证ES集群能够最大支持100w qps的写入(这里需要注意的是，增加节点后索引的分片数量也需要调整)。

所以一般新客户接入使用ES时，必须要事先评估好节点配置和集群规模，可以从以下几个方面进行评估：

上述场景2遇到的问题是业务上线前没有对集群配置和规模进行合理的评估，导致上线后ES集群负载就很高，通过合理的扩容处理，集群最终抗住了写入压力。但是又有新的问题出现了。

因为kafka积压的数据比较多，客户使用logstash消费kafka数据时，反馈有两个问题：

经过分析客户logstash的配置文件，发现问题出现的原因主要是：

分析后，对kafka和logstash进行了如下优化：

通过上述优化，最终使得logstash机器资源都被充分利用上，很快消费完堆积的kafka数据，待消费速度追平生成速度后，logstash消费kafka一直稳定运行，没有出现积压。

另外，客户一开始使用的是5.6.4版本的logstash，版本较老，使用过程中出现因为单个消息体过长导致logstash抛异常后直接退出的问题:

通过把logstash升级至高版本6.8避免了这个问题(6.x版本的logstash修复了这个问题，避免了crash)。

客户的游戏上线有一个月了，原先预估每天最多有10TB的数据量，实际则是在运营活动期间每天产生20TB的数据，原先6TB*60=360TB总量的数据盘使用率也达到了80%。针对这种情况，我们建议客户使用冷热分离的集群架构，在原先60个热节点的基础上，增加一批warm节点存储冷数据，利用ILM(索引生命周期管理)功能定期迁移热节点上的索引到warm节点上。

通过增加warm节点的方式，客户的集群磁盘总量达到了780TB， 可以满足最多三个月的存储需求。但是客户的需求还没有满足：

XX公司运维老大：给我们一个能存放一年数据的方案吧，总是通过加节点扩容磁盘的方式不是长久之计，我们得天天盯着这个集群，运维成本很高！并且一直加节点，ES会扛不住吧？

bellen: 可以尝试使用我们新上线的支持本地盘的机型，热节点最大支持7.2TB的本地SSD盘，warm节点最大支持48TB的本地SATA盘。一方面热节点的性能相比云盘提高了，另外warm节点可以支持更大的磁盘容量。单节点可以支持的磁盘容量增大了，节点数量就不用太多了，可以避免踩到因为节点数量太多而触发的坑。

XX公司运维老大：现在用的是云盘，能替换成本地盘吗，怎么替换？

bellen: 不能直接替换，需要在集群中新加入带本地盘的节点，把数据从老的云盘节点迁移到新的节点上，迁移完成后再剔除掉旧的节点，这样可以保证服务不会中断，读写都可以正常进行。

XX公司运维老大：好，可以实施，尽快搞起来！

云盘切换为本地盘，是通过调用云服务后台的API自动实施的。在实施之后，触发了数据从旧节点迁移到新节点的流程，但是大约半个小时候，问题又出现了：

XX公司运维小B: bellen, 快看一下，ES的写入快掉0了。

bellen: 。。。

通过查看集群监控，发现写入qps直接由50w降到1w，写入拒绝率猛增，通过查看集群日志，发现是因为当前小时的索引没有创建成功导致写入失败。

紧急情况下，执行了以下操作定位到了原因：

经过了这次扩容操作，总结了如下经验：

在稳定运行了一阵后，集群又出问题了。。

XX公司运维小B: bellen, 昨晚凌晨1点钟之后，集群就没有写入了，现在kafka里有大量的数据堆积，麻烦尽快看一下？

bellen: 。。。

通过cerebro查看集群，发现集群处于yellow状态，然后发现集群有大量的错误日志：

然后再进一步查看集群日志，发现有"master not discovered yet..."之类的错误日志，检查三个master节点，发现有两个master挂掉，只剩一个了，集群无法选主。

登陆到挂了了master节点机器上，发现保活程序无法启动es进程，第一直觉是es进程oom了；此时也发现master节点磁盘使用率100%， 检查了JVM堆内存快照文件目录，发现有大量的快照文件，于是删除了一部分文件，重启es进程，进程正常启动了；但是问题是堆内存使用率太高，gc非常频繁，master节点响应非常慢，大量的创建索引的任务都超时，阻塞在任务队列中，集群还是无法恢复正常。

看到集群master节点的配置是16核32GB内存，JVM实际只分配了16GB内存，此时只好通过对master节点原地增加内存到64GB(虚拟机，使用的腾讯云CVM， 可以调整机器规格，需要重启)，master节点机器重启之后，修改了es目录jvm.options文件，调整了堆内存大小，重新启动了es进程。

3个master节点都恢复正常了，但是分片还需要进行恢复，通过GET _cluster/health看到集群当前有超过10w个分片，而这些分片恢复还需要一段时间，通过调大"cluster.routing.allocation.node_concurrent_recoveries"， 增大分片恢复的并发数量。实际上5w个主分片恢复的是比较快的了，但是副本分片的恢复就相对慢很多，因为部分副本分片需要从主分片上同步数据才能恢复。此时可以采取的方式是把部分旧的索引副本数量调为0， 让大量副本分片恢复的任务尽快结束，保证新索引能够正常创建，从而使得集群能够正常写入。

总结这次故障的根本原因是集群的索引和分片数量太多，集群元数据占用了大量的堆内存，而master节点本身的JVM内存只有16GB(数据节点有32GB)， master节点频繁full gc导致master节点异常，从而最终导致整个集群异常。所以要解决这个问题，还是得从根本上解决集群的分片数量过多的问题。

目前日志索引是按照小时创建，60分片1副本，每天有24*60*2=2880个分片，每个月就产生86400个分片，这么多的分片可能会带来严重的问题。有以下几种方式解决分片数量过多的问题：

和客户沟通过后，客户表示可以接受方式1和方式2，但是方式3和4不能接受，因为考虑到存在磁盘故障的可能性，必须保留一个副本来保证数据的可靠性；另外还必须保证所有数据都是随时可查询的，不能关闭。

在场景5中，虽然通过临时给master节点增加内存，抗住了10w分片，但是不能从根本上解决问题。客户的数据是计划保留一年的，如果不进行优化，集群必然扛不住数十万个分片。所以接下来需要着重解决集群整体分片数量过多的问题，在场景5的最后提到了，用户可以接受开启shrink以及降低索引创建粒度(经过调整后，每两个小时创建一个索引)，这在一定程度上减少了分片的数量，能够使集群暂时稳定一阵。

辅助客户在kibana上配置了如下的ILM策略：

在warm phase, 把创建时间超过360小时的索引从hot节点迁移到warm节点上，保持索引的副本数量为1，之所以使用360小时作为条件，而不是15天作为条件，是因为客户的索引是按小时创建的，如果以15天作为迁移条件，则在每天凌晨都会同时触发15天前的24个索引一共24*120=2880个分片同时开始迁移索引，容易引发场景4中介绍的由于迁移分片数量过多导致创建索引被阻塞的问题，所以以360小时作为条件，则在每个小时只会执行一个索引的迁移，这样把24个索引的迁移任务打平，避免其它任务被阻塞的情况发生。

同时，也在warm phase阶段，设置索引shrink，把索引的分片数缩成5个，因为老的索引已经不执行写入了，所以也可以执行force merge, 强制把segment文件合并为1个，可以获得更好的查询性能。

另外，设置了ILM策略后，可以在索引模板里增加index.lifecycle.name配置，使得所有新创建的索引都可以和新添加的ILM策略关联，从而使得ILM能够正常运行。

客户使用的ES版本是6.8.2， 在运行ILM的过程中， 也发现一些问题：

这是因为shrink操作需要新把索引完整的一份数据都迁移到一个节点上，然后在内存中构建新的分片元数据，把新的分片通过软链接指向到几个老的分片的数据，在ILM中执行shrink时，ILM会对索引进行如下配置：

问题是索引包含副本，而主分片和副本分片又不能在同一个节点上，所以会出现部分分片无法分配的情况(不是全部，只有一部分)，这里应该是触发了6.8版本的ILM的bug，需要查看源码才能定位解决这个bug，目前还在研究中。当前的workaround是通过脚本定期扫描出现unassigned shards的索引，修改其settings:

优先保证分片先从hot节点迁移到warm节点，这样后续的shrink才能顺利执行(也可能执行失败，因为60个分片都在一个节点上，可能会触发rebalance, 导致分片迁移走，shrink的前置条件又不满足，导致执行失败)。要完全规避这个问题，还得在ILM策略中设置，满足创建时间超过360个小时的索引，副本直接调整为0，但是客户又不接受，没办法。

在场景5和6中，介绍了10w个分片会给集群带来的影响和通过开启shrink来降低分片数量，但是仍然有两个需要重点解决的问题：

可以估算一下，按小时建索引，60分片1副本，一年的分片数为24*120*365=1051200个分片，执行shrink后分片数量24*10*350 + 24*120*15 = 127200(15天内的新索引为了保障写入性能和数据可靠性，仍然保持60分片1副本，旧的索引shrink为5分片1副本), 仍然有超过10w个分片。结合集群一年总的存储量和单个分片可以支持的数据量大小进行评估，我们期望集群总体的分片数量可以稳定为6w~8w，怎么优化？

可以想到的方案是执行数据冷备份，把比较老的索引都冷备到其它的存储介质上比如HDFS，S3，腾讯云的COS对象存储等，但是问题是这些冷备的数据如果也要查询，需要先恢复到ES中才可查，恢复速度比较慢，客户无法接受。由此也产生了新的想法，目前老的索引仍然是1副本，可以把老索引先进行冷备份，再把副本调为0，这样做有以下几点好处：

经过和客户沟通，客户接受了上述方案，计划把老索引冷备到腾讯云的对象存储COS中，实施步骤为：

其中步骤1的实施可以通过脚本实现，本案例中采用腾讯云SCF云函数进行实施，方便快捷可监控。实施要点有：

在实施完步骤1之后，就可以批量把对索引进行过备份的索引副本数都调为0， 这样一次性释放了很多磁盘空间，并且显著降低了集群整体的分片数量。

接下来实施步骤2，需要每天执行一次快照，多创建时间较久的索引进行备份，实施比较简单，可以通过crontab定时执行脚本或者使用腾讯云SCF执行。

步骤2实施之后，就可以修改ILM策略，开启cold phase, 修改索引副本数量为0:

此处的timing是创建时间20天后，需要保证步骤2中对过去老索引数据备份先执行完成才可以进入到cold phase.

通过老索引数据冷备并且降低索引副本，我们可以把集群整体的分片数量维持在一个较低的水位，但是还有另外一个问题待解决，也即shrink失败的问题。刚好，我们可以利用对老索引数据冷备并且降低索引副本的方案，来彻底解决shrink失败的问题。

在场景5中有提到，shrink失败归根接地是因为索引的副本数量为1， 现在我们可以吧数据备份和降低副本提前，让老索引进入到ILM的warm phase中时已经是0副本，之后再执行shrink操作就不会有问题了；同时，因为副本降低了，索引从hot节点迁移到warm节点迁移的数据量也减少了一半，从而降低了集群负载，一举两得。

因此，我们需要修改ILM策略，在warm phase就把索引的副本数量调整为0， 然后去除cold phase。

另外一个可选的优化项是，对老的索引进行冻结，冻结索引是指把索引常驻内存的一些数据从内存中清理掉(比如FST, 元数据等)， 从而降低内存使用量，而在查询已经冻结的索引时，会重新构建出临时的索引数据结构存放在内存中，查询完毕再清理掉；需要注意的是，默认情况下是无法查询已经冻结的索引的，需要在查询时显式的增加"ignore_throttled=false"参数。

经过上述优化，我们最终解决了集群整体分片数量过多和shrink失败的问题。在实施过程中引入了额外的定时任务脚本实施自动化快照，实际上在7.4版本的ES中，已经有这个功能了，特性名称为 SLM (快照生命周期管理)，并且可以结合ILM使用，在ILM中增加了"wait_for_snapshot"的ACTION, 但是却只能在delete phase中使用，不满足我们的场景。

在上述的场景4-7中，我们花费大量的精力去解决问题和优化使用方式，保证ES集群能够稳定运行，支持PB级别的存储。溯本回原，如果我们能有一个方案使得客户只需要把热数据放在SSD盘上，然后冷数据存储到COS/S3上，但同时又使冷数据能够支持按需随时可查，那我们前面碰到的所有问题都迎刃而解了。可以想象得到的好处有：

而这正是目前es开源社区正在开发中的Searchable Snapshots功能，从 Searchable Snapshots API 的官方文档上可以看到，我们可以创建一个索引，将其挂载到一个指定的快照中，这个新的索引是可查询的，虽然查询时间可能会慢点，但是在日志场景中，对一些较老的索引进行查询时，延迟大点一般都是可以接受的。

所以我认为，Searchable Snapshots解决了很多痛点，将会给ES带了新的繁荣！

经历过上述运维和优化ES集群的实践，我们总结到的经验有：

从一开始和客户进行接触，了解客户诉求，逐步解决ES集群的问题，最终使得ES集群能够保持稳定，这中间的经历让我真真正正的领悟到"实践出真知"，只有不断实践，才能对异常情况迅速做出反应，以及对客户提的优化需求迅速反馈。

腾讯云scf的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于腾讯云scf onedrive、腾讯云scf的信息别忘了在维启网络进行查找喔。