首先就要编写压力测试计划。比如支持 10w 个并发连接、响应设计小于 200ms。这个就是我们的预期目标，我们接下来的设计、规划都要围绕这个目标以及超过目标来进行善于缓存。包括分布式缓存、本地缓存。少量频繁访问的可以本地缓存大部分情况下都能够使用分布式缓存解决我们的数据缓存问题。（Redis）需要外网进行网络传输的数据，能够压缩的尽量压缩后传输。客户端和服务端之间的数据交互，尽可能的压缩。数据压缩后的传输可以大大减少外网传输时间，并提高了单位时间的连接处理能力。压缩的传输一定会比未压缩后传输的效率高，相比网络传输的时间，CPU 用来压缩和解压缩的时间是可以忽略的。关于磁盘 IO 如果有大量的数据需要存储到磁盘上，然后需要读写，那么要进行压缩后存储，虽然存储便宜，但是 IO 消耗却很大，压缩后可以有效的提高 IO 吞吐量尽可能将随机 IO 模式替换为顺序 IO 模式降低每个连接的开销。一般而言，每个连接都需要一定的内存，比如一个最基本的 TCP 连接可能需要 2k 的内存；减少每个连接的开销可以支持更多的连接处理更多的事情。入口流量设计准入控制，需要有限流设计、队列设计。后端服务虽然可以自动扩缩容，但是它们的承受能力可能会有一个极限值，因此在极限值的时候就需要有限流措施，可以允许有一定的队列任务堆积，但是不能无限制的增长队列，当请求量超过一定的极限后，这个时候不能继续等待，而应该快速失败。如果持续等待，不加以限流措施，那么很可能会导致让整个系统变得更慢，从而压垮整个系统。关于通信协议，如果应用程序的组件通过外网相互通信，或者在客户端和服务器之间进行了大量通信，尽可能将文本分析协议的使用降至最低，也即是减少 xml、json 协议，而应该使用二进制协议如 pb，

弹性伸缩设计

因为可扩展和弹性伸缩是非常紧密的，因此这里也同时看看，要实现弹性伸缩，需要有哪些设计。

目前云上的架构，基本都有自动弹性伸缩功能，服务部署到公有云或者私有云上，应该是都能根据 CPU 使用率等基本指标来自动伸缩的。但是，当我们想要自己设计一个自动伸缩的架构，那么该怎么设计？

无状态服务设计

要能够弹性伸缩，服务一定是要无状态的才能比较好的保证，有状态服务的不太好实现弹性伸缩。

基础镜像轻量、快速启动

实例启动的时间很重要，如果不能快速启动，那么当检测到需要伸缩的时候，如果扩容很久才启动新实例，那么扩容期间是有损的，因此快速启动是必须的。快速启动的一个必要条件就是基础镜像要比较轻量，这样的话，从拉取镜像到启动镜像的过程就会比较快速；这个在容器时代的优势比较明显，通过 Docker 可以比较好的满足我们的诉求。