从西安“一码通”不工作来看软件系统性能与可靠性怎么保障

西安一码通问题， 上出来很多段子，段子就不说了，我就说说怎么在技术上解决这些问题。

1、业务上如何解决这些问题

1）客户端结果缓存

这种大型系统应该做客户端缓存，在有效时间内不要去后台请求，减少服务的请求量。

2）客户端做连续请求过滤

客户端可以做请求过虑，在服务端没响应的情况下不要连续发请求，可以设超时时间，超时后再请求，而且超时时间可以不断延长。

3）服务端做连续请求缓存

服务端可以做连续请求过滤，同一客户端的请求同时只处理一个，其他的丢弃。

4）服务端做过负荷控制

服务端处理能力进行监测，对超过负荷的请求按照算法规则进行丢弃一部分请求，避免系统资源耗尽或者IO堵死，致使整个系统瘫痪。

5）做业务方通

对业务做放通规则，在业务处理不过来的时候保证基础业务运行，附加功能直接屏蔽。

6）重点业务保护

在业务繁忙处理不过来的时候，只保证重点业务，普通业务直接客户端屏蔽。

2、性能上如何做到支持大容量

一码通这种区域性应用性能上也不算大，技术上比较容易解决大容量。

1）多服务节点负载均衡实现

游戏都是这么做的接到不同的开服服务器的，可以多节点互为备份，比如每个区一个服务节点，客户端接到不同的节点，当一个节点坏了可以接到其他节点，理论上除非所有节点宕机，否则不会出现这种全市不工作的情况。从出问题的情况看，系统绝对的存在单点故障，不然不会全市瘫痪。

2）单节点性能提高

（1）缓存，各种请求结果内存缓存，没失效的直接回结果，不用老跑重复的业务逻辑。

（2）可以做批量数据刷新

按照算法，每次从数据服务获取数据时可以获取一批数据，防止对数据端的压力。

（3）请求接入与请求处理分离

这个应该大部分系统都会做，消息中间件一般就做到了，那就是实现请求处理的的分解，涉及到请求其他服务都拆分出来，做成异步的请求，避免第三方服务没结果导致自身服务的堵死。

3、可靠性解决方案

1）分布式系统

避免单点故障，看出问题的情况应该是系统有单点故障，不然不会全市瘫痪。出问题可能存在两个点一个是接入点故障，一个是访问通信数据的点，就是访问第三方的点，接入点宕机，宕机应该重启就好了，或者 络故障， 络故障应该会说出来。实现分布式多点接入，就没有单点故障了，就不会出现全是瘫痪了。各阶段也可以负荷分担，一个宕机其他节点可以接管。

2、容灾

做容灾节点，服务节点都坏了还有容灾节点支持，最坏情况下也不会全市无服务

3、备份恢复

在没有办法的情况下，还可以重启恢复服务也不会出现全是长时间无服务。

4、系统监测和自动重启服务

避免长时间业务中断，监测到业务无服务，立即重启。提供手动快速重启服务，避免长时间无服务。