上一章：写点朋友遭遇的一系列不靠谱事儿吧 ①

上回说到第一次高峰期过去了。

技术总监之争

如果说上面的事儿都是小事儿，那么事情从此刻开始，就都是狗血了。

首先说说这个技术总监。仔细看的同学应该已经留意到了，有提到过很多次技术总监，但除了开始的时候给了一张像模像样的架构图，这位总监同学并没有再露过脸。
然后这位总监的由来，其实是这位朋友的兄弟，所以算半个合伙人。直到某天早上朋友发飙，要跟总监撕逼，直接的导火索就是这位总监十分看不惯在这次的架构演变过程中朋友全部听取了我的意见而直接架空了他，自己鼓捣了一套系统。
本来吧我心想其实用什么系统不是关键，闹得人仰马翻就不好了，就安慰朋友说其实用Nginx还是用Windows都不是关键，那个总监搞的Nginx反代也是比较成熟的也是一般的主流做法，并没有啥问题，只要配置没问题都行。但朋友一门心思要跟他撕逼，最后直截了当地说其实架构这个只是小事儿，其实心结由来已久。

原来此总监是这位朋友多年的兄弟，以技术入股的方式参与运营。虽然做的是技术总监的事儿，但其实不只是技术总监，连公司位置、技术团队招募等等，一个人乾纲独断，让朋友有点他一人把持了整个技术团队运营的感觉。
然而就算是这样，前期网站和服务器还是搞成了那个样子，让朋友很是郁闷，于是这次架构演变过程中，直接架空了他，所有的设计和架构都完全按照我的意思来。这让要面子的总监觉得很尴尬，也开始闹。
俩人闹啊闹啊，就要撕逼了。按照朋友的话说，就是毕竟刚开始合作没多久，现在摊开了以后还能做朋友。再这样下去，朋友都没的做。

PHP丢Session之争

在第一波高峰中出现的一个常见问题是，验证码怎么输都说错，而且有时候明明已登录，刷新一下又变成未登录了。其实这不是啥大问题，无非就是Session丢失之类的问题。
但处理方式出现了大问题。  

参考之前的说法，前端机器使用了负载均衡，使用了IIS的ARR将负载均衡到两台服务器上。由于后端中大量使用了Session来记录状态信息和验证码信息，然而Session依赖Cookies来记录标记，因此一旦Session生成，服务器便不可以切换，否则就会丢失Session。
因此在部署ARR的时候，我就特地设置了Client affinity来绑定客户端，在第一次访问后就会由ARR生成服务器绑定Cookies，保证上游服务器不会再变。
因此出现Session丢失的时候，我首先想到的是PHP关于Session部分的配置有问题。

如果事情只是往这个方向解决，那自然很好。  
可惜没有。  

原因在于当时在朋友手下的那个主技术员。他测试了一下觉得是Session丢失，基于他对负载均衡的理解，一口咬定是因为前后请求之间切换了上游服务器，导致了Session丢失，于是他强烈要求另外部署数据库或memcached来保存Session。
这个方案被我否决了。是Session的问题，但很明显不是因为负载均衡导致的问题。虽然用第三方服务器来保存Session应该是可以解决这个问题的，但这只是绕过了问题而不是解决了问题。
何况在这之后我是想彻底干掉Session的，所以虽然以后有可能会用分布式缓存，但是我不愿在这个问题上用分布式缓存来掩盖问题。

于是技术员开始跟我撕逼了。  
通过朋友这个传话筒，跟我反复隔空喊话，始终坚持是负载均衡有问题导致Session重复生成。然而我一直回复不是负载均衡有问题而是其它地方有问题，还在查。
最后技术员直接无视了我，使用掌握的远程管理权限，在数据库服务器上架了个memcached缓存，然后把所有服务器上的Session会话全部改成了memcached的，包括PHP配置都变更了，然后给我下通知，说问题解决了。
完全绕过了我，并且导致我无法定位最终问题出现的原因。

我还原了所有的更改，并且因为在我测试的时候那个技术员反复争夺远程桌面登录会话，一怒之下让朋友收回了所有的远程管理权限。只给他们FTP权限，所有的系统级别修改都被禁止。
后来经过调试，感觉是PHP序列化保存Session的时候遇到了问题，写Session的时候文件没有成功生成。
最终查明是因为PHP设置中的Session保存目录权限设置较高，PHP的进程没有权限写入，导致Session丢失。然而这个错误竟然没有报错，也没有任何位置记录相关日志，还是很费解的，不知道是不是因为错误被吃掉了的关系。

丢Session的问题是解决了。
但是从这个时候开始，这个主技术员开始变得有点好玩了。

第二波高峰

其实距离第一次高峰没几天，在解决了Session丢失问题之后，开始第二波高峰了。
然而这次高峰出现了一点戏剧化的场景，就是高峰来临之后没几分钟，服务器突然集体下线了。  
很神奇的，前端负载均衡无法访问，但是后端的机器用公网IP全部都可以访问，并且负载几乎为零。  

后来才查明，下线的原因是有人对负载均衡服务器的3389端口发起了DDOS攻击，然后超过了阿里云的清洗限制，接着就被强行黑洞了。换句话说，服务器网线被拔了。

您好，后台查看您的服务器在2015-07-23 19:00:34被黑洞了，所以目前服务器的网络访问不通。预计在150分钟后解除黑洞。

对于这种事儿还真没好办法解决。
后来的解决方案是，把所有服务器都全新购买部署（换掉公网IP），所有对外接口统一走CDN，隐藏自身IP。

不过卖个球票都能被攻击，也是……匪夷所思的。据说全中国地域攻击最严重的不是上海广州人，而是各大足球队的球迷，看来所言非虚。  

替换前端接口

在考察了朋友网站的首页和下订单页面的几个Ajax请求之后，我觉得请求可以做缓存。
理由是这两个地方的请求每次返回的数据之间没有用户的区别，短时间内几乎不发生变化。而现有网站的设计是不使用任何缓存，任何请求到来的时候都直接扔到数据库去。  
因此当用户在反复刷新首页等待起售的时候，或者下单选择详情的时候，反复的操作会对数据库造成巨大的压力。
因此我觉得应该加上缓存，这样能极大提高数据响应能力，对于全网站最繁忙的这俩接口来说，对降低数据库压力应该是立竿见影的。

基于之前对这些伙计的认识，我觉得让他们来改还不如我自己动手来的快。于是我就操起C#用Nancy作为基础框架搭建了一个简单Windows Service，一个服务进程作为守护进程，启动一个子进程提供简单的HTTP接口，然后IIS级别使用URL回写将特定的请求反向代理到这个接口上。
这个接口没干啥事儿，就是每隔一秒从数据库刷新一下数据，然后当有请求过来的时候返回内存数据。
然后这个接口在单进程处理请求的情况下，在并发300客户端时提供了将近2000RPS的响应能力，0错误。

而且这个接口的压力承受能力是线性的，并发直接加一倍（并发600）后性能也上升了将近一倍。

所以说想要性能好，缓存少不了，杠杠的，频繁调用的数据一定要谨记缓存，不能啥事儿都丢给数据库。  

另外这些人的前端太烂了，写的JS惨不忍睹，还有一个ajax两处调用所以一个页面发两次的问题。实在看不下去了我给简单重构了下……

这里顺便说一嘴，几个前端的json接口返回的ContentType统一为text/html，于是他们还很“聪明”地在ajax结束后用eval来把string转换成json对象。真不知道是不专业还是……没法说了。后来我说他们ContentType返回错误的时候还跟我犟嘴，说接口一直在用一点问题都没有……

这里本来我还想把流程优化下的，但是说了没人理。可能变动也比较大吧，后来我自己都懒得提了……

网站增加功能，支持线上付款，然后华丽地超卖了

在这之前，网站是不支持线上付款的，付款需要等到线下取票的时候再付款。
这多少有点麻烦，所以这次改动的时候上线了付款功能。
至于付款方式，除了支付宝，似乎也没有别的更好的选择。
具体的操作就是订票成功后有15分钟时间付款，超过指定时间后则取消订单，票重新可售。
具体的过程我没有参与，我唯一的建议就是独立出来一台服务器用来接收支付宝的支付通知。

熟悉这个流程的人一眼就看出来这中间的时间把控非常关键，很容易出现最后付了款订单却被取消的问题。

虽然这个问题出现的概率是有，但其实没那么高。
不过这次很明显意外了。

结果就是超卖了，严重地超卖，超卖了将近25%。
下场就是挨个打电话要退钱，然后被用户骂死。然后技术员被骂死。

对于此情况，技术员给出的解释是，是支付服务器的问题，支付成功了响应没接收到，于是超时了重新卖。
至于出了啥问题呢……技术员认为是因为用了CDN做反向代理，导致支付宝返回数据时出了问题。然后除此以外，他还认为这次的服务器没有之前的好，外带黑客攻击导致支付服务器没有能正确处理数据。

理由很充分，推测很靠谱。
可惜在我看起来就是扯淡，不管三七二十一先赖服务器再说，完全不知道这是啥心态。
我总觉得他无时无刻不在找服务器的茬儿……

后来我专门去支付服务器上扒了一天的运行日志做统计，发现支付服务器的接口错误率异常地高。

从上图可以看出来各类500错误的总数占比高达52%，换句话说，有将近一半的请求都是500错误。

……对于这种大面积的错误我还真是一时间没啥头绪，FastCGI跑的PHP还找不到相关日志，兜了一大圈光知道返回500了，具体啥错误信息不知道。

这时，另外一位据说是朋友认识多年的朋友，据说是高级顾问的人，开始关注支付宝环节了。嗯，这是个正确的思路……
但是他说……

……好吧，报500错误，让把MD5改成RSA。不知道这是啥解决问题思路。又或者根本不是为了解决问题，只是因为觉得MD5过时了不安全？
总之后来就没理他了。

只好让那个技术人员去仔细调试下接口，用模拟数据测试下。

然后他发现了一个很关键的地方。就是接口看起来正常，但是好像速度不快，有点慢。
这个慢到底是多慢呢？看这个图就知道了。

对，这一个接口用了16秒。
经过多次测试，这个接口返回时间基本上都在10秒以上，绝对不会低于10秒。
这可真是奇了怪了……因为他说本地测试都很快不会这么慢。
我看了下这个接口的代码，也没那么复杂，咋就那么慢。

此刻，那个技术员又开始对服务器上的PHP发难了……

后来他又觉得是加速乐的问题……要不然就是PHP的原因……反正至少一个有问题……否则问题没法解释……

虽然我觉得他的思路挺扯淡的，但他的发现还是很有价值的。那就是确实是这里的速度很慢。不仅慢，还奇怪，因为其它环境下可能会很快。
直觉告诉我这可能和网络请求有关系。

简单扒拉了一下支付宝的SDK，发现有一段代码表明了支付宝的SDK中对异步通知的信息做了二次联网校验。

然后我用Fiddler对支付宝的联网校验接口发起了请求。结果发现，这个请求就是很慢。
看起来原因找到了。

经我惊奇的是，这个慢竟然是将时间浪费在了TCP连接上：TCP/IP Connect用了九秒多，几乎是全部时间。很奇怪的，用服务器测试了一下其他的网站，却又都没有问题，快的很，唯独这个支付宝域名有问题。
开始的时候我还在考虑是不是这个服务器IP对应的网络有问题，企图换一个服务器IP，结果ping了一下发现全国都特么是同样的IP，只能作罢。

那既然问题是服务器层级的，怎么办？只能给阿里云提交工单了。
而此时，那个技术人员还在认为这跟PHP版本有关系。我都扛出Fiddler了他还认为是PHP导致的……

阿里云的工单简直就是低效的代名词。在他们解决这个问题或给出回复之前，暂时的方法是校验通知的签名和时间，跳过了二次联网校验。

然后阿里云的工单回复如下。

然后

经过很长时间的曲折后，终于找到原因了。
据说是Server2012新的默认开启的ECN机制导致的，关闭后就恢复正常了。

话虽这样说，但为什么ECN会只影响支付宝，还真是一个奇怪的事情啊。
再PS下，阿里云那边找到原因已经是两周后的事情，也算一个经验。

第三波高峰

当天晚上就迎来了第三波高峰。
简单地说，就是40分钟内服务器处理的请求数超过300万。同时由于攻击以及流量管控，在超过加速乐的限制后，所有流量回源，所以后面的时候接口处于不稳定状态。

但除此以外幸好没有太大问题。
所以后面我建议将非接口类地址全部彻底静态化。

这中间涉及到一些其它问题，不过不是很关键，在此略过。

在这之后，有更奇葩的事情诞生了……

神奇的加薪申请

过了几天，朋友突然找我，说让我用.NET把网站重新做一遍行不行。

朋友说的这位技术员就是之前一直有过交流的那位技术员，感觉虽然有时候思维有点让我理解不能，但态度大概不差的。没想到……

后来才了解到，这个技术员也是他开始的时候在网上认识的，一开始态度也还不错，没意识到后来的这些问题。

瞅着这架势，撕逼是撕定了。

倘若只是闹掰了，倒也没那么复杂。这俩人后来是彻底掰了，我就只能建议他先把所有数据和代码都做备份，然后把FTP什么的服务全部关闭，所有的控制密码都用新的。然后朋友为了防止那技术员复仇攻击，把所有的服务器也都换了新的……

在一个半星期后，粗事儿了……那个技术员要去告朋友。


好吧……虽然我觉得加班是应该给补贴，但是没合同的情况下我是没有啥底气的，难得这位同学这么有法律意识。不过话说回来，刚听到的时候我的内心其实蛮崩溃的，因为我加班这么多年竟然就没想过拿工资……

不得不说文盲真可怕，这种事儿我就从来没关注过，原来离职了投诉加班不给工资还能拿赔偿的……我隐约地看到了一条发财之路……
这事儿最后的结果呢，是以赔偿他9K块结束。

到这里我终于了解到这个人的来龙去脉，原来是网上认识的，做兼职起步的，没怎么见过面……只能说，悲剧啊。

但！你以为事情就酱紫结束了吗。
图样图森破。桑塔么司乃衣服！

……不知道为甚么说到这里的时候我好想笑。
且容我放浪不羁地笑一回。

啊哈哈哈哈……

同学们，我在冥冥之中指了发财的道路啊有木有   

好了。先写到这里。
后面还有一段，可以说是全系列中掉链子集中的高发期了，直接导致了这个项目黄了。

感谢阅读本文，欢迎扫描下方二维码关注鱼的公众号（微信内长按识别哦）