satan 通过 Google 阅读器发送给您的内容：
昨天聊天，聊到最牛电商的问题，大家都笑了。
frank订票45分钟花了45分钟，还没搞定。先是从chrome换到IE，因为前面的部分chrome能用，付款不行。然后从工商付款，上限500，不行，必须一次付款800，而且不能用支付宝。问我借卡，我的也不行。最后借到卡了，结果过45分钟了，重排，没票了。
淘宝买东西要是需要超过5分钟，喵喵就会少买好多东西。
还有个朋友说，他的卡能支付5000，买票，扣款后没票。人家说钱能拿回来的——钱能回来可是票回不来阿。好，再买，又扣钱没票。再买——没钱了。
我去阿，这TMD不是坑爹么？
这种网站，转化率还是100%，广告成本0，绝对最牛电商阿——没有之一。
关于顶不住这个问题呢，大家都懂的。我自己也做过类似的事情——甲方设法让自己的厂家中标，也不管人家有没有能力做。厂家领导是先中标再说，不中标自己就完蛋了。下面的人没能力，要么是不知道自己没能力，要么是知道也不敢说。做着做着问题一堆，也不敢和甲方沟通。不沟通问题就越来越多，交货的时候一看，甲方吐血。然后厂家领导就和甲方领导搞协调，厂家要去修一些问题的，甲方延一点时间，最终还是会让这个系统上去的——否则领导也麻烦阿。
最后只要这个烂摊子不被揭出来，大家皆大欢喜。中国政府领域的IT，大多都是这个样子。
比较大的烂摊子揭出来的，一个是绿坝。没办法，太烂了，还要所有机器供应商都来做支持。索尼干脆发了个文，这是中国政府让我们装的，出了问题不要找索尼，谢谢。结果这样还被告上美国法庭了。最后领导实在顶不住压力，撤了。另一个就是这个，最牛电商，估计回头也会撤的。因为后面订票压力越来越大，搞事情的人也越来越多，烂摊子搞到后来领导也会怕的。
其实昨天gary说了一句比较实在的话，这个系统不应该做成这个样子的。一切说中国买票的人太多，瞬间交易压力大，刷不出票的人持续刷的，都是借口。知道压力大，搞分时销售和抽签制分散压力。前端做负载均衡和CDN负担压力，后端真到订票的时候转换成MQ去操作。大型机再怎么做的差，每秒1000个transactions是出的来的。一小时就能完成360W的交易，一天八小时，3000W的票就出来了。中国有多少人需要订票的？3亿？就算做瞬时压力，铁道部车票成交比纽约股市买卖还快，要求还高？技术做不到根本是扯淡，最多是钱的问题——现在还是花钱没解决问题。
为了见证奇葩，我特地上去看了一下，结果第一眼就晕倒了——铁道部需要你自行下载根证书。我去阿，堂堂铁道部，一个多少万的项目，连TM买一张证书的钱都没有？！
其他细节就不多写了，相信用过的人比我都清楚的多。需要多次点击才能买到一张票，访问过程长导致压力大。定时开票，时间集中导致压力大。需要注册，导致注册过程冗长，也是增加压力。这些都不是技术问题。
整个过程中耗时最长的（抱歉我懒得注册，只去看了余票查询），一个是http://dynamic.12306.cn/TrainQuery/leftTicketByStation.jsp。这个的服务器响应表明是来自Apache-Coyote/1.1，由squid/3.1.18缓存，未命中。另一个是http://dynamic.12306.cn/TrainQuery/passCodeAction.do?rand=rrand。这个的服务器响应表明来自Apache-Coyote/1.1，是一张image（验证码），同样未命中。基本squid命中的都在ms级别返回了，出问题的都是dynamic.12306.cn这个域名没有命中的页面。这个表明前端的缓存还行，压力都压到了后端。至于造成这个现象的原因是前端缓存策略错误，还是后端性能相对不足，就不知道了。
我注意到，至少有一个页面https://dynamic.12306.cn/otsweb/css/contact.css。Server字符串是asfep/2.3.0 svn:3075。asfep是什么我不知道，google了一下也没出来。不过svn？这文件是从svn服务器上出来的么？！如果是，这就有点奇葩的味道了。
可从此处完成的操作：
- 使用 Google 阅读器订阅Planet of Woodpecker.org.cn for CPUG
- 开始使用 Google 阅读器，轻松地与您喜爱的所有网站保持同步更新
没有评论:
发表评论