分类目录归档：Arch

当我们在谈论HTTP队头阻塞时，我们在谈论什么？

发表于由
回复

近来访问网站，明显感觉支持HTTP/2的网站越来越多了，对行业来说是个好趋势。HTTP/2的RFC虽然写的很厚，但是总结起来就做了以下几件事：

  1. 通过TCP多路复用降低延迟；
  2. 单个TCP连接上允许乱序request-response，解决队头堵塞问题；
  3. 实现层面上，大部分浏览器要求HTTP/2必须开启TLS，一定程度上解决数据安全问题。

其中，队头阻塞问题真的被解决了吗？

HTTP/1.1为什么会队头阻塞？

HTTP/1.1通过pipelining管道技术实现一次性发送多个请求，以期提高吞吐和性能，如上图中的序列2。然而，这种技术在接收响应时，要求必须按照发送请求的顺序返回。如果，第一个请求被堵塞了，则后面的请求即使处理完毕了，也需要等待，如上图中的序列3。

那么，HTTP/2是怎么解决这个问题的呢？那就是数据分帧：多个请求复用一个TCP连接，然后每个request-response都被拆分为若干个frame发送，这样即使一个请求被阻塞了，也不会影响其他请求，如上图序列4所示。问题完美解决了？准确说，只解决了一部分。

如果队头阻塞的粒度是http request这个级别，那么HTTP/2 over TCP的确解决了HTTP/1.1中的问题。但是，HTTP/2目前实现层面上都是基于TCP（没错，HTTP从来没有说过必须通过TCP实现，你可以用它其他传输协议实现哟），因此HTTP/2并没有解决数据传输层的对头(包)阻塞问题。

如上图所示，当第一个数据包发生丢包的时候，TCP协议会发生阻塞会进行数据重传。虽然TCP有快速重传等机制来缓解这个问题，但是只能是缓解。无法完全避免。

如何解决传输层的队头阻塞问题？

应用层无法解决传输层的问题。因此要完全解决队头阻塞问题，需要重新设计和实现传输层。目前而言，真正落地在应用的只看到Google的QUIC. 它的原理简单讲，就是使用UDP实现了一个可靠的多路复用传输层。我们知道UDP是面向数据报文的，数据包之间没有阻塞约束，QUIC就是充分利用这个特性解决传输层的队头阻塞问题的。当然，QUIC的协议实现有非常多的细节，而这方面Google确实做得非常好，如果你想进一步了解，可以关注他们的开源实现。

需要说明的是，当前的QUIC实现使用HPACK压缩http header, 受限于当前HPACK算法实现，在QUIC中的header帧也是受队头阻塞的。但是粒度已经降低到了帧这个级别，并且仅会在header帧中出现。实际使用中，出现的概率已经非常低了。

小结

  1. HTTP/2 over TCP(我们接触最多的HTTP/2)解决了http request级别的队头阻塞问题
  2. HTTP/2 over QUIC解决了传输层的队头阻塞问题（除去header frame），是我们理解的真正解决了该问题。

APP上传文件到云端的正确姿势：据说值三万美金

发表于由
回复

APP上传文件到云端的正确姿势

近几年云存储和CDN的普及给多媒体文件存储和分发带来了诸多便利。如今要上线一个基础功能视频、图片网站，使用CDN厂商提供的服务，转码、存储、分发，甚至简单的访问控制都一站式搞定。想想以前个人站长时代，需要自己加硬盘、买带宽，自己使用ImageMagick和ffmpeg转码?‍♀️，真是酸爽。

云储存带来便利的同时，有很多安全问题往往容易被忽视。前段无人机独角兽大疆创新DJI爆出SSL 密钥和AWS key泄露问题，这使得黑客可以直接访问用户的私有视频内容。更有意思的是，泄露的原因居然是因为大疆把key放在了github上的开源项目的固件firmware中，而且已经这么放了4年，四年……?。这件事有意思的是，发现该密钥的哥们是一名叫做KF的白客，并把这个问题报告给了大疆，准备领取$30000的奖励，还预定了Tesla Model 3, 结果大疆法务把这花小钱就能解决的大事给谈炸了，KF的特斯拉没有了，但是大疆损失的可就不止这点小钱了。喜欢看故事的同学可以移步大疆 VS “白帽子”，到底谁威胁了谁？

如今移动互联网的天下，几乎每个APP都会上传文件到云端。这里，我们谈一下上传文件到云端的错误姿势背后的原因，以及正确姿势是什么样的。

错误的姿势

将云端的key保存在APP，然后APP直接调用接口上传文件。

很惊讶？我们的独角兽公司大疆同学就是这么干的呀。其实，不需要嘲讽大疆，你可以问一下你身边的互联网公司工作的同学，结果会让你更惊讶。

就我了解的情况，走上这条不归路有这几类原因：

  1. 创业公司野蛮生长的技术债。
  2. 部门墙的原因，有些公司的云端账号可能掌握在客户端开发小组的手里，而客户端同学对于服务器端的安全问题相对欠缺知识背景和敏感度。
  3. 程序员偷懒，不走云端标准交互流程，并且有严重的侥幸心理。

正确的姿势

正确的姿势其实也是一句话：

密钥保存在服务器，客户端每次向服务器申请一个一次性的临时token或signature，然后上传文件。

据我们的使用情况看，国内的CDN厂商都支持这种授权三方上传方式。比如又拍云的认证授权，阿里云OSS的授权给第三方上传。

当然，实际的系统不可能这么简单。下面以我们前端时间设计和实施的上传流程为例，介绍我们在设计文件上传时的考量因素：

名词解释：cds, content delivery service, 这是上述流程中唯一自己开发的服务，感谢CDN的普及?

  1. 根据我们以往的客户端文件上传监控，客户端上传文件第一次尝试的失败率约为4%（这其实是一个比较可怕的数字，同时你也可以感受一下4G网络的复杂性）。因此，客户端申请上传签名时，可以指定多种类型。在我们的系统中，我们实际使用了两个CDN厂商承载上传请求：阿里OSS和云拍云。默认通过阿里OSS上传，又拍云作为灾备上传。
  2. 为了能达到高于CDN厂商之上的可用性，我们使用了两家CDN厂商（又拍云和七牛）进行内容分发。访问每一个文件的完整url地址是可配置的，因此我们可以在任一CDN出现问题的时候，在后台切换CDN。
  3. 可能有同学发现了我们使用了不太主流的又拍云。没有什么特殊原因，只是因为给的价格折扣比其他两家要低。
  4. 所有的云端数据都保存在阿里OSS，主要是基于阿里OSS可用性是跨可用区的。另一方面，这也实现了云端储存与内容分发的剥离。这意味着我们可以无痛的更换又拍云或者七牛云。
  5. 客户端上传文件成功以后，cds会收到一个回调通知，这里我们做了文件内容的合规检查和内容审计。当然，你可以在这里做一些数据挖掘的事情。

小结

他山之石，可以攻玉。据说，大疆犯错的程序员已经被劝（开）退（除）了。如果你所在的公司还存在类似的问题，赶紧行动起来吧。

微服务troubleshooting利器——调用链

发表于由
2

微服务troubleshooting利器——调用链

Docker、k8s以及「微服务」是过去两年（2016~2017）对互联网系统架构影响最深远的技术和理念。自己非常幸运，全称参与了公司新架构的设计、研发与迁移，目前公司整个架构已经完成了微服务1.0的建设，正在朝着微服务2.0的方向继续前进（关于微服务1.0与2.0的关系和差异，后面有空了单独在写）。期间有非常多有意思的事情值得与大家分享。今天先聊一聊微服务中的调用链系统。

微服务的喜与悲

从以前的巨服务完成微服务化后，服务的数量大幅增加，系统进化为完全的分布式系统。对运维、上线的自动化的要求自不必说，对研发troubleshooting也有了更高的要求。troubleshooting面临的挑战主要体现在：

  1. 服务日志分散化。以前在一个巨服务里面大多时候可以顺利的将一次调用的所有日志查完，但是现在日志分散在各个服务之中。
  2. 服务之间的日志需要某种手段进行关联查询。
  3. 由于日志量巨大，直接从原始日志进行关联查询没有普适性。因此，需要对这种关联数据进行索引单独存储。

这是一个有意思的挑战。更有意思的是Google早在2010年发表的论文Dapper, a Large-Scale Distributed Systems Tracing Infrastructure中就已经系统的阐述了如何在分布式系统中使用调用链来解决该问题，更更有意思的是，国内几乎所有介绍调用链系统的文章都会提到这篇论文，也会引用下面这张图?‍♀️……

这个问题虽然在国内已经被谈及了多次，但是我们发现大部分文章都是介绍如何基于open-trace, zipkin建立一个跟踪系统，即使有自建系统的分享，也相对缺乏对构建适合自己的调用链系统时的考量和分析。因此，这里主要谈谈我们在做调用链系统时的设计理念和取舍。

cdapper调用链系统

我们的调用链系统取名cdapper, 显然基本思想来自Google Dapper论文，对此我们毫不避讳。字母c则是公司首字母。

我们没有采用开源的dapper系统，而是完全自己实现。主要有以下原因：

  1. 开源的dapper系统为了顾及通用行和普适性，代码都非常臃肿。这与我们一贯主张的「大系统小做」原则不符。
  2. dapper的思想并不复杂，甚至可以说非常简单，因此自己实现这套系统并不是「没问题创造问题去解决」。事实上，我们的dapper数据采集核心代码（golang实现）也就400行以内。
  3. 我们的基础服务组件有很多定制功能，直接使用开源dapper系统不可避免设计相关系统改造，而我们自己实现系统，可以从设计之初就与已有基础组件整合。

在我们的系统中，各微服务主要通过http API进行交互，下面以API调用为例进行说明：

  1. 流量通过gateway服务进入系统，gateway会在每一个http API请求的header中生成一个trace_id，然后将该请求分发给各个微服务。
  2. 微服务接收到请求后，会生成一个子节点span_id。以service_0为例，生成子节点span_id_0, service 0调用service 1, 则继续生成子节点span_id_1. trace_id, span_id_0, span_id_1,...形成链式关系。
  3. 节点的粒度粗细无须局限在http API级别，各个微服务可以根据自身业务特点，进一步将子节点细化到每一个redis调用、每一次mysql查询等。
  4. 我们使用自己深度定制的gin作为http 微服务的基础框架，通过中间件的方式来集成调用链。大部分时候，添加一行代码即可完成调用链集成。此外，我也提供redis, mysql, rpc等其他基础组件的低侵入集成方式。
  5. 调用链数据统一输出到我们的data bus的基础组件。data bus是一个架构上的逻辑概念，目前实现层面主要通过文件日志和kafka承载。我们不推荐使用tcp网络传输调用链数据。主要有以下考虑：
    1. 我们使用的是阿里云，而阿里云内网抖动几乎是家常便饭。使用网络传输调用链数据稳定性差。
    2. 由于业务性质，流量存在突发性，我们需要一个高吞吐的的消息队列来缓冲这种尖峰流量。在这方面，我们非常信赖kafka.
  6. data bus是我们整个分布式系统的数据总线，我们在这个总线上安插了很多子系统，其中一个子系统是log sink日志数据汇聚系统（其他子系统后面有空了介绍）。该系统对调用链数据进行收集，然后存储在cassandra中。在这方面，我们非常信赖cassandra, 尤其是其优异的写入性能。如果你对我们如何存储调用链数据感兴趣，可以看上一篇文章LSM Tree/MemTable/SSTable基本原理了解细节。
  7. 每一个http API请求的响应中都会在header中返回trace_id。研发通过trace query进行调用链查询：

小结

微服务不是银弹，在带来很多好处的同时，也对整个系统架构的其他基础提出了更高的要求。微服务系统要先运作起来，一个简单、高效的系统诊断工具对系统微服务化的落地有着非常重要的促进作用。调用链就是一把这样的瑞士军刀。当然，调用链其实已经是8年前的理念了，如果你关心这个选题的最新发展方向，你还需要持续保持对世界上最大的分布式系统公司——Google的关注?！