分布式架构高可用与高并发那些在工作中常用到的那些变态应用.docxVIP

分布式架构高可用与高并发那些在工作中常用到的那些变态应用.docx

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
分布式架构高可用与高并发那些在工作中常用到的那些变态应用 2021-12-15 反向代理服务 上图呈现了一个典型的三层架构的高功能 Web 应用。这种成熟的架构多年以来已被广泛部署于包括 Google、Yahoo、Facebook、Twitter、Wikipedia 在内的诸多大型 Web 应用中。 位于三层构架中最外层的反向代理服务器担任接受用户的接入恳求,在实际应用中,代理服务器通常至少还要完成以下列表中的一部分任务: 连接管理:分别维护客户端和应用服务器的连接池,管理并关闭已超时的长连接。 攻击检测和平安隔离:由于反向代理服务无需完成任何动态页面生成任务,全部与业务规律相关的恳求都转发至后端应用服务器处理。因而反向代理服务几乎不会被应用程序设计或后端数据漏洞所影响。反向代理的平安性和牢靠性通常仅取决于产品本身。在应用服务的前端部署反向代理服务器可以有效地在后端应用和近程用户间建立起一套牢靠的平安隔离和攻击检测机制。 假如需要的话,还可以通过在外网、反向代理、后端应用和数据库等边界位置添加额外的硬件防火墙等网络隔离设备来实现更高的平安性保证。 负载均衡:通常使用轮转(Round Robin)或最少连接数优先等策略完成基于客户恳求的负载均衡;也可以使用 SSI 等技术将一个客户恳求拆分成若干并行计算部分分别提交到多个应用服务器。 分布式的 cache 加速:可以将反向代理分组部署在距离热点地区地理位置较近的网络边界上。通过在位于客户较近的位置供应缓冲服务来加速网络应用。这实际上就构成了 CDN 网络。 静态文件伺服:当收到静态文件恳求时,直接前往该文件而无需将该恳求提交至后端应用服务器。 动态响应缓存:对一段时间内不会发生转变的动态生成响应进行缓存,避开后端应用服务器频繁执行反复查询和计算。 数据压缩传输:为前往的数据启用 GZIP/ZLIB 压缩算法以节省带宽。 数据加密爱护(SSL Offloading):为与客户端的通信启用 SSL/TLS 加密爱护。 容错:跟踪后端应用服务器的健康情况,避开将恳求调度到发生毛病的服务器。 用户鉴权:完成用户登陆和会话建立等工作。 URL别名:对外建立统一的url别名信息,屏蔽真实位置。 应用混搭:通过SSI和URL映射技术将不同的web应用混搭在一起。 协议转换:为使用 SCGI 和 FastCGI 等协议的后端应用供应协议转换服务。 目前比较出名的反向代理服务包括:Apache httpd+mod_proxy / IIS+ARR / Squid / Apache Traffic Server / Nginx / Cherokee / Lighttpd / HAProxy 以及 Varnish 等等。 应用服务 应用服务层位于数据库等后端通用服务层与反向代理层之间,向上接收由反向代理服务转发而来的客户端访问恳求,向下访问由数据库层供应的结构化存储与数据查询服务。 应用层实现了 Web 应用的全部业务规律,通常要完成大量的计算和数据动态生成任务。应用层内的各个节点不肯定是完全对等的,还可能以 SOA、μSOA 等架构拆分为不同服务集群。 上图给出了一个典型的高并发、高功能应用层节点工作模型。每个 Web 应用节点(在图 5中由标有App字样的方框表示)通常都会工作在本人的服务器(物理服务器或VPS)之上,多个应用节点可以有效地并行工作,以便利地实现横向扩展。 1、在上图所示的例子中,Web 应用节点由 IO 回调线程池、Web 恳求队列以及后台工作线程池等三个重要部分组成,其伺服流程如下: 2、当一个 Web 恳求到达后,底层操作系统通过 IOCP、epoll、kqueue、event ports、real time signal (posix aio)、/dev/poll、pollset 等各类与具体平台紧密相关的 IO 完成(或 IO 就绪)回调机制通知 AIO(Asynchronous IO)回调线程,对这个已到达的 Web 恳求进行处理。 3、在 AIO 回调池中的工作线程接收到一个已到达的 Web 恳求后,首先尝试对该恳求进行预处理。在预处理过程中,将会使用位于本地的高速缓存来避开成本较高的数据库查询。假如本地缓存命中,则直接将缓存中的结果(仍旧以异步 IO 的方式)前往客户端,并结束本次恳求。 3、假如指定的 Web 恳求要求查询的数据无法被本地缓存命中,或者这个 Web 恳求需要数据库写入操作,则该恳求将被 AIO 回调线程追加到指定的队列中,等待后台工作线程池中的某个空闲线程对其进行进一步处理。 4、后台工作线程池中的每个线程都分别维护着两条长连接:一条与底层到数据库服务相连,另一条则连接到分布式缓存(memcached)网络。通过让每个工作线程维护属于本

文档评论(0)

bob157641554 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档