腾讯云项目实践: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 条评论
登录 后参与评论

相关文章

来自专栏SDNLAB

漫谈虚拟路由方案

前言——关于虚拟路由 SDN,抑或是OpenFlow,能否为路由市场开辟一个新的时代?以OpenvSwitch为代表的开源软件交换机,已经推动SDN界发展了一段...

3455
来自专栏北京马哥教育

关于泰捷商城项目与如何做一个高可用的网站

hi 各位, 上两周一直都在做泰捷商城这个项目。这个项目的目的就是卖泰捷出品的WEBOX。这是我第一次做有关电子商务的网站。各种头绪。其实原始需求很简单,只卖一...

35412
来自专栏Golang语言社区

优酷、YouTube、Twitter及JustinTV几个视频网站的架构

优酷视频网站架构 一、网站基本数据概览 据2010年统计,优酷网日均独立访问人数(uv)达到了8900万,日均访问量(pv)更是达到了17亿,优酷凭借这一数据成...

6237
来自专栏Java架构

十年资深架构师告诉Java程序员成为架构师必须要掌握的知识点一、分布式架构二、工程化专题三、微服务架构四、性能优化五、源码分析六、项目实战

2234
来自专栏PHP在线

说说大型高并发高负载网站的系统架构

转自:Just Do IT (http://www.toplee.com) 我在Cernet做过拨号接入平台的搭建,而后在 Yahoo3721负载搜索引擎前端平...

3225
来自专栏大数据文摘

Hadoop如何通过IT审计(下)?

2687
来自专栏全华班

如何实现一个优质的微服务框架

摘要: 一个优质的微服务框架需要考虑的要素众多,在满足微服务设计理念的前提下,也是一个不断实践优化的过程。 本文讲述了整个 开源微服务框架 Apache Ser...

1714
来自专栏架构师之路

YouTube系统架构【YouTube如此,你应该更有信心】

上一期,和大家分享了12306架构优化思路,本期讲和大家分享YouTube架构设计,阅读了本文你将了解到YouTube初期架构是个什么样子,以此,增强自己站点架...

5936
来自专栏韩伟的专栏

经典软件架构模式

目录 (一) 架构模式是什么 (二) 分层模式案例 (三) 微核模式案例 (四) 管道与过滤器案例 (五) MVC模式案例 (六) REST模式案例 (七) S...

3665
来自专栏性能与架构

Hotjar在架构演进中总结的8条经验

Hotjar 提供了帮网站主了解用户行为的服务,网站接上此服务后,可以生成用户的点击热区,录制用户的行为,查看各个页面的跳出路径以及停留时间等,根据这些统计数据...

3416

扫码关注云+社区