ESI
上篇我补充了下SSI的知识,SSI是一个十分常见的技术,记得多年前我看到很多门户网站页面的后缀是.shtml,那么这就说明很多门户网站都曾经使用过SSI技术,其实现在搜狐网站也还在用shtml,如下图所示:
由此可见SSI在互联网的应用还是非常广泛的。其实互联网很多网页如果我们按照动静分离策略拆分,绝大部分都是可以当做静态资源处理,例如新闻网站,文学网站,这些网页生成后,大部分的资源都是不变的,说白了这些网页本质就是一个静态页面,我们开发他们时候也不需要服务端的参入,每一个网站都有自己固定的板式,假如每个新网页都要完完整整的开发,重复性的工作实在太多了,出错的概率也非常高,在本系列第二篇里我曾经详细介绍了velocity的布局模板技术,其实SSI也可以制作出一套固定的模板,开发时候我们只需要在定义好的模板里添加或者修改我们需要更改的内容就可以完成一个页面的制作,可见SSI技术为了我们开发网页提供了很大的便利。
与SSI相对应的还有ESI,这个技术不是太常用,在网上能收集到的资料也不是太多,网上有限的资料也基本都是和淘宝相关的,不过仔细研究下淘宝对ESI的运用,对于理解网站静态化处理是非常有借鉴意义的,下面我将重点讲讲ESI的知识。首先看个场景啊。
我们登录支付宝网站,到了个人首页我们发现在支付宝下面有一个条目,如下图所示:
这是支付宝默认给我们显示的【生活好助手】,右边有个箭头,我们点开它,如下图所示:
我们看到这里有添加的按钮,通过添加按钮,我们可以添加其他常用的组件图标。(注意:我这里只是以支付宝这个功能为例,支付宝是否按照我说的设计,这个我就不清楚了)
如果我们按照自己个性化添加了自己的组件,不同的人添加的常用组件也会是不尽相同的,如果我们自己开发的网站也有这样的功能,那么我们该如何设计了?我们一般都会很直观的把这个新增的组件信息存储在数据库里,用户每次登录时候该信息也会随之从数据库里读取,但是这个场景对于像支付宝这种用户量极大,日均访问量极高的大型网站,这种个性化又非核心的功能都从数据库里读取,那么它对数据库造成的压力一定是十分巨大的,在存储的瓶颈里我们讲了那么多优化数据库的手段,其核心手段有一个就是减少对数据库价值不高的操作,而这种个性化配置跟支付宝的支付操作相比起来,价值度实在太低,因此我们最好的选择是避免数据库承担过多此类的操作。
不过像上面这个场景里的功能,它所使用的数据又不是那种可有可无的,假如数据存储的不可靠造成数据丢失还是会造成不必要的麻烦,所以我们还是会把这些信息做持久化存储。此外像上面的【生活好助手】条目还是页面的一个重要组成部分,因此像SSI那种使用html注释指令,当指令无法正常解析,就直接返回到浏览器,因为是注释,所以页面也不会显示它,SSI的这种做法用在上面场景肯定是不太合适的。这样的场景在电商网站里是十分常见的,例如一个商品页面,页面里会有商品的图片,还有商品的详细介绍,这些内容其实都是会用持久化系统进行存储,同时它们本身也是网页的重要做成部分,如果碰到问题就忽略最终会造成页面显示错误。
结合上面的场景我们来讨论下ESI技术了,ESI技术和SSI技术类似,其实也和jsp里的include指令类似,它也是在页面里使用一个指令标签web容器解析这个标签后将获取的数据替换掉这个标签。我们来看看ESI的使用方法,我们可以在velocity里自定义一个esi标签,velocity里的使用如下所示:
esiTool.setTemplate('test.vm').addQueryData('id', 100)
velocity引擎解析vm模板,最终会把vm解析成html页面,这个时候该页面里使用esi标签的地方就被转化为:
<esi:include src="test.vm.esi?id=100" />
当页面到了服务端web容器之前的静态web容器(该web容器要安装好解析esi的模块),静态web容器就会解析这个esi标签,静态web容器会以test.vm.esi?id=100 作为key,到缓存系统里查找信息,如果查到了信息,缓存服务器就直接返回,用返回内容替换掉esi标签,如果缓存里没有找到则会直接请求持久化系统,持久化系统返回信息后,缓存系统将信息缓存起来,同时也将信息返回至静态web容器,那么下次用户再访问同样内容就会直接从缓存里读取了。
ESI技术和SSI很像,只不过ESI技术是和缓存技术配合起来的,同时ESI标签也不像SSI标签那样使用注释的形式,因此ESI标签是一定要被解析的,如果仅仅是缓存,ESI和SSI比较起来也没显得那么有优势和特别,但是对于电商这种场景而言ESI的现实意义非常大,电商网站也是一个由用户产生内容的网站,每一个商家的店铺虽然我们都知道它是属于淘宝或天猫的,但是单独一个商家的店铺都是个性化很强的,与其他店铺差异很大,为了买卖商品,商家会上传自己商品的图片,还会使用图片和文字描述自己的商品,单个商品页面我们做动静分离分析,很容易分辨出动态内容和静态内容,但是如果一个电商平台拥有超乎想象数量的商家,那么每个页面的图片,文字和商家页面的关系就会变得有点微妙了。由于电商网站的图片特别多,那么电商网站系统一般都会设计一套管理这些小图片的分布式存储系统,例如淘宝的TFS文件系统,它是专门针对图片使用的分布式文件系统,这些文件系统里存储的图片会和商家紧密关联,这就让图片本身拥有了一定的动态属性,但是对于每个商家页面而言,商家自己的图片资源都是可以静态化的,也就是说图片的读取是要通过商家信息进行计算的,计算出的结果对于商家而言又是静态的,可以被缓存的。但是这个静态资源的处理时候就变得复杂了,而这些是SSI无法完成的。
首先我们直接从文件系统读取图片,效率是非常低效,因此我们还是会把它们缓存在内存里,但是由于不同图片和不同商户是相关联,那么对于缓存查找时候是需要一定的条件,不同商户对自己页面的设计方案也会有所不同,一般商户这些资源,存储系统肯定会按照设计模板的维度存储,不同商家由于商品和文化的不一样,那么使用的模板也不一样,因此资源返回静态web容器前还需要一个整合过程,这样场景下的静态资源获取其实是需要一定逻辑计算的,那么这个计算一般都会在开发时候由代码完成,所以从上面ESI使用的例子看到,开发人员会使用velocity的esi标签,这个标签开发人员可以设置参数,velocity引擎最终会将这个标签解析成静态web容器可以解析的esi标签,标签里有这样的代码test.vm.esi?id=100,文件后面会带上参数,那么这个参数其实是动态的,那么这个参数也就是缓存系统获取正确信息的规则了。这样我们就完成了静态资源获取的逻辑计算,计算完毕后这些资源会在一段时间里长期有效,因此它就演变为静态资源,可以被缓存了。ESI比SSI强大多了,同时ESI也可以完成SSI的功能,所以使用了ESI也就没必要用SSI了。
像我们平时做web开发时候可能没有太留心一个问题,一般的web开发里使用的静态资源例如图片,css文件,js文件我们都会放置在一个resource包里,如果是企业开发,这个web应用上线时候也就直接打包在web工程里,一些互联网网站也只不过会将这些资源放置在单独的静态服务器上,我平时开发时常听到有人说,项目里图片太多了,应该合并下,css文件和js文件也太多了也要合并下,这个多到底多多少了,几十个文件,几百个文件,这个要和社交网站,电商网站这种用户可以产生图片的网站比起来那就是小巫见大巫了,因为用户能产生内容的网站静态资源会随着时间推移文件规模变得异乎寻常的大,所以此类网站的静态资源已经没法放置在项目下,它就要求我们需要有新的手段管理这些静态资源,并且有新的手段使用这些静态资源,那么像TFS文件存储系统出现了,缓存技术出现了,最后我们在应用里使用ESI技术把它们整合到我们网页里,通过这个分析我们就能明白ESI适用的业务场景了。
网站静态化处理我们首先要按规则拆分动静资源,拆分出来的静态资源该如何处理就是网站静态化处理的关键所在,把静态资源处理从服务端的web应用里剥离出来,不让服务端的web应用参入过多的静态资源解析,这样就可以为服务端的web应用减少不必要的处理操作,从而达到提升服务端web应用的运行效率,接着我们就把拆分出来的静态资源处理操作往前推移到静态web服务器,前两篇文章和今天的文章我着重讲解了静态web服务器处理静态资源的手段,那么这里有个问题了,这些处理可以再往前推到浏览器来完成吗?答案当然是否定的,首先浏览器的缓存是非常不可靠的,如果用户把浏览器设置为不缓存任何数据的模式,那么浏览器就没法缓存数据了,而用户的行为那是根本没法控制的,其次浏览器缓存的数据量是有限的,如果我们要在浏览器进行缓存也是缓存最有价值缓存的数据,更重要的一点,为了做好网站静态化处理我们对网页的动静资源做了拆分,但是拆分出的静态资源也并不是完全不需要进行任何逻辑处理就能使用的,例如前面讲到的ESI适用的场景我们就发现,有些静态资源的获取还是要很多条件的参入,而这些条件是由动态数据产生的,那么这样的静态数据浏览器是没法做缓存的,这点也说明了拆分出来的静态化资源绝大部分还是要停留在服务端的,居然只能停留在服务端,那么最为高效的处理这些静态资源的地方就是CDN和静态web容器了。所以在本系列的第一篇里我讲到网站生产部署时候最好是在服务端web应用之前放置一个静态web容器,如果有了这样的静态web容器做反向代理,那么我们就可以让它来完成静态资源的相关操作,而且静态web容器还能辅助完成一些逻辑上的处理,从而弥补了CDN的不足之处。当然这么做的好处不仅仅只有这些,第二篇文章里我曾经讨论了反向代理的好处,可能大家印象还不是很深刻,我将会在后面文章里对反向代理做更加深入的分析。
讲完了ESI的妙用后,我下面将讲讲本篇的主题缓存了。其实单独讲缓存真的没啥太多内容,不过在网站静态化处理里的缓存还是和存储里讲到的分布式缓存有所不同,分布式缓存的数据都是存储在内存里,而网站静态处理的缓存既有存储在内存里还有存储在硬盘上,当然存储在内存里读取速度会更快,但是网站的读取效率还和资源距离用户的远近有关系,例如浏览器的缓存其实是把静态内容缓存在硬盘上,但是因为不需要通过网络获取资源,因此它的读取效率就显得特别高了,除了这个因素外还有个因素,我们前面做动静拆分的目的就是想拆分出静态资源,让这些静态资源远离服务端的web应用,这样可以减少服务端不必要的压力,从而达到提升服务端web应用处理能力,而把静态资源放置在静态web容器处理,它的处理静态资源效率又会高于在服务端web应用的处理,从而也达到提升静态资源读取的效率。不过如果静态资源最终只能放置在服务端,那么这个时候我们把静态资源存入到缓存里即内存里效率肯定比在硬盘上高,所以CDN的服务节点一般都是采取将静态资源存储在内存里,就算是服务端web应用前的静态web容器,如果我们让静态资源缓存在内存里,效率肯定也是比在硬盘上高。
相关推荐
此外,还涉及到数据库MySQL、缓存Redis、分布式事务Seata、分库分表技术、Docker/K8s容器化部署、Nginx集群等。 五、数字化转型过程 传统企业逐渐从外购产品转向自主研发,过程中经历了外包、混合模式到自主掌控...
### 网站缓存核心技术概述 随着互联网技术的飞速发展,缓存技术成为支撑大规模网站高效稳定运行的关键组成部分之一。本文旨在深入探讨网站缓存的核心技术,并着重分析三种主流缓存技术——Ehcache、Memcached及...
【天猫浏览型网站静态化架构设计】是针对大型电商平台如天猫在双11等活动期间应对极高流量冲击的技术解决方案。此架构旨在确保系统在峰值请求下的可伸缩性、用户响应时间和高可用性,同时考虑安全性和成本效益。自...
### 浏览型网站静态化架构设计 #### 架构背景与挑战 随着电商活动规模的不断扩张,尤其是像天猫“双11”这样的大型促销活动,浏览型网站需要面对比平时高出数倍甚至数十倍的流量冲击。这种短时间内急剧增加的访问...
《大型网站技术架构_核心原理与案例分析》是李智慧撰写的一本专著,主要针对Web开发领域的高级架构设计进行深入探讨。这本书旨在帮助读者理解并掌握构建大规模、高性能、高可用性的网站所需的关键技术与实践策略。...
因此,为了应对这些挑战,大型网站的技术架构也随之不断演进和完善。本文将深入探讨大型网站架构的演变过程、关键模式、核心要素以及高性能、高可用性和伸缩性架构的设计原则。 #### 一、大型网站架构演化 1. **...
中大型网站架构的演变是伴随着互联网技术发展和业务需求增长而不断优化和升级的过程。在这个演变之路上,网站架构师需要考虑的关键因素包括服务器的可伸缩性、系统的高可用性、数据的一致性与安全性,以及处理高并发...
随着非关系型数据库技术的发展,**NoSQL**数据库因其在大数据处理方面的优势而在中大型网站架构中占据了一席之地。它们能够更好地支持大规模的数据存储和处理需求。 ##### 内存化 为了提高数据访问速度,越来越多...
Java Web网站架构的技术演进是一个复杂且持续发展的过程,它涉及到多个层次的优化和改进,以适应不断增长的用户需求和系统负载。最初的架构通常是一个简单的单体结构,所有的组件,包括文件、数据库和应用程序,都...
通过上述步骤的逐步实施和完善,一个普通的网站可以逐步演进成为一个高效、稳定且可扩展的大型网站。在这个过程中,除了技术层面的知识积累之外,还需要不断学习和适应新的技术和工具,以应对不断变化的需求和挑战。
大型分布式电商系统架构的构建和演进是一个复杂且系统性的过程,它涉及到多个技术领域和设计原则。在从0开始构建这样一个系统时,我们需要考虑的关键点包括:高可用性(High Availability)、可扩展性(Scalability...
《大型网站技术架构:核心原理与案例分析》这本书深度探讨了构建和优化大规模互联网系统的关键技术和策略。在当今数字化时代,大型网站和互联网应用的复杂性与日俱增,本书旨在帮助读者理解如何应对这些挑战。 一、...
大型网站后台架构的演变是一个复杂且持续的过程,随着网站用户量的增长和技术的发展,架构需要不断地进行优化和调整以满足更高的性能、稳定性和可扩展性需求。本文将探讨从小型网站到大型网站后台架构的演进过程,...
本文将围绕“面向用户体验的电商平台技术架构”这一主题,深入探讨如何通过技术栈的不断演进来改善用户体验,以及在此过程中需要注意的关键技术点。 ### 一、技术栈演进概述 #### V0: UX/前端性能优化 - **目标**:...
分布式网站架构的演进是一个复杂且逐步迭代的过程,旨在应对网站流量增长、处理能力需求提升以及数据量膨胀等问题。从初始阶段的简单架构到复杂的分布式服务架构,每一阶段都反映了技术解决方案的升级与优化。 1. *...
总的来说,大型网站架构演变的知识体系包括:单体架构、垂直拆分、水平扩展、微服务架构、容器化、数据一致性理论、缓存技术、CDN、NoSQL、消息队列、监控和日志分析等多个方面。理解并掌握这些知识,有助于构建高效...
总之,大型网站架构的演进是一个从单一到分布式、从简单到复杂的进化过程,涉及到网络、存储、缓存、数据库、负载均衡等多个领域的知识。每一步的改进都需要对现有技术有深入的理解,并能够灵活运用以解决实际问题。...