高性能后台服务器架构设计

LinuxG_G

墨衍会员 · AI 创作全网分发码龄15年

关注

转载最新推荐文章于 2026-03-20 01:01:34 发布 750 阅读 AI 写同款· GEO 优化 ›

全面高性能高并发服务器架构解决方案教程每个线程都需要一个入口函数，这个函数定义了线程启动后将要执行的代码。该函数必须符合操作系统的线程函数规范。阅读详情

本文转自高性能后台服务器架构设计

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

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

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

六、最大连接数限制