腾讯云项目实践:App 性能监控方案

什么是 App 性能监控方案 ?

App 性能监控方案(APM) 是将 App 产生的性能数据上报及处理和分析, 提供适度加工的数据, 平台及合适的方法协助应用发现对用户影响最大的性能问题, 并且用累积数据一步步回归验证, 最终使应用数据上报, 数据存储与分析, 报表及邮件推送, Bug 产生及回归验证, 行业经验沉淀成为一个完整的闭环, 使应用的性能可以得到持续的监控与提升。

> 哇, 好正式的开场啊, 稳!

为什么要使用腾讯云(相比于传统机房) ?

  • 降低运维成本, 将精力集中于构建上层业务. 曾经一段时间, 后台的维护与开发耗时比例高达 1:1
  • 可更快速的扩容, 大部分云上资源都可以即时分配
  • 更好的支持独立部署和成本核算, 毕竟后台需要使用大量的计算资源, 最后的产生的成本需要接入的产品共同承担
  • 大部分腾讯云服务都会有监控告警能力,而自建服务还是需要大量精力用来构建这方面的能力

> 哇, 好有说服力的原因啊, 稳!

那么,一张图说清楚后台架构

Entrance (golang) 是一个供SDK上报的后台服务, 用以接收客户端的上报请求并将数据存储到kafka, 并将大文件落地到Cos文件存储服务。

Kafka 集群用以缓解数据峰值带来的压力,并且作为数据中转站,为各个模块进行解耦。

Transporter (golang) 是主要的后台, 作为kafka的主要Consumer, 将用户上报的数据存储到TDF进行数据计算,另外有一些需要分析的数据会发送到独立的模块进行分析。

Web (python) 是项目的Web服务, 主要提供数据展示及交互, 产品及邮件配置等。

腾讯云使用资源清单

服务

用途

优势/不足

容器服务

容器编排

底层使用k8s,业界主流发展方向。服务内置Ingress与腾讯云负载均衡服务无缝衔接

TDF

大数据计算

华丽的前台界面,即使小白也可以轻松构建数据工作流 (缺点: 目前还没有自动化配置方案)

COS

数据存储

目前腾讯云最稳定的海量存储方案 (缺点: 目前还没有golang客户端, 我们是自己开发的)

CDN

App配置下发

服务稳定,时延低,新手使用的话,“自助故障诊断”功能很好用

Postgres

关系型数据存储

数据类型丰富,例如 ARRAY,JSON 有丰富的PG插件 (缺点: 目前在单表过十亿条的场景, 性能不如分布式数据库)

Redis

KV存储

服务带宽真心高 (我们单机Redis带宽可达 400Mb 以上)

云文件存储

云文件存储

对于云文件场景, CFS在腾讯云的唯一可选项。且CFS可与容器服务PV无缝结合

腾讯云服务在项目应用的细节

  1. 腾讯云容器服务,后台所有容器均依赖容器服务运行
  1. 腾讯云 Redis, 用于加速Android和iOS堆栈的翻译速度
  2. 腾讯云 Postgres 数据库,用于结果表的存储及产品配置
  3. 腾讯云 COS 服务,用于文件存储
  4. 腾讯云 CDN 服务,用于App配置下发
  1. 腾讯云 TDF 用于定时计算指标数据并出库到Postgres, 供页面展示

CASE1: 使用 "腾讯云容器服务"

建立集群

Step 1 编辑集群信息

Step 2 选择容器宿主机配置

Step 3 最后的一些琐事

运行服务

说到运行服务,不得不提到有两种方式,适合于不同场景

1) 通过腾讯云控制台创建服务

> 适用于新手用户,简单快捷,覆盖到了常用功能

2) 通过 kubectl 命令行工具创建服务

> 适用于进阶用户,解锁全部K8s服务能力,例如Statuful Sets,Cronjob等等,并且服务配置可纳入版本管理系统

  • 登陆任意一台集群内主机即可使用 kubectl 命令行
  • source <(kubectl completion bash) 可为kubectl设置命令行自动补全
  • kubectl 只要附带了证书信息,是不必非要在腾讯云主机才能操作,详见下面文档

腾讯云容器服务官方文档相关操作的描述已经很详细了 https://www.qcloud.com/document/product/457/8438

使用负载均衡暴露服务

说到负载均衡,不得不提到有两种方式,适合于不同场景 ~

1) 通过腾讯云控制台创建负载均衡

> 适用于新手用户,简单快捷,覆盖到了常用功能

网页操作比较简单,这里不在细说。 可参考腾讯云容器负载均衡官方文档: https://www.qcloud.com/document/product/457/9110

1) 通过 kubectl 命令行创建负载均衡

> 适用于进阶用户,可将负载均衡配置纳入版本管理系统 (关于负载均衡的详细配置,例如检测周期等,需要在控制台配置)

这部分内容较多,详情请参阅Google官方文档: https://kubernetes.io/docs/concepts/services-networking/ingress/

CASE2: 使用 "腾讯云TDF"

基本配置

  1. 申请权限 https://www.qcloud.com/product/tdf
  2. 创建表,这里建议大家使用HQL创建,并且把HQL放到版本管理系统中。
  1. 腾讯云 CDP 配置接入层的Topic(DataPipeline正在内测, 只对白名单用户开放)
  1. 腾讯云 CDP 配置接入层的Integrator

数据入库

数据入库的流程稍微复杂些,解释一下:

  1. 首先我们应该编写一个Flume配置,可以配置Flume的Source为一个csv文件,看起来像这样的
  1. 配置里面有一个声明文件路径的地方,写一个自定义路径。可以将数据写入到这个数据,Flume会将里面的文件自动上报到云端后台
  2. 写入数据到CSV文件,这里要注意字段的顺序需要和CDP配置Topic保持严格一致

数据出库

  • 配置出库数据库
  • 编写 TDF 工作流
  • 启动工作流,就可以丢下鼠标等胜利啦!

关于后台构建,有啥重点么?

整个数据处理流程十分简单, 只有接入层(Entrance), 缓冲层(Kafka), 处理层(Translate,Transporter), 用户交互层(Db,Web)

为什么呢 ? 保持简单很重要, 一个系统走到尽头的原因通常都是拥有了无数个无关痛痒的功能而最终导致代码臃肿不堪, 最终迎来一次彻底的重构。这也是项目迁移到腾讯云的重要原因之一, 以为已经太过臃肿, 需要一次换血。所以说: 系统的架构图就不会使用下面这样的 ...

任意两个模块间无直接CGI交互, 全部通过 kafka 以 Producer/Consumer 的关系进行数据传递

为什么呢 ? Kafka 拥有很高的水平扩容能力, 如果后台模块间无直接耦合, 那么水平扩容所需做的仅仅是增加业务容器个数和Kafka集群规模即可啦

绝对, 绝对不要更改字段的值或者删除字段

为什么呢 ? 遵守上面的原则便可维护数据不可变性。在海量数据下, 可以保证数据容忍重复消费, 数据回滚等操作, 因为数据回滚需要做的事情仅仅是删除几个字段然后把数据重新放回Kafka队列.

一个字段在客户端, 后台, 数据库, 前端都只能有一个名字

为什么呢 ? 说出来都是泪,这个还是要具体经历过字段混乱带来的灾难后才可以体会。。。

Kubernerts 做好健康检查很重要

为什么呢 ? 这不就使用 Kubernetes + Docker 的原因么?希望发现异常使通过重启容器,解决大部分运行时问题,提升服务可用性。所以,要花力气检查好容器是否是正常工作才可以团建时候不被工单电话骚扰呀 ^^

但是究竟有哪些点, 自己项目和腾讯云都获得了成长 ?

近代著名思想家孔子日: 双赢是最佳实践的入场券

  • 在使用腾讯云, 可以在低资源成本下(不到1W经费), 使我们快速搭建项目的原型, 并得到现网环境的验证 | 关键字: 低成本 快速验证
  • 在我们的使用过程中, 遇到的Bug或者体验问题, 及时反馈给了腾讯云同学, 并快速得到了解决 | 关键字: 合作 改进
  • 项目作为基础服务, 支持独立部署后, 可作为平台能力, 为腾讯云带来更多潜在用户 | 关键字: 共同利益 发展

> 上面的标准式回答真的是太假了, 能不能来些足够感性的栗子 ?

  • 腾讯云的 TDF 服务在使用初期, 事实上处于内测阶段, 会不时出现任务失败的情况,所以会经常反馈问题。

对话风格由 @鲁班: TDF今天任务又失败啦, 帮忙看下原因哈 [鲜花.gif] 变成了 @我: 你们业务今天有任务跑失败啦, 是不是最近改了任务配置呢 ?

这是TDF系统后台监控越来越完善的例子有米有 !! | 关键字: 先于用户发现问题

  • 在使用过过程中, 遇到了腾讯云COS缺少Golang客户端的问题, 在进度压力下, 我们开发了golang cos 客户端并在后续版本与腾讯云共同维护 | 关键字: 共同承担
  • 在使用 TDF 的 Flume 插件上报数据时, 会偶尔出现进程因为网络不稳定退出的问题. 我们把TDF 的Flume插件Docker化后, 由Kubernetes做健康检查来维持进程存活并将方案同步给了腾讯云的同学, 腾讯云的同学积极响应, 并在两天内完成了Flume插件稳定性的提升工作 | 关键字: 互相督促

如果有腾讯云流式数据处理或者APM能力建设相关的问题或者经验,欢迎在本文留言一起讨论。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

田小康的专栏

1 篇文章1 人订阅

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏xingoo, 一个梦想做发明家的程序员

Oracle基础知识-数据迁移

我们常需要对Oracle数据库进行迁移,迁移到更加高级的主机上、迁移到远程的机房上、迁移到不同的平台下 一、exp/imp:  这也算是最常用最简单的方法了,一...

1938
来自专栏Albert陈凯

2018-06-07 小团队的自动化运维实践经验翟志军一些小团队的自动化运维实践经验

1853
来自专栏云计算

OpenShift的容器镜像(第1部分):目标

本文来源于2017 EMEA (Europe, the Middle East and Africa,欧洲,中东和非洲) 红帽技术交流会议的会议记录,与会者包括...

1966
来自专栏大魏分享(微信公众号:david-share)

打通CI/CD任督二脉的关键技术点在哪?

CI/CD(工具)界的扛把子 大家都说CI/CD,他们的目的到底是什么? 持续集成的目的,在保证高质量的基础上,就是让产品可以快速迭代。它的核心措施是,代码集成...

3546
来自专栏NetCore

Windows 7 初体验

用了10个小时下载windos 7 build版本,再用了2个小时安装了windows 7,在盼望中正式开始接触了,我也“潮”了一次 研究了1个小时,实在太累了...

1989
来自专栏北京马哥教育

我的linux运维日记,比较下学习与工作。

从事运维一年半,遇到过各式各样的问题,数据丢失,网站挂马,误删数据库文件,黑客攻击等各类问题,今天想简单整理一下,主要有以下几点: 1.线上操作规范 测试使用 ...

2747
来自专栏喵了个咪的博客空间

Kubernetes(一) - Docker管理工具

1053
来自专栏北京马哥教育

做Linux背锅2年,我总结了这六类好习惯和30个血的教训

一、线上操作规范 1.测试使用 当初学习Linux的使用,从基础到服务到集群,都是在虚拟机做的,虽然老师告诉我们跟真机没有什么差别,可是对真实环境的渴望日渐上升...

37112
来自专栏SDNLAB

分层安全用于通用客户端设备(uCPE)部署的准则

1275
来自专栏FreeBuf

如何使用PowerShell实现命令控制以及安全检查绕过

Windows操作系统在全球市场上的占比是大家有目共睹的,而现代Windows平台都默认安装了PowerShell,而且系统管理员还可以毫无限制地访问和使用Po...

2407

扫码关注云+社区