高并发互联网应用解决方案

       最近一个项目上的需求:要求在短期内通过媒体发布消息,统一通过互联网上的某入口进行预约办理业务。此需求涉及到高并发互联网应用的解决方案。

一、简介

典型网格架构示意图

二、网络架构优化

2.1域名负载均衡

动态DNS英语:Dynamic DNS,简称D-DNS)是一种把互联网域名指往可变IP地址的系统。简单的说,动态域名可以在你的电脑每次上网得到新的IP之后,自动设置了新域名的指向,使网上其他任何人访问该域名时,始终能定向到你机器的最新的正确IP上去,从而使得人们能使用一个能记忆的,对用户来说是永远不变的域名来访问你那台IP每天都在变化的机器。从而也就能实现了将个人电脑变成可以供任何人访问的“服务器”了。

当然,我所关心的是动态DNS技术在负载均衡方面的应用,那么让我们看看其实现原理:

DNS负载均衡技术的实现原理是在DNS服务器中为同一个主机名配置多个IP地址,在应答DNS查询时,DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果,将客户端的访问引导到不同的机器上去,使得不同的客户端访问不同的服务器,从而达到负载均衡的目的。

主要优点

这种技术的主要优点如下:

第一,技术实现比较灵活、方便,简单易行,成本低,适用于大多数TCP/IP应用。不需要网络专家来对之进行设定,或在出现问题时对之进行维护。

第二,对于Web应用来说,不需要对代码作任何的修改。事实上,Web应用本身并不会意识到负载均衡配置,即使在它面前。

第三,Web服务器可以位于互联网的任意位置上。

主要缺点

DNS负载均衡技术在具有以上优点的时候,其缺点也非常明显,主要表现在:

第一,不能够按照Web服务器的处理能力分配负载。DNS负载均衡采用的是简单的轮循负载算法,不能区分服务器之间的差异,不能反映服务器的当前运行状态。所以DNS服务器将Http请求平均地分配到后台的Web服务器上,而不考虑每个Web服务器当前的负载情况。如果后台的Web服务器的配置和处理能力不同,最慢的 Web服务器将成为系统的瓶颈,处理能力强的服务器不能充分发挥作用。不能做到为性能较好的服务器多分配请求,甚至会出现客户请求集中在某一台服务器上的情况。

第二,不支持高可靠性,DNS负载均衡技术没有考虑容错。如果后台的某台Web服务器出现故障,DNS服务器仍然会把DNS 请求分配到这台故障服务器上,导致不能响应客户端。

第三,可能会造成额外的网络问题。为了使本DNS服务器和其他DNS服务器及时交互,保证DNS数据及时更新,使地址能随机分配,一般都要将DNS的刷新时间设置的较小,但太小将会使DNS流量大增造成额外的网络问题。

第四,一旦某个服务器出现故障,即使及时修改了DNS设置,还是要等待足够的时间(刷新时间)才能发挥作用,在此期间,保存了故障服务器地址的客户计算机将不能正常访问服务器。

2.2CDN

对于大型网站来说增加CDN这一层是非常有必要的,CDN(Content Delivery Network,内容分发网络),它属于网络范畴的一个技术,它依靠部署在各个区域的边缘服务器,实现负载均衡、内容分发调度等功能。它使得用户就近获取内容,降低网络堵塞,提供用户访问响应速度。网络应用的很大一部分由静态资源构成,如图片、CSS样式文件、JavaScript脚本以及一些针对特定产品提前渲染好的页面等,通过使用缓存,对于一些客户的请求,不一定都去重新处理一遍,使用缓存,提高访问速度。遍布各地的CDN使得用户可以从物理上靠近他们的地方来获取网页内容,而不是每次都把数据从源头搬到用户那里。

来举一个通俗点的例子:小明公司做了了一个针对全国用户的业务,服务器放在了北京,但是深圳用户在访问网站的时候非常卡顿,有时候甚至访问不到。经排查,造成该问题的原因是深圳用户所在网络到北京的机房延迟非常大。小明想到了一个办法,他在深圳的某机房假设了一台服务器,把北京服务器上的文件传输到深圳的服务器上,当深圳用户访问网站时,让该用户直接去访问深圳的服务器,而不是访问北京的服务器。同理,其他城市也效仿深圳假设了类似的服务器,这样全国各地的用户访问公司业务都很顺畅了。

例子中的解决方案其实就是CDN实现原理,当然,真正的CDN技术要复杂得多,要考虑很多问题,比如边缘服务器的分布、机房的网络、带宽、服务器的存储、智能DNS解析、边缘服务器到真实服务器之间的网络优化、静态和动态资源的区分、缓存的优化、压缩、SSL等等问题。关于这些细节技术我不做过多解释,但希望大家能通过我的描述了解CDN在架构中存在的意义。

CDN是处于整个架构体系中最前端的一层,它是直接面对用户的,CDN会把静态的请求(图片、js、css等)直接消化掉,然后把动态的请求往后传递。实际上,一个网站(比如,淘宝网)超过80%的请求都是静态的请求,那也就意味如果前端架设了CDN,即使并发1亿,也只有2000万到了后端的WEB上。那么你可能会问,CDN能支持8000万的并发吗?这个主要取决于CDN厂商的实力,如果他们搞10000个节点(即边缘服务器),每个节点上消化8000并发,如果搞10万个节点,每个节点只需要消化800个并发而已。然而,一台普通的Nginx服务器(配置2核CPU4G内存)轻松处理5万个并发(前提是做过优化,并且处理的请求是静态请求、或者只是转发请求)。

2.3带宽

无论上边提到的域名负载均衡还是多台就近CDN,都要注意网络的带宽瓶颈。例如,动态域名的多个IP最好是分布在不同的链路和网络上,这样效果明显。如果多个IP处于同一机房的同一网络链路上,网络压力还是不能减轻,那么域名负载均衡对网络压力就没有缓解的效果。

3、服务优化

3.1动静分离

       大家都知道,效率最高、消耗最小的就是纯静态化的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站,我们无法全部手动去挨个实现,于是出现了我们常见的信息发布系统CMS,像我们常访问的各个门户站点的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管理、权限管理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。

  除了门户和信息发布类型的网站,对于交互性要求很高的社区类型网站来说,尽可能的静态化也是提高性能的必要手段,将社区内的帖子、文章进行实时的静态化、有更新的时候再重新静态化也是大量使用的策略,像Mop的大杂烩就是使用了这样的策略,网易社区等也是如此。

  同时,html静态化也是某些缓存策略使用的手段,对于系统中频繁使用数据库查询但是内容更新很小的应用,可以考虑使用html静态化来实现。比如论坛中论坛的公用设置信息,这些信息目前的主流论坛都可以进行后台管理并且存储在数据库中,这些信息其实大量被前台程序调用,但是更新频率很小,可以考虑将这部分内容进行后台更新的时候进行静态化,这样避免了大量的数据库访问请求。

       对于Web服务器来说,不管是Apache、IIS还是其他容器,图片是最消耗资源的,于是我们有必要将图片与页面进行分离,这是基本上大型网站都会采用的策略,他们都有独立的、甚至很多台的图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不会因为图片问题而崩溃。

  在应用服务器和图片服务器上,可以进行不同的配置优化,比如apache在配置ContentType的时候可以尽量少支持、尽可能少的LoadModule,保证更高的系统消耗和执行效率。

3.2流量优化

图片缩略显示图不要用原图,可以生成静态的缩略图以减轻流量压力。JS库也要采用压缩的模式不要用开发调试模式。从内容上尽量减少下载的数据量。

3.3数据库优化

将数据库的最大连接数调大,同时调大数据链接池的空闲连接数。

3.4缓存优化

Redis 是一个高性能的key-value数据库。 redis的出现,很大程度补偿了memcached这类key/value存储的不足,在部 分场合可以对关系数据库起到很好的补充作用。它提供了Java,C/C++,C#,PHP,JavaScript,Perl,Object-C,Python,Ruby,Erlang等客户端,使用很方便。

 对频繁访问且更新频率低的数据,放到redis里,由于redis里的数据存于内存之中,这样减少了对磁盘的访问从而提升了服务的吞吐量。

3.5队列优化

MQ,就是简单的在队列中插入一条消息,这个时间成本,显然比B服务的时间要低。而B服务,会自己去MQ读取相关消息,并进行相应的操作,如插入日志等。

MQ,消息队列,消息可以理解为一个业务现场,而队列则是保存这个业务现场的容器,而B服务对消息的处理,则是一个对业务现场的异步处理。所以,消息队列的本质,就是将某个业务现场暂存下来,异步处理。

优点如下:

1. 异步。正如上面的demo,异步就是MQ的第一个能力。可以将一些非核心流程,如日志,短信,邮件等,通过MQ的方式异步去处理。这样做的好处是缩短主流程的响应时间,提升用户体验。

2. 解耦。假设现在,日志不光要插入到数据库里,还要在硬盘中增加文件类型的日志,同时,一些关键日志还要通过邮件的方式发送给指定的人。那么,如果按照原来的逻辑,A可能就需要在原来的代码上做扩展,除了B服务,还要加上日志文件的存储和日志邮件的发送。但是,如果你使用了MQ,那么,A服务是不需要做更改的,它还是将消息放到MQ中即可,其它的服务,无论是原来的B服务还是新增的日志文件存储服务或日志邮件发送服务,都直接从MQ中获取消息并处理即可。这就是解耦,它的好处是提高系统灵活性,扩展性。

3. 消峰。这个其实也很好理解,因为MQ的本质就是业务的排队。所以,面对突然到来的高并发,MQ也可以不用慌忙,先排好队,不要着急,一个一个来。消峰的好处就是避免高并发压垮系统的关键组件,如某个核心服务或数据库等。

异步,解耦,消峰,MQ的三大主要应用场景。

采用MQ对请求进行处理,当服务无法及时响应请求时放到MQ里暂存来缓解峰值对服务的压力。

3.6Nginx调优

Nginx调优最核心的参数有两个:

1、worker_processes auto;  #这样nginx会自动根据核心数为生成对应数量的worker进程。

2、events {

        use epoll;   #采用Linux下epoll模型,比传统的select模型性能提高一个数量级

        worker_connections  65535;

    }




最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,639评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,277评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,221评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,474评论 1 283
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,570评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,816评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,957评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,718评论 0 266
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,176评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,511评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,646评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,322评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,934评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,755评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,987评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,358评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,514评论 2 348