`
uule
  • 浏览: 6349024 次
  • 性别: Icon_minigender_1
  • 来自: 一片神奇的土地
社区版块
存档分类
最新评论

关于大型网站技术演进的思考(十一)--网站静态化处理—动静分离策略(3)

 
阅读更多

来源:夏天的森林

 

SSI技术

结果处理越早那么网站响应效率也就越高,所以当请求在CDN返回了,那么肯定比在apache返回效率高,在apache就返回了肯定比jboss返回的效率高

CDN技术

 

前文里我讲到了网站静态化的关键点是动静分离动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来,动静资源做好了拆分以后,我们就可以根据静态资源的特点将其做缓存操作,这就是网站静态化处理的核心思路。由此可见,网站静态化处理的核心就是动静分离和缓存两大方面,上篇我简单讲述了动静整合的基础知识,本篇将会讲述两大核心之一的动静分离策略,只有把动静分离策略做好了,缓存才能发挥出它应有的效果。

  下面我们要讨论下动静分离的策略了,一个页面什么内容是动态的,什么内容是静态的,这个我们到底该如何来区分了?这个问题学问非常大,我们的标准不同,最后拆分出来的动静资源就会存在很大的不同。在本系列开篇里,我提到了什么样的页面是静态页面,什么样的页面是动态页面,我是以一个url的角度定义的,每个独立的页面都会有一个url,这个url就好比这个页面的门牌号,我们每次访问这个url时候如果得到的响应页面都是一样的那么我们就认为该页面是静态页面,如果访问某个url,我们访问的时间不同,最后展示的页面也不一样那么这个页面就是动态页面,动态页面就是我们要进行动静分离的载体了,我们可以看到我的定义其实是和时间相关的,也就是说访问时间不同,得到的结果会不一致,所以我们可以根据时间这个维度分析页面里那些内容是静态的,那些是动态,但是这个划分在实际情况里就会变得非常复杂,下面我就讲讲这个复杂度。

  场景一:假如我们是一个商户,我们查询自己网店的交易数据,一般这个交易数据我们会放置在页面的右下部分,这个部分我们很自然把它当做动态资源,就算我们的网店交易量很小,我们也不敢把这个部分当做静态资源处理。(商户右下角交易数据)

  场景二:我们网站为了给用户一个友好的体验,会在用户登录网站后在页面某个地方显示欢迎语,例如:上午好,夏天的森林,欢迎使用我们的网站!,到了下午,这个欢迎语可能就变成了下午好,夏天的森林,欢迎使用我们的网站!,那么这块内容我们应该是当做静态内容还是动态内容呢?这个就需要思考了。(登录后友好提示)

  场景三:网站页面里会有很多图片,有些图片的确是很久很久都不会发生变化,例如网站的图标,但是有的图片却不同了,例如有一个星期我们要为某个商户做营销活动,那么营销图片这块更新后就会有一个星期的有效期,复杂点的话,我们可能会在营销活动期间在页面的某一块专设给这个商户营销活动的内容区,这个内容区使用一个html片段,但是当营销活动结束了,这个营销的图片可能就要发生变化,营销的内容区可能会被去掉,那么这些东西我们是当做静态内容还是动态内容处理了?(营销活动的活动区)

 

  由上面的场景我们可以知道,这个动静分离是要讲究策略的,如果策略设计的不好,可能我们把网站静态化处理后,效果并没有达到我们的预期。其实,我认为动静分离除了以时间维度考虑外,还应该有个维度,就是被拆分的资源是否需要服务端应用加以配合,例如像场景一交易查询这样的动态内容,我们其实需要服务端程序按照一定的业务逻辑处理请求后从存储层获取数据,那么这种动态资源是没法做静态化处理的,还有一部分资源例如场景三里的图片以及营销的html片段,这些资源写好后在有效时间内是不会发生变化的,那么这块内容虽然时效性可能会有差异,但是它却是可以在这段时间做静态化处理的,还有种情形就是场景二了,这个场景虽然使用数据需要服务端参入计算,但是计算结果在一定时间范围内是不变的,也就是说结果是可以被缓存的,那么这块的资源也是可以当做静态化资源进行处理的,为什么说拆分策略要考虑服务端应用的因素了?因为上面这些场景都是由服务端应用参入的形式所决定,在有效时间里服务端应用不需要参入,或者参入一次后,可以长期保存结果,那么我们可以把这些资源当做静态资源处理。

  除此之外,服务端应用和结果的密切度也是要当做考虑的因素的。在web开发里,除了需要浏览器处理的,其他技术都可以当做服务端来理解,如果我们网站使用到了CDN,使用到了静态web服务器例如apache,以及服务端的web容器例如jboss,那么按请求的行进路径,我们结果处理越早那么网站响应效率也就越高,所以当请求在CDN返回了,那么肯定比在apache返回效率高,在apache就返回了肯定比jboss返回的效率高,再则服务端的web容器本身因为服务端程序运行要消耗部分系统资源,所以它在处理请求的效率会比CDN和apache差很多,所以当我们按照动静分离策略拆分出了静态资源后,这个资源能不放在最底层的服务端的web容器处理就不要放在服务端的web容器里处理。

  由上所述,我们再回过头来看看静态web服务器的SSI技术,这个技术使用起来和我们在服务端使用include类似,但是在SSI使用include一定会比在服务端效率高,因为服务端在整合动静资源时候还会掺杂很多服务端程序处理,因此动静资源的效率就会大打折扣。我们再看看SSI的include的用法,如下所示:

  

<!--#include file="info.htm"-->

 

  这个写法是使用页面的注释标签,当静态web容器处理请求时候,它会扫描里面的SSI标签,接着就会处理这个标签的内容,如果找到了资源那么web容器会将资源插入到页面里,如果web没有处理这个SSI标签,那么等结果到了浏览器,这个也就是一个注释而已,不会影响页面的展示,而且SSI标签处理的资源也是非常丰富的,不管这个资源是静态的,还是动态的,只要获取时候是个完整的资源都能被正常加入到页面里,所以像前面的场景二这种动态的内容也是可以正常处理的。因此场景二,场景三这样的情况都可以使用SSI来解决。SSI的作用当然不仅仅只是可以做include操作,它的标签也可以做一些逻辑上的操作,讲述如何使用SSI不是本文的重点,有兴趣的朋友可以去研究下。

  不过SSI也有自己的局限性,它的第一个局限就是SSI解析是静态web容器来完成,因此它会消耗web容器的性能,如果SSI使用时候还有一定的逻辑,那么这种性能消耗就会更大,其实我觉得更加重要的是如果静态web容器过渡使用SSI,那么就会把自己变成了一个服务端的web容器,除了会影响到请求处理的效率,它还会降低自身的并发处理能力,所以我们希望资源整合策略交给外部服务处理效果会更好些,如是有些大型互联网公司使用ESI技术,ESI技术和缓存关系密切,这个内容我就放到下篇讨论了。

  本篇最后我要再讲讲CDN的问题,上篇我讲到静态web容器整合动静资源的好处,由此我说如果CDN可以做动静整合,那么就能做到就近处理,这样效果会更高,今天我对这个做法做了一些考证,觉得该说法有点不妥,至少我现在的公司没有使用到这样的技术,

CDN技术应该由三个步骤组成首先是解析DNS,找到离用户最近的CDN服务器,接下来CDN要做一下负载均衡,根据负载均衡策略将请求落地到最合适的一个服务器上,如果CDN服务器上就有用户所需要的静态资源,那么这个资源就会直接返回给浏览器,如果没有CDN服务器会请求远端的服务器,拉取资源再把资源返回给浏览器,如此同时拉取的资源也被缓存在CDN服务器上,下次访问就不需要在请求远端的服务器了,CDN存储资源的方式使用的是缓存,这个缓存的载体是和apache,nginx类似的服务器,我们一般称之为http加速器,之所以成为http加速器是为了和传统静态web服务器区别开来,传统的静态资源服务器一般都是从持久化设备上读取文件,而http加速器则是从内存里读取,不过具体存储的计算模型会根据硬件特点做优化使得资源读取的效率更高,常见的http加速器有varnish,squid。Ngnix加上缓存模块也是可以当做http加速器使用的,不管使用什么技术CDN的服务器基本都是做一个就近的缓存操作,这也就是说CDN是否可以完成SSI操作是值得商榷的,所以前文的说法还是有点问题的。

 

分享到:
评论

相关推荐

    《大型网站技术架构演进与性能优化》

    《大型网站技术架构演进与性能优化》这本书深入探讨了互联网行业中大型网站在技术架构上的发展路径和性能优化策略。随着互联网的飞速发展,大型网站的架构设计和性能优化成为了决定企业竞争力的关键因素。本篇文章将...

    「NGFW」关于网络安全行业生态演进的思考 - 安全架构.zip

    「NGFW」关于网络安全行业生态演进的思考 - 安全架构 信息安全 法律法规 安全管理 等级保护 网站安全

    项目架构、服务技术架构的演进(单体-SOA-微服务-中台)、网站架构的演进

    本项目采用了前后端分离的架构,后端技术栈包含SpringBoot、SpringCloud/AlibabaCloud、Redis、Ehcache、Quartz、Mybatis、SpringSecurity等,前端使用Vue3.x.js、ElementUI、Echarts等。此外,还涉及到数据库MySQL...

    携程技术演进之路-携程李小林.pdf

    ### 携程技术演进之路 #### 一、携程技术演进背景及历程 携程作为中国领先的在线旅行服务公司,其技术体系经历了从呼叫中心时代到互联网与移动互联网时代的转变,再到现今的大数据与人工智能时代的演进。这一过程...

    3G发展和演进介绍--华为技术

    3G(第三代移动通信)是21世纪初通信技术的一大飞跃,它开启了移动互联网的时代,为全球用户...通过学习华为关于3G的资料,可以深入了解3G技术的基础原理、发展脉络以及未来趋势,为通信技术的学习和研究提供宝贵资源。

    C-V2X业务演进白皮书-完整版.pdf

    C-V2X技术作为未来智能交通系统的核心组成部分,其演进不仅能够显著提升道路安全性和交通效率,还能推动整个汽车行业向更加智能化、网联化的方向发展。然而,这一过程中面临的挑战也不少,包括技术标准的统一、跨...

    大数据平台 MaxCompute 公有云多租户设计-8-4 神策数据营销策略引擎的技术演进.zip

    《大数据平台 MaxCompute 公有云多租户设计——神策数据营销策略引擎的技术演进》 在现代数字化时代,大数据已经成为企业决策的关键驱动力。阿里巴巴的MaxCompute作为一款强大的大数据处理平台,广泛应用于各行业的...

    服务运维自动化的演进与思考.6f4ab950-2975-11e7-a665-7f37c0ecc6ae.pdf

    《服务运维自动化的演进与思考》这篇文档深入探讨了服务运维自动化的发展历程,以及在这一过程中遇到的问题和解决方案。本文将围绕以下几个关键知识点进行详细阐述: 1. **自动化演进**: - **起步期**:早期的...

    美拍后端技术演进

    美拍后端技术演进的过程中涉及了多种技术与架构的选择,下面我们来详细解读美拍后端技术演进的核心知识点: 1. 美拍用户规模快速增长的技术应对策略: - 随着用户总数在2015年1月突破1亿,美拍必须迅速对后端架构...

    浏览型网站静态化架构设计2.docx

    【天猫浏览型网站静态化架构设计】是针对大型电商平台如天猫在双11等活动期间应对极高流量冲击的技术解决方案。此架构旨在确保系统在峰值请求下的可伸缩性、用户响应时间和高可用性,同时考虑安全性和成本效益。自...

    王关胜-新浪微博平台运维自动化演进之路-v1.0版.pdf

    《微博平台运维自动化演进之路》是王关胜在2016年12月17日分享的一份演讲稿,主要探讨了新浪微博在运维自动化方面的实践和演进。这份文档主要分为三个阶段:百台规模的标准化、千台规模的平台化与可视化,以及万台...

    大型网站技术架构_核心原理与案例分析_李智慧PDF高清

    《大型网站技术架构_核心原理与案例分析》是李智慧撰写的一本专著,主要针对Web开发领域的高级架构设计进行深入探讨。这本书旨在帮助读者理解并掌握构建大规模、高性能、高可用性的网站所需的关键技术与实践策略。...

    3G系统演进--推荐

    3G系统的多址方式包括FDMA、TDMA和CDMA,这些技术的组合使得3G网络能够同时处理大量用户并提供多种服务。GSM系统采用了FDMA和TDMA相结合的方式,而CDMA系统则以其独特的码分多址技术,通过给每个用户分配唯一的码...

    从大型电商架构演进看互联网高可用架构设计——内训方案.pdf

    #### 二、大型电商系统架构演进分析及背后的思考 **京东电商系统架构演进** 1. **V1.0架构**:单体架构为主,简单直接但难以应对快速增长的业务需求。 2. **V2.0架构**:引入分层架构和部分微服务架构,提高了系统...

    浏览型网站静态化架构设计.docx

    ### 浏览型网站静态化架构设计 #### 架构背景与挑战 随着电商活动规模的不断扩张,尤其是像天猫“双11”这样的大型促销活动,浏览型网站需要面对比平时高出数倍甚至数十倍的流量冲击。这种短时间内急剧增加的访问...

    数据中台演进实施方案-四川电信-v.qy.pptx

    ### 数据中台演进实施方案-四川电信-v.qy.pptx #### 一、概述 在当前数字化转型的大背景下,企业对于数据驱动的需求日益增长。四川电信为了更好地利用其丰富的数据资源,提出了“数据中台演进实施方案”。该方案...

    5G无线技术演进白皮书.pdf

    5G无线技术演进白皮书 在5G无线技术演进白皮书中,讨论了5G技术的演进和发展方向。该白皮书由多家通信公司共同编写,旨在推动5G技术的发展和普及。 1. 引言 该白皮书首先对5G技术的演进进行了概述,强调了5G技术...

    新浪微博平台运维自动化演进之路-v1.0版.zip

    《新浪微博平台运维自动化演进之路》是一份深入探讨微博平台如何逐步实现运维自动化的技术文档。这份资料详细记录了从早期的手动运维到如今高度自动化的运维体系的转变过程,揭示了在大型互联网公司中,如何通过技术...

Global site tag (gtag.js) - Google Analytics