如何设计高性能的大型网站系统？在移动互联网时代，客户端应用开发本身，并不是体验的决胜之处，真正对团队挑战的地方，还在于后端，无论是承压能力，还是安全性等方面，如果这些地方过不了关，整个应用的基础是不扎实的。

       提高服务器性能最简单粗暴的方式，就是增加机器和升级硬件配置。虽然现在的硬件越来越便宜，但是一味地通过增加机器来解决并发量的增长，成本是非常高昂的。结合技术优化方案，才是更有效的解决方法。

一、web端性能

       这几年，用户数量并没有出现指数增长，而并发连接数呈指数增长的主要原因是：1、Web页面元素越来越多，更为丰富；2、主流的本浏览器的预加载功能。

       （1）、建立长连接。减少反复的创建和销毁连接行为。但是，连接的保持是会占用Web系统服务端资源的，如果不充分使用这个连接，会导致资源浪费。

       （2）、通过缓存减少Web请求。通过Http协议头中的expire或max-age来控制，将静态内容放入浏览器的本地缓存。但是，这种方案，对首次访问的用户无效，同时，也影响部分Web资源的实时性。

       （3）、通过版本号减轻Web请求。协商方式是通过Http协议的Last-Modified或Etag来控制，这个时候请求服务器，如果是内容没有发生变更的情况，服务器会返回304 Not Modified。但是，，但是连接仍然被建立，请求也发生了。

       （4）、合并页面请求。1、合并HTML展示内容。将CSS和JS直接嵌入到HTML页面内，不通过连接的方式引入。2、Ajax动态内容合并请求。对于动态内容，将10次Ajax请求合并为1次的批量信息查询。3、小图片合并，通过CSS的偏移量技术Sprites，将很多小图片合并为一张。4、压缩css，js，图片的大小。

       （5）、页面静态化。页面上的大部分内容在很长一段时间内，可能都是没有变化的。例如一篇新闻报道，一旦发布几乎是不会修改内容的。这样的话，通过CGI生成的静态html页面缓存到web服务器的磁盘本地。

二、app端性能。
       （1）图片三步加载。从内存、磁盘、网络三个方面上进行三级缓存的实现。1、在加载一张图片的时候，先查看内存是否有该图片的缓存，若无，再查看磁盘时候有该图片的缓存，若无，才从网络中加载；2、在网络加载完成之后，需要把图片加进到内存和磁盘缓存中；3、根据LRU调度方式对缓存进行管理。

       （2）预加载技术。基于历史浏览记录和对该网页的安全性判断，在你没点击请求之前，预先加载这个数据。

       （3）路由计划表。对用户每天登陆的上网行为和不同行为连接哪个机房，做了一个路由计划表，推送到客户终端上。当用户的网络发生切换，我们就知道这个网络情况下他应该连到哪里最快。

       （4）上传加速。在全国部署了超过70个上传加速节点，让每个用户都会选择他最近的上传节点上传他的图片。同时有启用多端口、多连接的上传加速能力，可以尽可能的用尽网络资源，而不是说在一个连接上不停的等待数据包的重传等各方面的东西。

三、带宽

        计算带宽要涉及到两个指标(页面平均大小、全天pv), 可以从access日志统计到详细数据。平均流量 = (全天pv/(24*60*60)) * 页面平均大小。峰值流量 = 平均流量 * 5。需购买的带宽等于峰值流量。

        但是活动日的峰值流量远不止这个数。2015年微信红包除夕摇一摇总次数110亿次，峰值1400万次/秒。应对活动日，需提前在活动当天CDN将准备数百G带宽应对。

四、后台性能。

       大型网站不是设计出来的，而是逐步演化出来的。因为互联网发展运行有其自己的规律，互联网历史已经一再证明“一开始就把网站设计成大型的”这种企图行不通。另外，演化过程中，需要分清当前哪个点是瓶颈，需要知道哪个点优化的优先级最高。所以，技术架构的演进不一定就是按文章从头到尾这样列下来的，要视具体情况来下决定。

       从一个小网站说起，一台服务器也就足够了。演进包括如下：

       （1） 数据服务器和应用服务器分离。给应用服务器配置更好的 CPU，内存。而给数据服务器配置更好更大的硬盘。

       （2）使用缓存。因为 80% 的业务访问都集中在 20% 的数据上，如果我们能将这部分数据缓存下来，性能一下子就上来了。空数据也要入缓存，否则会增加数据库的压力。

       （3）nosql。NoSql数据库大量应用于微博系统等事务性不强的系统。如：BigTable、MongoDB 

       （4）服务器集群。需要考虑：负载均衡问题? 负载均衡调度服务器，如nginx。Session 的管理问题。如何让上传文件这些类似的功能继续正常？采用文件服务器统一管理。

       （5）数据库读写分离。订阅和发布。实现一个数据访问模块使上层写代码的人不知道读写分离的存在。需要考虑：时延问题。MySQL数据同步是通过binlog日志。延迟问题通过水平拆分服务来提高性能、多线程同步解决。

       （6）数据库拆分。垂直拆分数据库时，会遇到的问题：跨业务的事务，应用的配置项多了。数据水平拆分会遇到的问题：SQL 的路由问题，需要知道某个 User 在哪个数据库上。主键的策略会有不同。查询时的性能问题，如分页问题。

       （7）CDN。分布式文件系统使用 CDN 。将网站的内容发布到最接近用户的网络”边缘”，使用户可以就近取得所需的内容，解决Internet网络拥塞状况，提高用户访问网站的响应速度。据统计，采用CDN技术，能处理整个网站页面的 70%～95％的内容访问量，减轻服务器的压力，提升了网站的性能和可扩展性。异地部署一般遵循：核心集中，节点分散。如：网宿、睿江、蓝讯，将网站内容同步到全国CDN节点，客户就近访问CDN服务器。

       （8）分布式拆分。网站的业务日益复杂，建立一个独立的大型应用来完成这所有的业务变得不实际。从管理角度来，也不方便管理。将系统根据职责进行拆分，同时也能采用大量的廉价机器来支撑着巨大的访问量和数据量。微服务架构的优势很明显：耦合度低、技术选型灵活、发布更加高效、故障隔离。拆分会碰到很多的挑战：1、拆成分布式后需要提供一个高性能、稳定的通信框架，并且需要支持多种不同的通信和远程调用方式；2、将一个庞大的应用拆分需要耗费很长的时间，需要进行业务的整理和系统依赖关系的控制等；3、如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。

       （9）大系统小做。将功能复杂较大的系统，化大为小，减少模块耦合，降低关联性。分成一个个高度自制的小系统，形成高内聚低耦合的格局，每个模块之间不会过分依赖对方，这样的好处是不会因为任何一个模块而影响全部服务，避免牵一发动全身的风险，实现真正的灰度服务。 

       （10） 硬件负载均衡。一台Nginx服务器的软负载已经无法承担巨大的web访问量了，可以用硬件负载解决F5或应用从逻辑上做一定的分类，然后分散到不同的软负载集群中。

五、业务方式

       有些问题用技术手段并不比用业务手段更有效。12306 的分时卖票就是一个典型例子。

       （1）前端缓冲请求。比方说在接入层置入摇红包逻辑，将每秒千万级请求转化为每秒万级的红包请求，再传到红包服务的后端逻辑，降低雪崩的可能性。

       （2）后端采用异步分拆。耗时最长的入账操作，直接跳过，异步处理。如：“当前人数较多，收到的红包将稍后入账零钱”

       （3）快速拒绝。在客户端的版本更新中，将相关的指令和策略埋入，当接受数据获取异常时，在客户端自动就降低请求频率，比如一次请求失败，用户肯定想二次再刷，但是可能实际上没有向后端请求，而是直接返回，请客户稍安勿躁，如果不提前埋入，到有问题时才处理是来不及的。

       （4）流量预加载。从客户端入手，将语音图片等极消耗流量的资源提前让客户端自动下载预置好，提前将流量洪峰疏导。

       （5）资源隔离。避免任意一个支路出问题影响整个服务链条，这样即使部分服务出现问题也不会影响到整个服务的崩塌。

       （6）根据业务场景降低图片质量。1、针对不同终端，下载不同质量图片。2、研究新的编码格式，使得图片在基本同等质量情况下再下降30%。3、应用一些渐进式的传输技术，你会首先看到模糊的图，一会儿清晰的图就会出现。

       （7）回滚机制会造成业务逻辑复杂，容易出错，可能会出现漏洞。我们应该提高服务的简单性、高可用性，减少出错率。对于极少的错误，后续对日志进行单独处理即可。

六、最大连接数限制

       （1）全程压测流程，对整个业务链接进行自动提前评估，防止过载。

       （2）柔性可用要求我们对各种特性一开始就是分好级别（登录>文本消息>图片消息>好友状态呈现>键盘活动提示）。

       （3）模块间调用的超时时间如果设置不合理，会导致柔性策略失效。A调用B是300ms超时，B调用C是500ms超时；B对c有柔性，调用c超时的时候会柔性的继续往下，但是这个没有意义。

       （4）如果成功率高于95%，才可以重试，否则接口层拒绝。