经过六年的迭代与沉淀，腾讯Tencent Server Web (以下简称TSW)这一公司级运维组件于今日正式开源。TSW是面向WEB前端开发者，以提升问题定位效率为初衷，提供云抓包、全息日志和异常发现的Node.js基础设施。TSW每天为百亿次请求提供稳定服务，广泛应用在QQ空间、微视、微云、QQ音乐、全民K歌、腾讯云等三十多个重要业务当中。
官方网站：https://tswjs.org
Github开源地址：https://github.com/Tencent/TSW
云抓包
TSW支持用户维度的抓包
对于染色的用户 对请求生命周期内的抓包进行收集 提供抓包查看、下载等功能 抓包格式支持Fiddler和Charles，以及HAR
全息日志
TSW提供用户维度的全息日志帮助开发者快速定位问题
对请求生命周期内的日志，采用全息的方式记录，形成流水 流水按用户维度聚合 提供查看功能，快速定位问题原因
异常发现
谁都在用？
源于直出
2012年10月，TSW第一版上线织云（一体化自动运维平台），Node.js版本为0.6.20。当时的功能十分简陋，只实现了服务端JS直出页面，可以说毫无运维可言，唯一的价值是可以让首屏体验更快。为了强化这个唯一的价值，实现了gzip chunked，边压缩边传输，可以让页面内容有节奏的回包，精确控制流式回包，对Node.js来说非常简单。
在浏览器里，想要cookie的时候通过上下文window变量就取到了，从来没有觉得取cookie是一件特别费劲的事。但到Node.js里就不同了，对于取cookie这么简单的需求，需要特别关注request对象在哪里。因为request对象是局部变量，无法全局获得，这就是问题的本质。
直到2014年，一种实现上下文的方法被发现，window对象诞生。利用process.domain总是指向当前包裹自己的domain对象这一个特性来完成上下文自动切换。window对象的本质是与request对象生命周期绑定的全局变量。你可以在任何时候通过window获取request对象，进而取得cookie等其它信息。
window的出现，打通了不同维度间的联系，把这些联系落地，就可以产生新的价值。比如在DNS解析API中，是没有用户概念的，用户存在于更高维度中，高维对低维不可见，通过window对象，低维度里可以知道正在为哪个用户做解析服务。当解析结果有问题时，知道影响了哪个用户，通过用户也能回朔到解析过程。维度之间不是单纯的依赖关系，而是密切配合的关系。这就导致了TSW的代码在组织方式上，需要无条件高内聚，不能以模块的方式单独存在。为了收集这些联系，需要有配套的存储、查看系统。这些系统最终演进为TSW开放平台（tswjs.org）。
兴于抓包
有个问题一直困扰着我们：为了解决某个问题，抓包一小时，代码一分钟，抓包效率严重影响着定位问题的效率。在这样的背景下，TSW提出服务端云抓包的解决方案。与用户端抓包相比，不用再关注用户端网络环境、位置、接入层协议等问题。
久于运维
公司内顶尖的前端开发，分布在各种类型的产品中，想让他们成为用户，先要突破部门墙。运维这个维度是有机会破墙的。A业务和B业务的运维很大可能是同一波人。就像引力波，可跨越空间维度，直接抄近道，不用绕着本维空间跑。因此TSW选择在运维上发力，而不是在代码如何编写上，与开源库飚车。
安装1台Node.js是技能，安装1000台是运维。安装和升级，应该看成一个运维问题来解决掉。
Node.js版本，大家都知道迭代很快，如果每个版本都有业务在用，就有多个运维对象。提供多个版本供业务选择看起来很民主，但是，好的运维是减少运维对象。
能不能统一升级只维护一个版本？统一升级又遇到新的挑战：CPP扩展是和Node.js版本强相关的，只升Node.js还不够，扩展也需要统一维护。为了找出来所有的CPP扩展，TSW动用了监控，对业务私有扩展邮件告警，然后纳入TSW统一维护。统一维护加速了TSW的迭代速度，版本强一致规避了迭代带来的代码腐化问题。
前端开发之间交流JS毫无问题，但对运维同学来说，是方言，这时就需要能讲普通话。拿启动逻辑来说，一个Node.js程序炫技式启动，挂了的时候，只有开发知道怎么拉起来，这就十分尴尬。再拿扩缩容举例，运维扩缩容后，需要动代码才能上下线，那就是有问题的。织云经过多年积累，运维自动化程度达到了自助级别，TSW在标准化上，选择入驻织云。当需要安装、重启、升级TSW时，到织云点一下按钮就好了。
盛于开源
TSW已经具有很强的稳定性和业务通用性。Node.js在前端界目前已经具有相当的热度和欢迎度，TSW作为Node.js基础设施，在公司内部已经得到了开发团队以及运维团队的认可，本次将TSW开源，在业界进一步增强TSW的技术影响力，同时也进一步完善和优化TSW。
