上一篇的详细方案，有的同学会有疑问，我怎么就能直接得出这些结论，这里面是有套路的，之所以可以直接给出结论是因为在架构设计上行业内已经有了很多成熟的解决方案，我们要把所有的基于场景的架构解决方案烂熟于胸，然后挑选适合系统场景的方案，进行一定的修改和妥协来满足当前场景的方案即可。

从本节开始，我们将基于该跑步运动APP来详细了解每种架构设计的套路，其适用的场景和具体实践，为了后面统一语境，我们将该运动APP命名为Runnf。下面这张图描述了Runnf的部署架构。

无状态服务 是为了解决高性能，因为一台服务器的硬件设备性能是有限的，通过增加机器的方式来提高总体的性能，同时也解决了高可用问题，一台服务器出现故障，自动切换到另外一台可用的服务器继续无缝的提供服务；同时也解决了可扩展的问题，当临时需要提供十倍于当前规模的服务时，横向的增加服务器即可，因为是无状态，整个集群规模可以线性增长。

对于Runnf的读要求达到83328的QPS，我们需要设计服务都是无状态的，即每次相同的请求，任何一个节点经过计算后返回的值都是相同无差别的，某个节点不会保留某次请求的状态数据，所有状态数据通过第三方的有状态系统来保存，比如购物网站的session数据，可以保存在Redis中。

Runnf的用户会话数据会保存在Redis集群中，无论哪个应用节点对外提供服务，都会统一访问Redis集群获取会话数据。当在线用户量比较大时，可以考虑Redis的sharding方案来解决数据分片问题，这个后面再单独来讲。

经过把状态数据存储在第三方的有状态系统中，我们对有状态服务进行了改造，实现了无状态服务，但是如何把每次请求都平滑的落到整个无状态服务集群上，保证不会出现请求集中落在几个固定节点上，同时也能够保证在增加和减少服务节点时，对整个服务集群没有影响，这就需要负载均衡系统来实现，下一节我们来聊一聊负载均衡系统的设计和实现。