APISIX 金丝雀发布实践
背景Apache APISIX 是 Apache 软件基金会下的云原生 API 网关，由 API7.ai 开发并捐赠，基于 NGINX + ngx_lua 构建，提供了动态路由、动态上游、动态证书、A/B 测试、灰度发布（金丝雀发布）、蓝绿部署、限速、防攻击、收集指标、监控报警、可观测、服务治理等功能。 具体的介绍可以查阅 APISIX 文档。 由于 Nginx reload 存在网络抖动，并且随着业务路由增加，nginx 配置维护十分困难。根据 APISIX 的官方介绍，这些问题得到解决。因此，我们尝试引入 APISIX 作为云原生网关，实现 A/B 测试、金丝雀发布等功能。 目标引入 APISIX 代替 Nginx 网关，简化生产运维操作。 部署为方便维护，使用官方提供的 Helm 脚本部署 APISIX 网关，代码片段如下。 123helm repo add apisix https://charts.apiseven.comhelm repo updatehelm install apisix apisix/apisix --create-names...
Prometheus 动态获取 Pod 监控数据改造
背景Spring Boot Actuator 提供了一个监控和管理生产环境的端点，可以查看应用的运行状态。由于运维人员对 Prometheus 和 Grafana 的配置不是很熟悉，使用静态 IP 来获取监控数据，并且从 Grafana 模板市场获取的 Dashboard 不能较好的区分运行环境。 目标使用 Prometheus 服务发现动态获取 Pod 的监控数据，支持 K8s 运行环境筛选监控数据。 实现引入 Prometheus 依赖123456789101112131415161718192021222324<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> <exclusions> <exclusion> <artifactId>spring-boot-s...
CODING 云原生应用交付实践
背景我们引入了腾讯云 CODING 作为新项目的构建方式，践行了 DevOps 研发运营一体化的理念。 在使用的过程中，我们也发现持续集成这块功能，不能满足我们一些场景。 可视化编排只支持镜像更新，不支持镜像部署，需要手动写 kubectl apply 实现，对于研发人员来说，不够傻瓜化。 部署人员对 Kubernetes 云原生环境不熟悉，例如 Deployment、Service、ConfigMap 等资源。 在生产发布场景，不支持批量发布，没有完善的生产发布流程，缺乏上线留痕和回滚机制。 上述的问题其实就是 OAM 要解决的目标。 OAM（Open Application Model）是阿里巴巴和微软共同开源的云原生应用规范模型，构建于 GitOps 基础上。对于 OAM 来说，基础设施即代码，一些代码都可以基于 Git 版本控制。稍微用过 Kubernetes 的伙伴可以知道，Kubernetes 的资源变更基本都是 kubectl apply YAML 文件 调用 API 实现。OAM 的本质就是把 YAML 文件放到 Git 管理，并根据研发团队和运维团队的视角，...
服务器高可用恢复演练报告
概述背景介绍根据《服务器高可用恢复演练方案》文档介绍，验证基于 CLB 负载均衡下部署多台 CVM 的高可用。 目标要求通过混沌演练故障注入，验证 A 系统的 RPO 不超过 4 小时，RTO 不超过 12 小时。 实施人员* 演练实施组：小D* 业务验证组：小E、小F 测试对象A 系统的 prd1 生产环境 操作时间2023-06-25 15:00 ~ 18:00 记录Linux内核故障恢复演练故障模拟在 prd1 服务器节点注入Linux内核故障。 控制台显示 “执行中”。 等待执行完成后，我们连接这台服务器的 ssh 会话自动退出，说明故障注入已生效。 过程记录Linux 内核故障注入总共持续了 30 分钟，表现如下：持续访问生产环境，出现短暂几秒的接口报错。在 CLB 探测 prd1 环境端口异常之后，访问生产环境的接口不再出现报错。 短信收到系统告警，提示 prd1 服务器异常。 关闭故障注入，重启 prd1 服务器后，ssh 登录 prd1 服务器成功，但发现应用进程已经停止，没有再次启动，需要手动重启。 结果验证 首次故障注入后，业务接口出现短暂的报错，CLB...
服务器高可用恢复演练方案
概述演练目的由于历史原因，A 系统存在部分项目使用 CVM 作为运行环境。尽管腾讯云方承诺单实例服务的可用性达到 99.975%，但遇到 Linux 内核故障、CPU 或内存的使用率过高等问题，仍然会导致系统不可用。为避免业务中断，使用腾讯云 CLB 作为负载均衡，管理和分流至少 3 台以上的 CVM 实例，实现高可用。 目标要求通过混沌演练故障注入，验证 A 系统当前的部署架构具备自愈能力，对业务的影响在可接受范围，满足金融行业IT系统容灾标准，灾难恢复能力达到国家标准等级 4 级以上，即 RPO 不超过 4 小时，RTO 不超过 12 小时。 名词解释 名词 解释 RPO 恢复点目标（Recovery Point Object，简称 RPO）。指灾难发生后，容灾系统进行数据恢复，恢复得来的数据所对应的时间点。 RTO 恢复时间目标（Recovery Time Object，简称 RTO）。指灾难发生后，从 IT系统宕机导致业务停顿之刻开始，到 IT 系统恢复至可以支持各部门运作，业务恢复运营之间的时间段。 CVM 云服务器（Cloud Virtual Mac...
Linux 执行 tar 命令处理大文件引发线上问题
问题描述最近我们生产环境的几个系统出现了很诡异的现象，每天晚上 21 点之后出现短暂的报错，或者响应超时。 例如，系统 A 在 21 点弹出微信预警，提示接口访问异常。 系统 B 在 21 点弹出钉钉预警，提示网关探测异常。 一开始我们怀疑是数据库、代码、xxl-job 等问题，但是这些想法很快就否决了。 各系统分别独立部署在腾讯云的 EKS 弹性集群，互不干扰。 各系统使用的数据库和 xxljob 都是分开的。 我们通过回退代码版本检查，也排除了这些系统近期的代码更新问题。 原因分析经过时间线整理，各系统发生故障的时间点基本是同时触发的，如下。 时间范围 系统A 微信预警 系统B 钉钉预警 其他系统 2023-03-15 20:58-21:00 20:59:13 推送 499 访问异常 21:03 提示 APISIX 探测异常 … 2023-03-16 21:03-21:06 21:03:04 推送 499 访问异常 21:03 提示 APISIX 探测异常 … 2023-03-20 21:19-21:23 21:19:34 推送 499 访问异常 ...
Elasticsearch 深度分页查询问题处理方案
背景在 Elasticsearch 中，分页查询是常见的需求，尤其是在处理大量数据时。为了提高查询效率，Elasticsearch 提供了多种分页方案，适用于不同的场景。笔者根据实际的使用情况整理了相关方案。 方案Elasticsearch 分页查询方式主要有如下 3 种，现给出结论。 查询方案 用法限制 适用场景 from+size 查询 支持随机跳转不同分页，不超过 max_result_window 值 小数据范围查询 search_after 查询 仅支持向后翻页，可以超过 max_result_window 值 APP向下滑动查看新闻 scroll 查询 大数据量分页查询，但数据实时性不高 批量大数据、日志导出 from+size 小数据范围查询from 参数指定从结果集中的第几条数据开始返回数据，size 参数指定返回数据的总量。假设我们有一个索引 my_index，并希望查询名字为 “梦想歌” 的文档，且返回 10 条数据。可以使用如下查询： 12345678910GET my_index/_search{ "from&...
Elasticsearch 文档版本冲突处理方案
背景使用 _update_by_query 批量更新或者 _delete_by_query 批量删除，刚好有个 _bulk 批量写入，并且 _bulk 的执行更快，导致批量更新或者批量删除的版本比写入的版本要低，造成版本冲突报错。 方案以下提供两种方式避免版本冲突：一是使用 version=版本号&version_type=external 外部控制，二是 if_seq_no 和 if_primary_term 参数控制。 基于 external 外部模式将 version 的控制权交由客户端管理。 例如，更新 my_index 索引。 1PUT my_index/_doc/233?version=2&version_type=external 当给定的 version=2，大于当前版本 version=1，执行更新或索引操作成功。 使用 if_seq_no 和 if_primary_term 参数控制在更新索引之前先查询 if_seq_no 和 if_primary_term 这两个参数，然后传入更新指令。 例如，更新 my_index 索...
Elasticsearch 索引备份与恢复方案
背景有时候需要对 Elasticsearch 集群进行备份，或者恢复到其他集群。 方案以下提供两种方案：使用 Elasticsearch 自带的 SNAPSHOT 快照机制，或者利用 elasticsearch-dump 工具完成。 使用快照与恢复功能将索引数据备份到其他文件存储，恢复时先恢复快照，再恢复索引。 在 elasticsearch.yaml 配置快照存储路径。 1path.repo: ["/path/to/snapshot"] 注册快照存储库。 1234567PUT /_snapshot/my_backup{ "type": "fs", "settings": { "location": "/path/to/snapshot" }} 创建快照。 1234567891011121314# 全量备份PUT /_snapshot/my_backup/snapshot_cluster?wait_for_...
Elasticsearch 索引零停机变更方案
背景在对外提供服务的线上环境中，发现 Elasticsearch 集群中核心业务涉及的索引设计不合理，需要做数据迁移，但不允许重启服务。 方案使用 Alias 别名对外提供服务。 新建索引并设定好 Mapping，然后进行数据 reindex 迁移操作。 例如，设置索引 my_index 的 Alias 别名为 my_index_alias。 1234567891011PUT my_index{ "aliases": { "my_index_alias": {} }, "settings": { "refresh_interval": "30s", "number_of_shards": 1, "number_of_replicas": 0 }} 创建新索引 my_index_v2...
