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

  • 高性能后台服务器架构设计已关闭评论
  • 78 views
  • A+
所属分类:编程开发
如何设计高性能的大型网站系统?在移动互联网时代,客户端应用开发本身,并不是体验的决胜之处,真正对团队挑战的地方,还在于后端,无论是承压能力,还是安全性等方面,如果这些地方过不了关,整个应用的基础是不扎实的。
       提高服务器性能最简单粗暴的方式,就是增加机器和升级硬件配置。虽然现在的硬件越来越便宜,但是一味地通过增加机器来解决并发量的增长,成本是非常高昂的。结合技术优化方案,才是更有效的解决方法。

一、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%,才可以重试,否则接口层拒绝。
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 微信公众号
  • 微信公众号扫一扫
  • weinxin
avatar