不保存状态的应用给高可用的架构设计带来了巨大便利，既然服务器不保存请求的状态，那么所有的服务器完全对等，当任意一台或多台服务器宕机，请求提交给集群中的其他任意一台可用机器处理，这样对终端用户而言，请求总是能够成功的，整个系统依然可用。对于应用服务器集群，实现这种服务器可用状态实时检测、自动转移失败任务的机制就是负载均衡。
DB分库分表，读写分离
对于数据层来说，如果数据量不大，db可以采用读写分离部署，对于读多写少的场景可以解决一部分压力，从而提高我们接口的响应速度，如果写的数据量和读的数据量都很大，那么就必须要对db进行分库分表外加读写分离了。
2. 伸缩性
应用程序应该能够根据不同的工作负载进行伸缩扩展（尤其是通过增加计算资源来进行扩展）。为了提供伸缩性，系统应该努力消除瓶颈。
如果在虚拟机上运行内存数据库，那么添加另一个虚拟几点就可以将所有的查询请求分布到两台虚拟服务器上，将可能的吞吐量增加至原来的两倍。添加额外的节点应该能够几乎线性的提高系统的性能。
增加一个内存数据库的节点后，还可以将数据分为两半，并将其中的一半移至新的节点，这样就能够将内存容量提高至原来的两倍。添加节点应该能够几乎线性的提高内存容量。
所以一般好的接口设计是可以通过水平扩展机器来达到提升性能的，这就要求我们设计接口的时候提现无状态性。
3. 容错性
应用程序应该考虑到错误发生的情况，并且从容的对错误情况做出响应。如果系统的某个组件发生错误，对与该组件无关的请求不应该产生任务影响。错误是难以避免的，因此应该将错误造成的影响限制在发生错误的组件之内。如果可能的话，通过对重要组件及数据的备份和冗余，这些组件发生错误时不应该对其外部行为有任何影响。
假设你的系统既使用了redis，也使用了mysql对数据进行处理，当redis或着mysql挂了的时候，程序应该可以继续提供服务，而不是一味的报错。流程如下：
当一个组件不可用的时候，可以使用开关对某一个组件进行降级，常见的降级方式分为手动降级和自动降级，手动降级可以借助zookeeper进行，自动降级可以使用Hystrix。