腾讯云 TSF 是整合外部开源框架和腾讯内部历经多年锤炼的 PaaS 平台打造而成的企业级分布式应用服务开发与托管平台, 本文重点对 TSF 中负责服务托管的 PaaS 平台进行揭秘, 从技术角度解析 TSF 平台是如何每天应对万亿次调用的服务托管与治理
简介:
腾讯云 TSF 是整合外部开源框架和腾讯内部历经多年锤炼的 PaaS 平台打造而成的企业级分布式应用服务开发与托管平台, 本文重点对 TSF 中负责服务托管的 PaaS 平台进行揭秘, 从技术角度解析 TSF 平台是如何每天应对万亿次调用的服务托管与治理
TSF PaaS 平台的前身是 CAE(Cloud App Engine), 其核心架构是参考 Cloud Foundry 设计研发的为了给开发者提供更加便捷的服务, TSF 和公司很多基础服务打通, 例如腾讯网关 TGW 名字服务 L5 内部鉴权服务以及消息队列等, 使得用户可以在 TSF 平台完成一站式开发上线托管服务; 除此之外还支持对托管在平台上的应用进行健康检查进程监控日志汇聚展示等服务让开发者只需关心自己应用代码, 而其它一切事情, 都由平台为其提供, 极大地提高了开发者的效率, 降低了运维成本下图简要描述了 PaaS 平台和不同角色用户之间的关系
整体架构示意图
核心能力介绍:
目前腾讯内部有上万个应用托管在 TSF PaaS 平台, 这些应用每天的请求量超过万亿次下面对 TSF PaaS 平台的所解决的问题及核心能力分别展开介绍
弹性扩展能力
在公司众多的互联网业务中, 往往有这样的一些业务场景, 海量用户突然同时去访问一组服务, 如限时抢购秒杀活动, 或者游戏整点开服, tips 弹窗都会触发用户的此类行为服务器经常会面临在短时间涌入大量请求, 快速的吃掉 CPU 和内存, 造成服务器瘫痪, 前端用户进一步重试, 导致雪崩现象加剧因此在一些非常重要的业务搞活动的时候, 需要运维事先准备好大量的机器 (预估值要远远大于可能实际值), 部署好程序, 等待活动的到来如果有一套自动伸缩机制, 活动时可以自动扩容, 不需要时可以很方便的下线, 整个运营将简单很多, 弹性伸缩能力是 PaaS 平台的基础能力之一, TSF 根据公司内部不同业务需求场景提供多种方式的弹性规则:
规则一: 可以对应用所在节点在一定时间内的物理负载情况请求量延时返回错误码等多维度进行配置规则, 一旦触发弹性条件, 平台将自动进行相应扩缩容操作
规则二: 对于请求量有周期性波峰波谷规律的应用, 可以配置定时弹性伸缩, 入下图所示
图: 定时扩缩容规则
无论是动态伸缩还是定时伸缩, 其后台实现原理是类似的, 整体调度架构如下,
图: 弹性伸缩模块示意图
配置系统: 用户在控制台根据业务情况, 设置弹性伸缩触发规则, 规则包括以下几个维度:
采样间隔: 1~60s, 可任意配置, 平台具备秒级别采集数据的能力配置规则中需要制定连续高负载次数, 服务自动扩容首要条件就是服务分组下至少存在一个实例连续上报几次上报高负载数据同时还要配置冷却时间, 在冷却时间平台会忽略实例高负载信息, 这样可避免在扩容还没完成期间, 再次触发扩容配置规则中的性能指标, 包括 CPU 内存磁盘网卡流量 TCP 连接数请求量错误比例延时大小等的维度
通知中心: 负责对外推送的模块高负载信息及扩容决策信息
流程系统: 通知中心收到信息后, 触发自动扩容流程, 包括资源部署, 程序包安装, 配置下发等
弹性伸缩能力在微信红包诞生的那个春节发挥到了极致, 2014 年春节微信红包出乎所有人的意料一夜之前红遍大江南北, 每一秒钟都有大量用户涌入, TSF 根据事先配置的规则, 自动弹性扩展, 成功支撑了突入起来的海量请求为微信红包初期的发展赢得了宝贵的时间, 下图为自动扩容任务列表, 可以看到同一个服务在短时间内自动触发了很多次扩容操作, 大大减轻了运维压力, 真正达到了无人值守
图: 弹性伸缩任务查询列表
灰度发布, 流量控制能力
TSF 平台可以完成对应用整个生命周期的管理, 从代码开发到 CI/CD 再到版本的升级与回退在新功能上线过程中通常需要一个灰度过程来控制能访问到新版本的流量比重, 如果发现了异常问题需要及时回滚到稳定版本另外, 灰度发布并不是短暂的过程, 可能会持续很久例如某个重大的框架或者系统更新可能会持续很久, 有可能整个服务在几个月内都是新旧并存, 甚至有可能需要两个版本分别各自迭代而从产品的角度来看可能就会更灵活, 很有可能线上有五六个方案都在收集数据, 每天有了一些新想法都要上一些小版本看效果, 每个版本上线后可能都要再各自做优化调整观察效果这种情况可能线上就永远不会有一个统一的版本灰度反而是个常态来应对不断变化的需求和挑战
TSF 灰度发布系统包括以下两个方面
精确的流量分发控制: 从运维风险控制的角度, 需要把受影响的流量控制在一个精确的范围内, 在上线前就知道哪部分用户会有问题, 而不是真出问题谁受到影响都不知道一个常见场景是新版本只让公司内部的员工能访问到, 再一个市一个省的一点点推上去 TSF 灰度发布系统可以对应用实例进行分组操作, 新版本按照分组来灰度发布, 将一部分流量导入灰度分组, 观察是否符合预期, 具体导入那部分流量可以是公司内部员工, 也可以按照其他维度来切分
监控系统的支撑: 流量精确分配只是第一步, 接下来更重要的是获得多个版本的关键指标对运维来说可能是看错误率吞吐量延迟 CPU 内存消耗这些系统层面指标对于产品来说可能是要看点击率 pvuv 等业务指标的变化这些都可以在 PaaS 控制台以图表的方式展现出来, 方便对下一步灰度做出决策
完备的日志与监控系统
完善的统计监控与日志系统是一个 PaaS 平台最基础的能力, 没有之一 TSF 的监控与日志系统底层采用 EFK(ES+ Filebeat+Kinana) 方案搭建而成, 监控数据维度主要分为以下几类:
a. 访问量: 请求数成功数失败数成功百分比同比环比波动百分比
b. 响应包大小响应延时
c. 机器负载: CPU 内存读写磁盘 TCP 连接数出入流量出入包量
d. 进程监控
其中前两类采集频率是分钟级别的, 机器负载和进程类的监控是秒级的, 各个业务可以根据实际需要进行个性化配置
上述以监, 在控方面, 支持字符串类型的微信短信邮件告警, 另一方面支持如下图所示的曲线告警, 用户可以根据需要来配置触发告警条件
同时 TSF 后台也会根据历史上报数据和告警策略进行大数据分析对比, 进行智能运维
图: 统计监控示意图
分布式作业能力
TSF PaaS 平台的分布式作业系统是基于 Quartz 开发而来的, 充分继承了 Quartz 强大的调度功能和丰富多样的调度方法, 以及其分布式集群能力
通过 TSF 分布式作业管控平台不仅可以完成所有的运维操作, 还可以自动选取负载较低节点来下发计算任务, 充分利用设备资源除此之外所有作业的执行详细情况都可以在控制台进行查询, 从下图可以看出目前分布式作业平台一天大约执行几十万个任务
图: 分布式作业示意图
总结:
本文针对腾讯内部接入 TSF 平台的业务在日常运营过程中重点关注的几个核心功能点来介绍了 TSF 平台服务生命周期管理部分的核心能力, 如想进一步了解实习技术细节欢迎进一步交流
来源: https://cloud.tencent.com/developer/article/1070122