目录
减少请求次数：减少前端脚本与后端服务的请求次数，有三种方案：
设计一个千万级流量的架构
对于这个问题，需要从系统的全链路视角，从前端请求到后端服务评估，各环节性能指标，要从全链路的视角进行高性能的设计。
1、前端优化
三个环节：减少请求次数、页面静态化、边缘计算
减少请求次数：减少前端脚本与后端服务的请求次数，有三种方案：
1.1、增加缓存控制：
前端研发经常会设置HTML的缓存头部（Cache-Control头），这样浏览器在请求同一个文件时，只访问本地保存的资源副本，从而加速文件的访问速度。
1.2、减少图像的请求次数
大部分网站会将所有用到的多张图片拼成一张，这样多张图片只需要下载一次，然后通过CSS中的background-image和background-position来定位目标位置选择显示哪一张图片。
1.3、减少脚本的请求次数
通用的做法就是CSS压缩和JavaScript压缩，将多个文件压缩成一个，目的是减少传输文件的大小，而更重要的是减少请求数。
而页面静态化就是缓存的一种方式，相当于把整个页面元素缓存起来，那么缓存到了那里？
通常是将页面问及那先存储到CDN节点中，比如将商品详情页做静态化，就是将商品详情页的页面元素存储到CDN节点，然后所有请求就可以直接以由CDN来提供服务，不会到达后端，减少对后端服务的压力。
边缘计算被很多人提及，原因是大数据处理的实时性越来越高，由集中式的服务系统提供实时性的计算能力捉襟见肘，所以很多大厂开始将计算能力放到距离用户最近的CDN节点中，这就要求原有的CDN节点不只作为静态资源文件的缓存，而是要提供可以定制化的计算能力。
2、后端优化
可以从基础设施层面、网络层面、架构层面三个角度进行考量。
网络层面可以考虑网络专线、CDN优化；
架构层面可以考虑动静态分离、集群优化、数据隔离、服务拆分、异步驱动、负载均衡等
3、高性能设计中的“道”
设计高性能系统架构师，首先是清楚认知系统的硬性性能指标。
指数需求：我们要保证系统的TP 99为2s;
表面意思：系统要保证99%的请求的相应时间都在2s内；
深层意思：对有经验的架构师来说，这样说的需求是不明确的，任何系统都有自己的承受能力范围，换句话说就是在并单用户数限定范围内，一定要保证系统 TP99=2s，例如：“我们要保证系统并发数在100万用户内的时候，有所不能”。
所以，对一个架构师而言，要一个高性能架构至少有以下4个系统设计思考步骤。
明确指标：比如系统小于100万并发用户时，保证系统的TP 99为2s;
保护系统：当系统并发用户量超过100万，要做到保证有100万用的TP99=2s;然后保护系统，并拒绝其他用户连接请求。
用户体验：为了用户体验，要给系统承载容量外的用户提供优雅的体验，比如如服务器排队机制，并附加具体，明确的信息提示。
快速扩容：这一步很容易被忽略，如今系统的性能指标还有一点就是贵在快速反应，比如能承诺出现并发用户数量的TP99=2s;
在明确了性能之后，高性能架构的落地工作，可以氛围以下三个关键技术点：
做好系统限流：通过流量控制来保证系统稳定性。当实际并发压力超过系统性能设计指标的时候，就拒绝新的请求连接，让用户进行排队。
做好快速扩容：对于扩容能力，一般要储备额外的计算资源，用于不时之需，也就是事先通过预估流出一部分资源池。
会有人疑惑，既然有多余的资源为什么不提前扩容呢，只是处于对IT成本的考虑，作为系统设计者要把成本作为系统的设计原则之一。
另一个关键因素是系统的扩容速度，这是当今互联网软件中非常重要的系统能力之一，就算架构设计的不够优雅单如果相应速度够快，也就是能解决问题。
做好系统优化：结合上述后端优化，补充：性能设计要贯穿于系统建设的始终，以一个系统的研发管理过程为例，内容大致包括：需求阶段，设计阶段，研发阶段，测试阶段，上线阶段，运行阶段。
对于性能设计，（不仅仅是性能设计，所有的非功能性的设计）要在项目的各个阶段进行考虑，以便根据项目过程的推进，随时进行优化和调整。
未雨绸缪ing......
514
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
