摩拜服务器又双叒叕挂了

今天摩拜推送红包活动之后，傍晚时分，服务器又挂了，这次应该和9月份服务器宕机不一样，在9月份宕机的时候技术储备不足，这么长时间摩拜单车都没有把服务器问题解决，看来技术部门需要背一下黑锅了。

回顾一下去年9月份的故障：9月19日下午6点40分，摩拜单车发布官方微博，解释称 “由于当前app访问使用人数过多，导致服务暂不可用，系统将在二十分钟之后恢复正常”；但情况显然并没有在20分钟后好转，直到晚上9点40分左右，摩拜单车才更新微博，称 “仍在事故恢复之中，后台服务资源紧张，导致app上可以看到车，却无法开锁，请您暂时选择其他出行方式。”

这应该是服务器资源不足，后台程序架构处于早期阶段，各项技术指标优化不足，导致请求过多的情况下，服务器资源被耗尽，导致后台服务启动困难，这时候重启试试是不管用的，重启后台服务就会被巨量请求瞬间击垮（其实也就是前端客户端处理的问题导致连锁反映，当前端请求服务器不可达的时候，客户端会自作主张的进行多次请求重试，导致请求成倍放大）。

相信经过去年9月份的服务器问题，摩拜单车挖了不少牛人来处理后端架构的问题，这次又出问题的原因估计这些牛人依然没办法彻底解决问题，导致事故频发。

让我猜测一下摩拜单车后台技术架构的演进看看他们的问题到底出在哪里？

早期估计摩拜单车应该技术没有几条枪，主要完成业务模型，走通整个业务流程，充其量也就是应用、车锁、数据库分离。大概如下：

这是一个具有基本功能和数据分离的架构，用户和支付等相关逻辑都在应用服务器这块，当受到大量的用户请求冲击的时候，应用服务器则会超载并且造成资源不足，当服务器响应缓慢的时候，客户端逻辑如果处理不好，则会对服务器造成二次伤害，那就是当请求不到数据的时候，客户端就会多次轮询，原本正常1w次请求可能会成倍增长，这也就是去年九月份摩拜单车预估20分钟解决问题，结果花了6个小时都没有处理过来的主要原因。原本想着重启所有服务器就好了，结果请求堆积严重，导致重启失败。这个时候如果真的遇到大的冲击应该怎么能够解决呢？按照最小修改原则，应该采用服务降级的模式来处理，也就是在应用服务器前端增加请求过滤，让应用服务器能够支撑的请求数量请求到应用服务器，超出应用服务器服务范围的时候，把请求丢弃，这样即可保障部分用户的使用，当用户负载降下来的时候再做后续修改（其实摩拜单车后台还有另外一个隐患，那就是车锁服务器是个长连接服务器，随着单车投放越来越多，长连接的服务器的负担也会越来越重）。

有过去年九月份的故障，相信摩拜单车花了重金找了不少大牛来处理网站业务请求的问题，保证业务不受影响。那么按照常见的互联网高性能架构应该是这样的。当然也许摩拜单车的架构还没有进化到这个阶段，反正不管怎么说，未来他会进化成这样。:)

（太复杂了，直接网上取图）

这个架构下，貌似完美解决大面积宕机造成的用户不可用的情况，但是由于服务分区，导致系统恢复起来也很困难，今天这个故障其实就是这种情况，统一数据模块挂了，导致用户大范围无法使用，下午6-7点的这个阶段，从路上只有小黄车来看基本属于这个情况。到了晚上8点以后用户请求恢复，但是车锁服务由于分区的原因，导致一部分用户无法使用，扫描车锁的时候app上显示？？？？，这应该是部分分区用户命中了故障的校验服务器的原因。这种架构看似完美，实际上也存在分区单点故障的风险，需要服务器和客户端双向配合才能完成多点负载协调。这种情况下极端的故障基本可以避免了，从今天的摩拜单车的故障来说，我路上看到北京大面积故障，看微博上的消息，深圳、南京等多地故障，看来不是孤立事件，估计摩拜单车还要努力进化到上图这样。

作为一个分布全国多个城市的分布式单车服务，GSM这套架构比一般的网站架构更适合摩拜单车，希望他们有人能看懂下图。：）

通信和计算机架构实际上是殊途同归的，相信既有通信工程又有计算机技术的同学能够体会到这一个微妙的特点。

关注@白话互联 明天我会详细的讲解这个图，并且提出如何优化摩拜单车的技术体系架构，应该怎么通过逐步演进的方式把架构进行优化。