常用云PaaS组件及开源组件业务运维指南

1 目标和范围

1.1 目标

用于指导使用腾讯云的PaaS组件和常用开源组件进行业务开发的服务的部署实施环节和后续生产环境运维。文档摘取了腾讯云的官网文档中运维需要关注的技术指标，应用于初创团队快速对应用开发组件有一个快速了解。

1.2 产品组件范围

2 负载均衡

负载均衡是指设置在一组功能相同或相似的服务器前端，对到达服务器组的流量进行合理分发，并在其中某一台服务器故障时，能将访问请求转移到其它可以正常工作的服务器的软件或网络设备。

2.1 CLB负载均衡

2.1.1 使用场景

负载均衡服务通过设置虚拟服务地址（VIP），将位于 同一地域 的多台云服务器资源虚拟成一个高性能、高可用的应用服务池；根据应用指定的方式，将来自客户端的网络请求分发到云服务器池中。

负载均衡主要适用于以下场景：

流量分发，将高访问量的业务通过负载均衡分发到多台云服务器上。

消除单点故障，当其中一部分云服务器不可用时，负载均衡可自动屏蔽故障的 CVM 实例，保障应用系统的正常工作。

横向扩展，根据业务发展的需要，按需扩展应用系统的服务能力，适用于各种 Web Server和 App Server。

2.1.2 技术指标

实例类型

当前负载均衡有传统型和应用型。传统型为早期版本，应用型为增强版本，且应用型几乎可覆盖传统型的所有功能。从产品功能、产品性能等多方面考虑，我们建议您使用应用型负载均衡。

协议支持及端口配置

支持 四层转发 和 七层转发 两种监听器模式，针对不同的协议类型，分别作用于网络模型中的传输层和应用层。

轮询方式

轮询方式是负载均衡向 后端服务器 分配流量的算法，根据不同的轮询方式及后端服务器的权重设置，可以达到不同的效果。

加权轮询算法:

加权轮询算法（Weighted Round-Robin Scheduling）是以轮叫的方式、依次请求调度不同的服务器。加权轮询调度算法可以解决服务器间性能不一的情况，它用相应的权值表示服务器的处理性能，按权值的高低和轮询方式分配请求到各服务器。加权轮询算法根据新建连接数来调度，权值高的服务器先收到连接，权重值越高被轮询到的次数（概率）也越高，相同权值的服务器处理相同数目的连接数。

加权最小连接数算法:

最小连接调度是一种动态调度算法，与轮询调度算法相反，它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器时，其连接数加一; 当连接中止或超时，其连接数减一。

加权最小连接数算法（Weighted Least-Connection Scheduling）是在最小连接数调度算法的基础上，根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求，是在最小连接数调度算法的基础上的改进。

源地址散列调度算法:

源地址散列调度算法（ip_hash）根据请求的源 IP 地址，使用散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器为可用且未超载状态，则请求发送到该服务器，反之则返回空。

会话保持

会话保持可使得来自同一 IP 的请求被转发到同一台后端服务器上。默认情况下，负载均衡会将每个请求分别路由到不同后端服务器实例负载。但是，您可以使用会话保持功能使特定用户的请求被路由到同一台后端服务器实例上，这样可以使某些需要保持会话的应用程序（如购物车）合理地工作。

四层会话保持：

四层转发情境支持简单会话保持能力，会话保持时间可设为 30-3600 秒中的任意整数值，超过该时间阈值，会话中无新请求则断开连接。

七层会话保持：

七层转发情境支持基于 cookie 插入的会话保持能力（由负载均衡器向客户端植入 cookie），会话保持可选时间为30-3600秒，关于插入 cookie 会话保持的更多信息可以参考这里。

连接超时时间：

当前HTTP连接超时时间暂时不支持调整，默认为 75 秒。超过该时间阈值，会话中无数据传输则断开连接。

当前TCP连接的超时时间暂时不支持调整，默认为900秒。超过该时间阈值，会话中无数据传输则断开连接。

健康检查

负载均衡实例可以定期向后端服务器发送 Ping、尝试连接或发送请求来测试后端服务器运行的状况，这些测试称为健康检查。

当后端服务器实例被判定为不健康时，负载均衡实例将不会把请求转发到该实例上。但健康检查会对所有后端服务器（不管是判定为健康的还是不健康的）进行，当不健康实例恢复正常状态时，负载均衡实例将恢复把新的请求转发给它。

四层转发健康检查配置：

四层转发的健康检查机制由负载均衡器向配置中指定的服务器端口发起访问请求，如果端口访问正常则视为后端服务器运行正常，否则视为后端服务器运行异常。对于TCP的业务，使用 SYN 包进行探测。对于 UDP 业务，使用 Ping 进行检查。

响应超时时间：2 - 60秒。

检查间隔：5 - 300秒。

不健康阈值：2 - 10次（健康后端服务器出现此指定次数响应超时后，视为不健康）。

健康阈值：2 - 10次（不健康后端服务器出现此指定次数响应超时后，视为健康）。

七层转发健康检查配置

七层转发的健康检查机制由负载均衡器向后端服务器发送 HTTP 请求来检测后端服务，负载均衡器会通过 HTTP 返回值是否为http_2xx、http_4xx来判断服务是否正常。后续将推出用户自定义的方式，对响应代码所代表的状态进行描述。

响应超时时间：暂不能设置，默认响应超时时间为5秒。

检查间隔：5 - 300秒，默认为6秒

不健康阈值：2 - 10次，默认为 3次 （健康后端服务器出现此指定次数响应超时后，视为不健康）

健康阈值：2 - 10次，默认为 3次（不健康后端服务器出现此指定次数响应超时后，视为健康）

HTTP 请求方式：默认使用 HEAD 方法，服务器仅返回 HTTP 头部信息，对应的后端服务需支持 HEAD，选择 HEAD 可降低后端开销，提升请求效率；若使用 GET 方法，后端服务则需支持 GET。

2.1.3 应急处理

健康检查异常

四层排查

TCP协议下，负载均衡使用SYN包进行探测；UDP协议下，负载均衡使用ping命令进行探测。

在页面查看LB后端服务器端口的健康状态，若不健康，排查思路如下：

- 确定CLB后端服务器是否有配置有防火墙影响了服务，如果有请关闭

- 使用netstat命令，确定后端服务器的端口是否有进程在监听，若未启动，则重新启动服务

七层排查

针对7层（HTTP协议）服务，当某一监听出现健康检查“异常”时，可以通过如下方面进行排查：

- 由于负载均衡的七层健康检查服务与后端服务器之间的通讯是走内网的，您需要登录服务器检查应用服务器端口是否正常监听在内网地址上，如果没有监听在内网地址，请将应用服务器端口监听到内网上，从而确保负载均衡系统和后端服务器之间的通讯正常。

客户端timewait过多

客户端timewait太多，是因为客户端主动断开连接，客户端每断开一个连接，该连接都会进入timewait状态，默认60s超时回收。一般情况下，遇到这种场景时，客户会选择打开tcp_tw_recycle和tcp_tw_resuse两个参数，便于回收timewait状态连接。

然而当前CLB没有打开tcp_timestamps选项，导致客户端打开的tcp_tw_recycle和tcp_tw_resuse都不会生效，不能快速回收timewait状态连接。

针对这个问题，有如下解决方案：

- HTTP使用短连接（Connection: close），这时由LB主动关闭连接，客户端不会产生timewait

- 如果场景需要使用长连接，可以打开socket的SO_LINGER选项，使用rst关闭连接，避免进入timewait 状态，达到快速回收端口的目的

2.2 Nginx

2.2.1 使用场景

Nginx是一款开源的、高性能的HTTP服务器和反向代理服务器。

在我们日常工作中常用到如下功能：

反向代理。以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。真实的服务器不能直接被外部网络访问，而代理服务器能被外部网络访问的同时又跟真实服务器在同一个网络环境。

负载均衡。把请求分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

HTTP服务器。Nginx本身也是一个静态资源的服务器，当只有静态资源的时候，就可以使用Nginx来做服务器，同时现在也很流行动静分离，就可以通过Nginx来实现。

正向代理。一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。

2.2.2 技术指标

目录

Nginx主目录

/usr/local/nginx

Nginx配置文件

主配置文件：

/usr/local/nginx/nginx.conf

各业务配置：

/usr/local/nginx/conf.d/[业务英文描述].nginx.conf

数据类型配置文件：

/usr/local/nginx/ mime.types

Cgi配置相关：

/usr/local/nginx/fastcgi_params

/usr/local/nginx/ scgi_params

/usr/local/nginx/ uwsgi_params

日志目录

访问日志：

/var/log/nginx/[业务英文标识]- access.log;

错误日志：

/var/log/nginx/[业务英文标识]-error.log;

n 安全规范

消除目录浏览漏洞

nginx默认不允许目录浏览，请检查目录浏览的相关配置，确保没有目录浏览漏洞。

检查各个配置文件，确保autoindex的配置为off。

目录安全配置

网站web目录和文件的属主与nginx启动用户不同，防止网站被黑客恶意篡改和删除。网站web目录和文件的属主可以设置为root等（非nginx启动用户）。

Web目录权限统一设置为755，web文件权限统一设置为644。只有上传目录等需要可读可写权限的目录可以设置为777.

管理目录安全配置

对于管理目录，需要做到只允许合法ip可以访问，nginx限制白名单ip访问的配置日下：

location ~ ^/private/ {

allow 192.168.1.0/24;

deny all;

}

删除默认页面

删除nginx默认首页index.html，业务可以自行创建默认首页代替之.

隐藏nginx版本信息

攻击者在信息收集时候无法判断程序版本，增加防御系数。

打开配置文件（例如nginx.conf） 隐藏版本设置 Server_tokens off;

禁用非必要的请求方法

trace请求用于网络诊断，会暴露信息，只允许GET、HEAD、POST请求，其他请求直接返回444状态码 （444是Nginx定义的响应状态码，会立即断开连接，没有响应正文，TRACE请求nginx内置405拒绝）

if ($request_method !~ ^(GET|HEAD|POST)$ ) {

return 444;

}

X-powered-by 隐藏信息

nginx反向代理配置很多站点，主机信息会被泄露，因此我们需要隐藏信息，配置在http区段：

proxy_hide_header X-Powered-By;

fastcgi_hide_header X-Powered-By;

2.2.3 备份

每天晚上12点左右对Nginx主目录做全量备份，文件备份至少2个物理服务器。

2.2.4 资源管理

Nginx监控以下指标任意一个超过阈值需要考虑扩容：

- 网卡流量占用率超过50%。

- WA（IO等待所占用的CPU时间的百分比）超过30%。

- CPU使用率超过80%。

- 内存使用率超过80。

3 数据库

3.1 腾讯云数据库Redis

3.1.1 使用范围和条件

腾讯云数据库 Redis 是基于腾讯在分布式缓存领域多年技术沉淀，打造的一款高可用、高可靠的 Redis 服务平台。

适用于下面场景：

- 将配置、用户或者商品的基础资料、静态图片等缓存到Redis，提高读取性能。

- 大型秒杀活动，Redis支撑千万级高并发访问及数据一致性。

- 排行榜数据，Redis自带SortedSet数据类型帮助您对数据排序。

3.1.2 技术指标

版本

标准版：

兼容 Redis 4.0 版本的协议和命令，采用主从节点部署架构，提供数据持久化和备份，适用于对数据可靠性、可用性都有要求的场景。主节点提供日常服务访问，从节点提供 HA 高可用，当主节点发生故障，系统会自动切换至从节点，保证业务平稳运行。

标准版的性能最大支持10万 QPS，需要更高的 QPS 请选择集群版。

集群版：

基于社区版 Redis 4.0 打造的全新版本，采用分布式架构，支持垂直和水平的扩缩容，拥有高度的灵活性、可用性和高达千万级 QPS 的高性能。

集群版自动启动分片模式，通过将不同的 Key 分配到多个节点达到水平扩充系统性能的能力。

集群版使用限制：

集群版数据自动 Hash 分片，集群模式暂时不提供小于4GB的规格；

多DB相关命令（MOVE、SWAPDB）

数据备份相关命令（BGREWRITEAOF、BGSAVE、LASTSAVE）

系统操作相关命令（REPLCONF、SLAVEOF、SYNC/PSYNC）

跨 Slot 执行的命令。

对于QPS要求不高的业务建议使用标准版，开发和运维更方便。

副本数

副本数等于1时，Redis 提供数据主从实时热备，提供数据高可靠和高可用，HA 系统监测到节点故障后，会将请求切换到从节点，并且新增一个从节点加入到系统。

副本数大于1时，Redis 提供数据主从实时热备，并且提供从节点只读功能。

3.1.3 备份和恢复

支持数据的备份与恢复，云数据库后台服务会定期对实例的数据进行备份，备份进行的时间点可以在控制台进行配置，同时还可以在任意时刻执行手动备份。

支持以回档和克隆的方式恢复实例数据，提供在特定场景的数据恢复和克隆功能。

数据备份

云数据库 Redis 支持自动备份和手动备份，自动备份允许自定义备份时间窗口。

自动备份

云数据库后台服务会定期对实例的数据进行备份，备份周期可通过控制台的【备份与恢复】>【自动备份】查看和配置。

默认情况下会在每天的02:00-08:00期间进行一次全量数据备份，备份文件存储于COS 服务，您可以在云数据库 Redis 控制台的【备份与恢复】中看到每天的备份数据。

备份列表会展示实例的所有备份文件以及备份文件的信息。

手动备份

除系统后台定期的生成备份文件以外，您还可以通过云数据库 Redis 控制台进行手动备份，以满足您不同的需求，手动备份的文件将同样展示在控制台的备份列表中，您可以通过备份列表中的备份类型【手动备份】来区分系统自动备份和手动备份。

数据恢复

云数据库 Redis 支持基于备份文件来恢复数据，恢复数据支持两种方式：在原实例中恢复数据和通过克隆的方式将备份数据库恢复到一个新的实例中。

恢复实例

实例恢复将清空原有实例的数据，将指定的备份数据恢复到实例中，恢复期间实例不可访问。。

克隆实例

云数据库 Redis 集群版（社区）支持实例克隆功能，支持基于备份文件克隆一个完整的新实例，实例的数据和备份文件一致，您可以使用克隆功能来分析以往的数据，也可以通过修改 IP 的方式，交换克隆的新实例和原有实例的 IP 来达到回档的目的

3.1.4 资源管理

实际内存达到申请内存的70%是就要考虑加大内存或者拆分数据。

3.2 Redis

3.2.1 使用范围和条件

Redis是一个开源的、高性能的key-value数据库。很大程度补偿了memcached这类keyvalue存储的不足，在部分场合可以对关系数据库起到很好的补充作用。Redis可安装运行在SUSE和CENTOS操作系统上。

3.2.2 技术指标

相同类型的技术组件在不同系统中应保持路径的标准统一，为自动化运维提供必要的输入。

程序安装路径

/home/redis/

应用日志路径

/home/redis/log

日志名使用业务模块简称加端口.log命名。例如:redis-Account.log。

环境检查：

因Redis是由C语言实现的，所以操作系统需要安装gcc的glibc-2.11.1版本编辑器来进行编译。

注：集群部署环境中，每一台机器都需要安装redis。一台机器安装redis后，可以通过复制redis.conf配置文件使用多个端口来启动多个redis实例。

文件配置规范（以Redis主从版本为例）：

配置文件默认名称为redis.conf。

1) 端口号

可根据需要配置端口，默认6379，单机多实例下必须调整

2) 关闭持久化

redis作为缓存时不需要开启持久化，所以将以下三行注释掉

3) 指定日志输出文件

主实例读写验证：

就是验证通过主实例存储信息是否成功。

用redis-cli登录主Redis服务器,使用set命令放入一条测试数据，如下：

返回OK表示数据已成功存储。

然后我们使用get命令读取存入的测试数据

主从同步验证：

就是验证主实例存储的信息，从实例是否可以直接读取，比如我们在A机器主实例set一条数据，然后我们连接B机器从实例，进行读取。同理，针对集群中的每套主从实例进行以上的验证。

3.3 Elasticsearch

3.3.1 使用范围和条件

Elasticsearch是一个开源的、基于Lucene的搜索服务器。它提供了一个分布式的全文搜索引擎，基于RESTful web接口。

Elasticsearch适合的场景需要有以下一些特点：

- 不需要事务支持。

- 可以适应准实时的查询特点，注意ES不是实时查询的数据库。

- 需要支持多维度查询的场景，即需要在很多字段进行过滤，比如数十、数百甚至更大的字段中选择过滤。

- 需要支持庞大数据量的聚合、排序、统计的要求，但对并发请求要求不高。

- 需要支撑千万、甚至数百亿以上的数据查询。

3.3.2 技术指标

目录

Elasticsearch主目录

/usr/local/es

Elasticsearch配置文件

主配置文件：

/usr/local/es/config/elasticsearch.yml

日志配置文件：

/usr/local/es/config/logging.yml

日志目录（path.log）：/data/logs/es/

索引目录（path.data）：/data/es/

安装规范（以版本：6.3.0为例）

集群名（cluster name）：[分类名称]_[业务描述]

transport.tcp.port: 9300。如果是同一机器下配置多个节点，端口号不能用同一个，可9300、9301、9302等。（不建议部署同一机器）

http.port: 9200

用户：es。（不可使用root）

分片数：根据总数据大小，控制分片大小控制在 20GB 到 40GB 之间。

插件规范

head

head是的集群管理工具，它是完全由html5编写的独立网页程序，可以铜鼓哦插件集成到es。

bigdesk

bigdesk是Elasticsearch的一个集群监控工具，可以通过它来查看es集群的各种状态，如：cpu、内存使用情况、索引数据、搜索情况，http连接数等。

Smart Chinese Analysis Plugin

中文分词工具

3.3.3 备份

配置副本数： 2个。

每天定时对核心数据（由业务确认）进行冷备（调用REST接口）

3.3.5 资源管理

提前对各个业务的数据做容量限制。

节点存储使用超过磁盘大小的80% 需要申请扩容节点。

4 中间件

4.1 CMQ

4.1.1 使用范围和条件

腾讯云消息队列（Cloud Message Queue，CMQ）是一种分布式消息队列服务，它能够提供可靠的基于消息的异步通信机制。

在需要进行异步通信的应用情景中推荐使用CMQ。

4.1.2 技术指标

模型

队列模型

这里的队列与数据结构中定义的 Queue 有一定区别。数据结构中的队列严格按照 FIFO 操作，这里的分布式队列不会有严格的FIFO。这里的队列相当于一个高性能、高容量、高可靠的容器，可以生产消息投递进去，也可以把消息取出来消费。

队列模型主要是支持PULL模式，当服务端收到这条消息后什么也不做，只是等着 Consumer 主动到自己这里来读，即 Consumer 这里有一个“拉取”的动作。

主题模型

主题模型类似设计模式中的发布订阅模式，Topic 相当于发布消息的单位，Topic 下面的订阅者相当于观察者模式。

主题模型主要支持Push 模型，当 Producer 发出的消息到达后，服务端马上将这条消息投递给 Consumer。

4.1.3 备份

消息服务每条消息在返回给用户写成功之时就确保数据已被复制3份写到不同物理机上，并且后台数据复制机制能够保证任何一台物理机故障时其上的数据能够快速的做迁移，时刻保证用户数据3份 copy 可用。

4.1.4 资源管理

队列、主题默认每秒允许发送5000条消息，带宽20MB/s（带宽可以先调大，忽略带宽阈值影响）， 超过上述阈值会抛异常无法生产。建议发送消息条数超过60% 阈值时，申请提高每秒发送消息条数阈值。

4.2 CKafka

4.2.1 使用范围和条件

CKafka提供高吞吐性能、高可扩展性的消息队列服务，兼容Apache kafka 0.9版本接口。主要应用于下面场景：

- 大数据场景。适合处理海量的实时消息，并能汇总分布式应用的数据。能够很好地支持离线数据、流式数据的处理，并能够方便地进行数据聚合、分析等操作。

- 日志聚合。CKafka提供了低延迟处理、易于支持多个数据源和分布式的数据处理（消费）的特性。相比于中心化的日志聚合系统，CKafka实现更强的持久化保证以及更低的端到端延迟。

4.2.2 技术指标

实例创建

消息保留时长

用于定义队列中消息的删除机制，由于生产成功的消息会在CKafka实例中堆积，到达保留时间后才会被删除。如磁盘堆积打满则会导致生产失败。消息保留时间支持1分钟到7天（1-43200分钟），默认值为1天。

删除机制是按照 Ckafka 的分片批量删除的，不是立刻删除的，目前分片的大小是1G，如果分片不到1G 就不会删除，消息保留时长不能过短。一般配置1天，核心数据配置7天，低优先级数据配置1小时。

峰值带宽

峰值带宽设置取生产消息和消费消息的最大值，其中生产消息量要乘以副本个数。

Topic创建

分区数（partition）

通常建议 partition 的数量一定要大于等于消费者的数量来实现最大并发。 如果消费者数量是 5，则 partition 的数目也应该是 >=5 的。同时，过多的分区会导致生产吞吐的降低和选举耗时的增加，因此也不建议过多分区。提供如下信息供参考：

l 单个 partition 是可以实现消息的顺序写入的。

l 单个 partition 只能被同消费者组的单个消费者进程消费。

l 单个消费者进程可同时消费多个 partition，即 partition 限制了消费端的并发能力。

l partition 越多则失败后 leader 选举的耗时越长。

l offset 的粒度最细是在 partition 级别的，partition 越多，查询 offset 就越耗时。

l partition 的数量是可以动态增加的，只能增加不能减少。但增加会出现消息 rebalance 的情况。

副本数

目前为了保证可用性副本数必须大于等于 2，如果需要保障高可靠建议 3 副本。

副本数会影响生产/消费流量，如 3 副本则实际流量= 生产流量*3。

4.2.3 备份

Ckafka平台提供多副本跨物理设备容灾。

4.2.4 资源管理

磁盘

磁盘使用超过分配的80% 需要申请调整磁盘大小。

带宽

带宽是分别计算生产带宽和消费带宽，例如实例申请的带宽为100MB/s， 则生产带宽为100MB/s ，消费带宽为100MB/s 。

生产流量需要考虑副本，例如申请的带宽为100MB/s , 主题双副本，则真实的流量阈值为100MB/s / 2 = 50MB/s 当生产流量超过该阈值80% 则需要调整实例带宽。

消费流量不用考虑副本，例如申请的带宽为100MB/s， 当消费流量超过阈值80%（80MB/s） 则需要调整实例带宽。

生产、消费流量任一超过阈值则需要调整实例带宽。