@xishuixixia
2016-02-13T03:43:40.000000Z
字数 3210
阅读 1761
猴年说说耍猴的12306
原创
12306已经成为每年春节绕不开的热点。在猴年的春运之际，InfoQ再次重拾这个话题，与各位一起探索这个影响亿万人的公共服务。正如小道君所说的那样，今年朋友圈里、微博上抱怨12306的少了。不得不说，这是一个很大的进步，唯有进步值得颂扬。希望明年我们不必再跟踪这个热点。
吐槽奇葩验证码
相信无数人已经见识过今年12306各种神奇的验证码了，吐槽归吐槽，我们来看看验证码到底是怎么回事？验证码的学名叫做CAPTCHA，即“图灵测试”（看过电影《机械姬》的同学因该对此并不陌生）。验证码通常是由计算机生成一个对人类而言很容易而对电脑而言非常困难的问题，能回答者被判定为人，但验证码测试其实不是标准的图灵测试。验证码的目的是阻止人类恶意利用计算机做受限的事情。早期的验证码大多用扭曲的文字来实现，用以避开OCR的机器自动识别。后来，验证码的复杂有时让真正的人类也难以识别。毫无疑问，12306对验证码的使用已发挥到了极致。
图像识别方法可以分为两大类，模型的方法和搜索的方法。模型的方法是在业界研究和使用最多的方法，基于搜索的方法直到大数据时代才出现。2012年前后，深度卷积神经网络在图像识别领域开始应用，此后，深度学习的方法击败了所有传统的方法，使得图像识别的准确率向前迈了很大一步。最新的研究结果使得识别率达到了96.3%。阿里巴巴研究员/资深总监华先胜先生表示，只要验证码系统不断快速地增加和迭代系统的数据，验证码的破解基本上是不可能的任务。
折翼的前端
对于广大购票者来说，刷票软件并不陌生。浏览器厂商、黄牛党的刷票技能与12306道高一尺魔高一丈的对决，一度成为媒体争相报道的对象。我联系了著名刷票软件开发者木鱼并与之谈及了相关的话题，他源于个人使用而开发的刷票插件，曾一度导致GitHub遭受了DDoS攻击。
- 代码托管：导致对GitHub那次DDoS攻击的主要原因如下：
- Chrome在某次更新后增加了同源限制策略（大概是在2012年），HTTPS无法加载HTTP的资源。
- 木鱼没有HTTPS服务器，也没有相关证书。
- 订票助手需要自动更新检查，这个是刚需。
- 并没有找到比较简便的做法能绕过同源限制。
那时候并没有接触过GitHub并不清楚其内部的区别和限制
GitHub在流量略高的时候会返回错误（403）
经过调整的检测策略并没有对重试操作增加延迟和次数限制（虽然默认间隔并不短，但始终的高频率403导致请求越攒越多）
虽然后期我已经改用新的检测方式不依赖于Github和HTTPS（iframe代理模式），但之前的客户端因为GitHub不返回正确信息导致无法更新，也就无法降低请求量
综上所述，在GitHub越来越限制的时候，其承受的流量是逐渐增加的。只要能正确返回数据，流量是会直线降低的。可以说情况也始料未及，对GitHub认识不足导致其躺枪，因为这事儿众所周知也实非我所愿。
后来的解决方案分了好几个阶段。
鸟瞰混合云架构
先前有文章报道了12306采用Pivotal GemFire分布式内存计算平台进行技术改造的过程，重点阐述了12306如何解决网络阻塞和集群性能水平扩展的问题。
笔者针对12306业务的特点，与京东云首席架构师杨海明作了一番简单的交流，主要内容如下：
核心的瓶颈：12306购票业务与电商秒杀系统有诸多相似的地方。通常的秒杀系统包含数据展示及数据处理两个层面的能力：数据展示层面一般是通过CDN在全国范围内部署，实现各地访问的加速，因此访问层面的压力不大，核心瓶颈实际上在后台请求响应方面。后端必须同时能够支持高并发请求，并返回用户请求结果足够快。实际瓶颈不在CPU的处理能力，而在于I/O的吞吐速度以及数据一致性方面。在通常的电商秒杀系统里为了实现尽可能快一点，后端存储使用内存级别的操作，然后在慢速磁盘及高速内存中增加闪存卡，在磁盘阵列中增加SSD。虽然进行了磁盘层面的增强，但各地秒杀访问依然会带来数据一致性的问题，为了让全国各地的用户有平等的权利秒杀商品（比如新疆的客户与北京的客户）就需要部署多数据中心，同时实现多中心交易。
架构的选择，分布式内存计算平台(Pivotal GemFire)对于秒杀及12306之类的业务是一个正确的选择，但不是唯一的选择。在市面上还有其它各种分布式内存计算平台，在这里就不一一赘述了。但内存计算平台对于提升秒杀系统的处理能力毋庸置疑。此类业务的基本特性在于商品数目有限制，但在短时间内消耗光，查多买少；设计系统时，需要考虑读多写少的特性，尽量将压力往前端移，降低对数据层面的冲击。12306及秒杀业务的一个重要特点就是业务总量固定，比如12306对于一段时间的火车票是一个确定的数据量大小，秒杀业务在一个特定时间，商品的库存及商品的品类也是一个固定的数据量。因此，对于内存数据库层面，并不需要非常大的容量；相反，用户的请求如何合理的分散到各个负载服务器上，并汇总到这个数据后端，是秒杀平台设计优化的重点。
分库操作：原则上，需要对12306的业务及数据格式充分了解，才能把握其瓶颈及拆分点。12306涉及的是国家的铁路命脉，可以通过铁路的形态进行拆分，比如高铁、动车、快车及普通车；也可以通过地域进行拆分，比如北京中心、上海中心、广州中心、西安中心；再或者根据以往购票查询热度进行划分。原则是将数据分到多个地方，降低中心的压力。
小型机与X86优劣：虽然外界报道12306业务是x86取代小机，但京东云首席架构师杨海明认为小机不会完全被x86架构取代。在所有12306的报道中，所解决的是查询的问题，而不是改变数据库的问题，小机+Oracle或者小机+db2的传统结构在确保数据一致性方面依然有绝对的优势。我们只是看到12306的查询库使用了分布式内存计算平台。也就是说，假设一个x86服务器出现问题，并不会造成铁路秩序的混乱；相反，增加x86的前端，非常适应之前描述的将压力往前端迁移的原则，将用户的访问压力用更廉价的x86来扛住，而把数据一致性和可靠性的任务交给更稳定更可靠的系统平台。在x86及小机的架构选择中，京东云首席架构师杨海明认为性能的瓶颈并不是绝对的问题。小机在RISC架构上的优势，在内存访问上的优势，及软硬一体优化的优势依然明显；相反，x86的廉价、生态的丰富、越来越强的处理能力及易用性方面，也越来越吸引大量的用户。在现在对于系统的选择、成本的控制，以及出现问题的责任影响，成为决策者考虑的因素。举个例子，如果12306的后台票务核心系统在春节期间出现2小时无法购票，那造成的将不仅仅是经济损失，甚至可能引起各种不安定因素；相反，如果某电商的秒杀系统无法完成交易，那损失是可以控制的。
CDN缓存：CDN缓存解决的是用户访问端的问题，12306及秒杀场景下这些用户访问所带来的网络带宽是因为秒杀活动新增的，超过网站平时使用的带宽，这些带宽必须和运营商临时购买。为了减轻网站服务器的压力，更好地利用CDN、反向代理等性能优化手段，需要将秒杀商品页面以静态页面的形式缓存在CDN上。秒杀开始，用户刷新页面时，用户请求不会到达数据服务器，而是通过缓存直接提供给终端用户。用户体验的好坏，就是看CDN内容更新的效果。
更多关于12306的内容
早年InfoQ上几篇关于12306的内容如下：
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群（已满），InfoQ读者交流群（#2））。
