腾讯云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内存消耗这些系统层面指标。对于产品来说可能是要看点击率、pv、uv 等业务指标的变化。这些都可以在PaaS控制台以图表的方式展现出来，方便对下一步灰度做出决策。
完备的日志与监控系统，助力企业智能运维
完善的统计监控与日志系统是一个PaaS平台最基础的能力，没有之一。TSF的监控与日志系统底层采用EFK(ES+ Filebeat+Kinana)方案搭建而成，监控数据维度主要分为以下几类：
- a.访问量：请求数、成功数、失败数、成功百分比、同比环比波动百分比
- b.响应包大小、响应延时
- c.机器负载：CPU、内存、读写磁盘、TCP连接数、出入流量、出入包量
- d.进程监控
其中前两类采集频率是分钟级别的，机器负载和进程类的监控是秒级的，各个业务可以根据实际需要进行个性化配置。
上述以“监”，在“控”方面，支持字符串类型的微信、短信、邮件告警，另一方面支持如下图所示的曲线告警，用户可以根据需要来配置触发告警条件。
同时TSF 后台也会根据历史上报数据和告警策略进行大数据分析对比，进行智能运维。
图：统计监控示意图
不断整合创新，打造TSF强大分布式作业能力
TSF PaaS平台的分布式作业系统是基于Quartz开发而来的，充分继承了Quartz强大的调度功能和丰富多样的调度方法，以及其分布式集群能力。
通过TSF 分布式作业管控平台不仅可以完成所有的运维操作，还可以自动选取负载较低节点来下发计算任务，充分利用设备资源。除此之外所有作业的执行详细情况都可以在控制台进行查询，从下图可以看出目前分布式作业平台一天大约执行几十万个任务。
图：分布式作业示意图
总结：
本文针对腾讯内部接入TSF平台的业务在日常运营过程中重点关注的几个核心功能点来介绍了TSF平台服务生命周期管理部分的核心能力，如想进一步了解实习技术细节欢迎进一步交流。
