APP架构师必看：面对爆发流量如何进行架构调整

沈剑：58同城技术委员会主席，高级系统架构师，产品技术学院优秀讲师。负责过58同城即时通讯，支付系统重构，摊销系统重构，数据库中间件，58同城推荐系统，58同城商户平台App等多个系统与项目的设计、实现与重构，现在负责58同城C2C技术部门。

APP架构与WEB架构的最大不同

移动APP的架构和传统PC的WEB架构有三点不同：

1. 连接的稳定性。在传统的web端连接成功后就可以认为它是稳定的，但在移动端、无线端，APP连接非常敏感，可能进出电梯、隧道、地铁，连接就会断，所以连接的稳定性是很显著的区别，也是很大的挑战。

2. 流量的敏感性。传统PC和web的应用架构可能不太关注数据量、流量，但移动端、无线端，流量有限，用户非常关注。所以在架构和协议设计以及数据上，要给予非常重点的关注。

3. 消息的可达性。在PC和web端一般认为消息发出就能够收到，而APP可能连接不稳，消息发出去收不到。无线端在消息的可达性问题上，需要在架构上额外做一些事情来保证。

58在APP稳定性的优化实践

现在用的最多的协议一般是两种，一种是HTTP协议，一种是TCP的协议。 58这边主要是有两块优化：

一是针对HTTP的协议。HTTP传统的方式是发一个HTTP请求，先要进行一次DNS的解析，由域名解析出IP，然后根据这个IP访问一个Nginx，再把它转发到对应的后端Webservice上，这个过程对DNS敏感要求很高，同时它的路径比较长，需要经过Nginx的转发。在PC上这个架构是完全没有问题的，但如果到了移动端可能流程或处理时间上就过长了。

因此我们针对http做的优化是使用IP直连的方式：不使用域名，直接使用IP去连接，既避免了DNS解析，也减少了一次转发，用来提高稳定性，降低处理时间。

第二是TCP，传统PC和WEB的应用中，TCP与用户后端绑定得非常紧密，一旦TCP断开的话，它的session可能就清除掉了，你再次连接上需要走登陆的流程，成本非常高。WEB出现这种情况的概率小，但在APP端，无线不稳、网络环境不稳时经常断线，如果每次都重新建立session的话，可能耗电量和数据量都非常大。

因此我们针对TCP做的优化是将TCP和session进行解耦。TCP断开的时候，session不进行清除而是继续保持，让用户感觉不到断开，我们后端可能有一些机制探测出来，然后偷偷连上，这个过程对于用户来说是无感知的。

58在降低使用流量消耗方面的优化实践

我们采取了一些技术手段来降低流量的传输。举个例子，登陆一个APP的过程中，传统方式可能要从服务端拉取很多数据，比如微信、QQ登录时要拉取好友数据、群组数据、详细信息数据等；APP端也需要拉取这些数据。

其实并不是每次都需要重复拉取这些数据——用户登陆之后，本地已经存储了一些历史数据，我们只要从服务端拉取那些增量变化的，而没有变化的则可以直接使用本地数据。

我们使用了一些机制从服务端拉取变化的最新数据以减少数据量的传输。这是我们使用的方法，希望给同行有所借鉴。

58应对流量爆发的架构调整

随着用户量、并发量、数据量越来越大，后端一些架构在可用性、负载均衡和数据量上都有一些挑战。

• 高可用性，任何一台服务器宕机都不能影响服务的可用。解决可用性的问题方向是进行冗余。如果只有一份服务，那么它挂了的话可行性就会受到影响；如果有多份服务，就算挂了，也可以通过负载均衡或者一些导流的方式来保证服务可用。所以站点的可用性就是冗余站点；服务、数据也是这样。这是可用性上的一些调整。

• 负载均衡，在接入层用一些传统的负载均衡方式，在服务层依托连接池，在数据层用数据库的连接值的负载均衡方式来保证负载均衡。

• 非常大的数据量对架构也是极大的挑战，本来在数据层可以选择根据业务进行垂直拆分，但数据量大的话就必须进行水平拆分，用一些拆分的方式来保证大数据量下依然能够响应很高的并发和请求。

成为架构师的2个能力

我在最开始也没有非常明确的要在几年内成长为架构师的规划，只是不断地解决现实项目和系统中的问题，然后慢慢接触越来越多的架构、业务和系统，不断解决问题，不断学习和提高。

我给一些想成为架构师的同学的建议：

第一，一定要落地在一线。在一线了解项目业务中出现了哪些问题，然后解决它们，在解决问题的过程中能力范围实际是不断提高和成长的。我不具体举例使用什么样的架构或者工具和知识，反正在解决问题的过程中肯定会接触和学习到不同的知识和工具以及相关的技术。

第二，一定要贴近业务。我的观点是任何脱离业务的架构设计都是耍流氓。可能有些公司发展到后期有一些为了架构而架构的技术方案，目的可能不单纯，为了晋升或者是怎么样。但实际上，一旦脱离业务，技术和架构都是空谈。

总而言之，要保持一线，时刻接触业务，这是我的两个建议。