辑导语:我们可以发现很多政府网站基本都是选择静态发布的,这是因为静态发布能够更好的保证网站的速度以及安全性等等,政府网站这类对安全性要求较高的网站多会选择静态发布;本文作者分享了关于政府网站选择静态发布的原因,我们一起来了解一下。
今年过了年接手了政府网站建设相关的产品工作,发现和以往产品最大的不同是,政府网站建设用的是静态发布,以前做的移动产品都是动态的。那么政府网站为什么一般都选择静态发布呢?今天就来总结分析下。
静态与动态是相对来说的,静态网页就是我们常见的以.htm、.html、.shtml等后缀结尾的页面。
通常静态网页的制作流程是:
第一步:发布信息到数据库
第二步:选择页面的模板
第三步:程序读取模板+数据库信息=静态页面
第四步:发布索引页面(如首页、引导页等)
静态页面的生成至少需要上述几个步骤才能完成。
静态网站设计所采用的的技术原理是一对一的形式,也就是说在这样的网站上面,一个内容对应的就是一个页面,对应服务器上的一个文件;所以静态网站可以简单理解为纯粹就是几个制作好的页面而已。
网页在设计好并上传到服务器后,就不能对网站的内容进行修改了,除非把网站文件下载下来,用专业的网站制作软件修改编辑好后再次上传;所以在静态页面的制作中,模板是关键,因为一旦想要调整页面,必须再次创建,而如果数据量大的话,那么这个更新时间将相当可怕。
另外,静态页面不需要与数据库通信,无论网站访问者如何操作,都只是让服务器把固有的数据传送给请求者,没有脚本计算和后台数据库读取的过程。
最后补充一下,URL相对动态网站来说也比较清晰,如,product.html。
因为静态网站没有其他程序和数据读取,因此静态网站打开速度相对比较快。
动态网页网址中动态参数太多,而且链接过长,而静态网页则相反,因此静态网页比动态网页更受搜索引擎欢迎。
再加上静态页面打开速度快、网站URL标准化程度高、网站简洁、网站用户体验度好,使得静态网页更容易被搜索引擎所收录。
因为静态页面都是纯html格式的文件,所以不管黑客使用什么样的手段都无法直接对网站进行攻击,所以在网站安全性方面,静态页面是做的最好、最安全的一种方式。
因为静态页面无法在调整后自动更新,不能直接对网站内容进行修改,所以如果要调整页面,必须再次创建,维护操作十分繁琐。
虽然静态页面不需要对数据进行不断读取,但是在生产静态页面的时候,程序需要对服务器进行创建文件夹、创建html文件、删除文件等操作,所以如果网站存在上万篇文章,那么每生成一次静态文件,就会对网站服务器带来很大压力,而且也无形地增加空间占用率。
静态页面由于受其特性影响,无法实现会员注册、在线留言等功能,只能简单地以信息展示为主。
动态网站是先从数据库里面获取数据,然后再按一个格式显示出来,也就是说只需要一个显示页面内容的框架,就可以把成千上万的网页显示出来了,所以动态网站对服务器空间要求很小。
动态网站内容可以实时更新,而且与用户交互性强,比如一些论坛、注册、在线聊天页面都是动态的。
另外,动态网站由于每次加载一个新的页面,都需要与后台数据库通信,所以加载速度会稍慢一些。
在URL方面,动态网站URL可能会带有参数。
动态网站的开发语言主要有:ASP、JSP、PHP、ASP.NET,早期最普遍的是ASP开发的网站,现在主流网站开发语言是PHP、ASP.NET。这些程序都要使用数据库才能完成动态操作。数据库常用的有:ACCESS、MYSQL、MSSQL、ORACLE等。
由于动态页面可以通过网站程序直接调用大量数据直接展示到网站前台,因此动态页面对网站服务器产生的压力相对较小。
但是由于动态页面需要不断的调用数据库中的数据,所以对数据库的要求还是比较大的,而且频繁的调用读取会增加数据库的负担,严重情况有可能会导致数据库崩溃现象。
动态网站由于可以实时修改更新,因此维护方便,同时由于可以存储大量数据,所以在需要时可以立即查询。
搜索引擎的算法受网站安全性、网站打开速度、网站URL对用户的体验度等影响,使得搜索引擎对动态页面赋予的权重值和信任度相对较低。
由于动态页面网站的URL参数和网站目录结构都是很明显的暴露在浏览器上面的,所以很多黑客可以通过修改网站的URL参数从而获得网站的shell权限,进入后台拿到管理员账号密码,对网站进行非法操作,因此动态网站的安全性较低。
除此之外,因为动态网站会用到数据库,所以对数据库的安全和保密性要求较高,要专业技术人员提供维护才能保证网络安全。
伪静态本身其实就是动态网页,只不过是被转换重写成了静态网页,此时通过浏览器访问的地址和真的静态页面没有区别。
当考虑搜索引擎优化SEO时,可以将动态页面通过服务器处理成静态页面,比如论坛帖子页面,都是经过伪静态处理成静态页面。
但是伪静态不是真实地址,到底要显示哪个页面也就不能直接指定,而要由CPU来判断,所以CPU占有量的上升是伪静态最大的弊病。
总之,为了SEO,网站可以选择伪静态,但是为了避免CPU超负荷,可以少量使用伪静态,甚至可以只在专门提供给SEO的Archiver中使用伪静态。
当然,现在也有越来越多的网站采用动静结合的方式,因此可根据具体需求及实际情况来选择不同的技术方案。
作者:王山而,喜欢读书、喜欢研究用户心理,坐标:北京。公众号:小2在思考
本文由@王山而 原创发布于人人都是产品经理,未经许可,禁止许可。
题图来自 unsplash,基于CCO协议
迎关注头条号:老顾聊技术
精品原创技术分享,知识的组装工
我们小伙伴们在访问淘宝、网易等大型网站时有没有考虑到,网站首页、商品详情页以及新闻详情页面是如何处理的?怎么能够支撑这么大流量的访问呢?
很多小伙伴们就会提出他们都采用了静态化的方案,这样用户请求直接获取静态数据html,就不需要访问数据库了,性能就会大大提高;而且提高网站SEO优化。那今天老顾就带着大家聊一下静态化。把老顾之前工作场景中静态化方案遇到的问题,以及如何演变的,分享给小伙伴。
关于相关的静态文件的CDN技术,老顾就不在这边讲了。这个大型网站肯定都会用到的,什么是CDN,小伙伴们可以在网上查询看一下,比较简单;我们这边注重看技术方案。
这个方案是老顾最早使用的方案,我们就拿CMS系统举例,类似网易的新闻网站;核心流程图
上图的核心思想:
1)管理后台调用新闻服务创建文章成功后,发送消息到消息队列
2)静态服务监听消息,把文章静态化,也就是生成html文件
3)在静态服务器上面安装一个文件同步工具,此工具的功能可以做到只同步有变动的文件,即做增量同步(老顾用久没用了,忘了工具的名称)
4)通过同步工具把html文件同步到所有的web服务器上面
这样的话就达到了,用户访问一些变化不大的页面时,是直接访问的html文件,直接在web服务器那边直接返回,不需要在访问数据库了,系统吞吐量比较高。
这个方案的问题:
1、网页布局样式僵化,无法修改
如果产品经理觉得新闻详情页面的布局要调整一下,现在的不够美观,或者加个其他模块,那就坑爹了,我们需要把所有的已经静态html化的文章全部重新静态化。这个是不现实的,因为像网易这么大的体量,新闻量是很大的,会被搞死。
2、页面会出现暂时间不一致
会出现用户刚刚再看最新的新闻,刷新一下又不存在了。这个是因为同步工具在同步到web服务器是要有时间的,同步到web服务器A上面了,但web服务器B还没有来得及同步。用户在访问的时候通过nginx进行负载均衡,随机把请求分配给web服务器的导致的。当然可以调整nginx负载均衡策略去解决。
3、Html文件太多,无法维护
这个是很明显的问题,html文件会越来越多,对存储空间要求很大,而且每台web服务器都一样,浪费磁盘空间;将来迁移维护也会带来很大的麻烦。
4、同步工具的不稳定
因为文件一旦多之后,同步工具稳定性就出现了问题
这个方案应该是比较传统的(不推荐)
什么是伪静态?
举个例子:我们一般访问一个文章,一般的链接地址为:http://www.xxx.com/news?id=1代表请求id为1的文章。不过这种链接方式对SEO不是太友好(SEO对网站来说太重要了);所以一般进行改造:http://www.xxx.com/news/1.html 这样看上去就是个静态页面。一般我们可以采用nginx对url进行rewrite。小伙伴如何有兴趣可以自行了解,比较简单。
之所以是伪静态其实也是需要动态处理的。
针对方案一上面问题,方案进一步的演化,如下图
此方案的核心思想
1)管理后台调用新闻服务创建文章成功后,发送消息到消息队列
2)缓存服务监听消息,把文章内容缓存到缓存服务器上面
3)用户发起请求,web服务器根据id,直接查询缓存服务器
4)获取数据返回给用户
此方案就解决了方案一的一个大问题,就是html文件多的问题,因为不需要生成html,而且用缓存的方式,解决不需要访问数据库,提升系统吞吐量。
不过此方案的问题:
1、网页布局样式维护成本比较高,因为此方案照样是把所有的内容放到了缓存中,如果需要修改布局,需要重新设置缓存。
2、分布式缓存压力比较大,一旦缓存故障就导致所有请求会查询数据库,导致系统崩溃
还有个小问题,就是实时数据处理,就是页面中如价格,库存需要到后台读取的。当然小伙伴也许就会说,也可以处理啊,用户把商品内容请求到后,然后在用浏览器发送异步的ajax请求获得商品数量就好了啊。这样就是无形的增加了一次请求。(此问题可以忽略)
此方案类似很多公司都在使用,如:同程旅游等
针对方案二的问题,我们可以采用openresty技术方案进行,利用http模板插件lua脚本进行解决,这里老顾不会介绍openresty+lua技术,有兴趣的小伙伴,可以到访问https://www.roncoo.com/view/139 这个视频课程。
如下图:
这里说明一下上图中我们小伙伴不需要全部都要了解,这个是比较全的商品详情页的解决方案,涉及到了三级缓存这个概念,在这里老顾就不深入讲三级缓存了。
我们主要看的是上面怎么会有两层ngnix,分发层和应用层,这个是什么意思?
老顾先介绍一下应用层nginx是什么意思?nginx一般被用做负载均衡,其实nginx还有很多的功能,尤其他的openresty扩展 + lua脚本语言结合起来可以完成很多功能,小伙伴可以理解为lua脚本语言就是类似java语言,可以动态处理业务,如:本地缓存处理,远程http访问,访问redis等。
应用层nginx就是利用了http模板 + 缓存通过lua脚本完成的网页渲染
http模板
1)应用层nginx通过lua脚本语言先获取本地商品数据,然后和http模板进行渲染,形成最终商品详情页返回给用户
2)如果应用层nginx本地的缓存没有此商品数据,就通过lua脚本发起http请求访问web服务器,获取商品数据。
3)web服务器会向redis或本机的ehcache请求商品数据(这里涉及三级缓存概念),如果存在此商品数据,直接返回给用户;如果不存在则请求微服务访问数据库
这个思路就是通过http模板,解决了方案二中的布局样式的问题,如果需要调整布局,只要改一下模板就行了,非常方便。也解决了实时性问题。这边涉及到的nginx本地缓存其实就是为了保证不需要访问数据库,提升系统吞吐量。小伙伴只要了解一下思路,如果不了解openresty和lua可以自行上网了解,也可以联系老顾。
为什么上面还有一层分发层呢?这个是因为大型网站的商品数太多了,应用层nginx的本地缓存是有限的,不可能把所有的商品数据缓存在同一个服务器的本地缓存;一台应用层nginx只能缓存部分商品数据,说到这里小伙伴是不是应该就知道为什么了吧?就是利用hash一致性算法,根据商品id路由分发到同一个应用层ngnix服务器。
分发层ngnix的作用就是hash策略的负载均衡,保证了商品id路由到固定的应用层服务器。
三级缓存保证了系统的稳定性,即使redis缓存崩溃,还有其他2个缓存保障。
总结:
-End-
如有收获,请帮忙转发,您的鼓励是作者最大的动力,谢谢!
10几年的经验实战分享
相关微服务,分布式,高并发,高可用,企业实战,干货等原创文章正在路上
欢迎关注头条号:老顾聊技术
精品原创技术分享,知识的组装工
推荐阅读
1、你知道如何保障生产端100%消息投递成功吗?
2、你知道如何更新缓存吗?如何保证缓存和数据库双写一致性?
3、你知道怎么解决DB读写分离,导致数据不一致问题吗?
4、DB读写分离情况下,如何解决缓存和数据库不一致性问题?
5、你真的知道怎么使用缓存吗?
6、如何利用锁,防止缓存击穿?重构思想的重要性
7、海量订单产生的业务高峰期,如何避免消息的重复消费?
信息加速发展的互联网时代,越来越多的科技公司为了专注核心竞争力业务以及降低软件项目成本,开始将项目中的部分业务模块分发给第三方外包公司来完成。而这样是否就意味着大幅度地降低成本了?
事实告诉我们,并没有。
本文作者作为一名外包商,以自身的经历告诉我们本可以在3天之内完成了的一个报价仅为 1500 美元的静态 HTML 页面,是如何被大型企业硬是拖成了一个为期 7 周且需要耗费 18000 美元(约为人民币12万)项目的。
不久前,我作为承包商工作,经常从一个项目跳到另一个项目。有些是短期的,工作一周左右,可很快提交我的工作成果。也有的项目会持续几个月,这期间我会攒一些钱用以休息一段时间。
我更喜欢短期工作,因为这样的工作使我可以在单位时间内收取更高的费用。这样不仅我感觉是在为自己打工,而且我觉得我不需要太努力工作就能过上还算体面的生活了。我的最高费率仍然在合理的范围之内,而且我总是提供高质量的服务。这就是我和一家大公司定下这个项目之前我的工作状态。
这家公司联系我的时候显得很着急,经理告诉我他们现在就需要一个人来搞定这件事。需要一个不怎么需要公司培训就能马上上手,而且能交付最大性能的人。不管怎么说,这刚好是我的座右铭。这个项目正是我喜欢的工作类型。它内容简短,很快就能做好,而且报酬很高。
在谈判确定好合适的费率后,我收到了一封包含说明的电子邮件。他们给了我更多关于这个项目的背景。他们的开发人员在没有事先告知的情况下就离开了,并且从未跟任何其他人汇报过项目的进展。
我们需要您毫不分心地完成此项目。在合同期限内,您将只与我们合作,并及时交付成果。我们会对给您造成的麻烦进行补偿。
任务说明很简单:阅读这些需求然后估计完成这个项目需要多长时间。这是我职业生涯中遇到的一个那类比较容易的项目之一。这是一个HTML页面,包含一些简单的动画和几个嵌入的视频。我花了一个晚上研究需求并在脑中模拟实施。这些年来,我已经学会了在能确定收到报酬之前不为客户写任何代码。
我确定了这个项目充其量也就是一天的活儿。但为了保持谨慎,我上报了20个小时,总计1500美元。毕竟这只是一个HTML页面而已,我也只能收取这么多费用。他们让我到25英里外的卫星办公室去。在为他们工作的那三天里我必须天天开车去那儿。
第二天,我到了卫星办公室。在一个购物中心,然后通过一扇秘密的门进入了一个秘密的世界,一些工作人员在他们的小隔间里安静地工作着。接待员给我看了一个我将用它来工作的全新MacBook Pro,我必须从零开始设置环境。我的确更偏向于使用公司的笔记本电脑,因为他们经常要求承包商安装一些可疑的软件。(我可不想装到自己电脑上。)
我花了一天时间下载我的工具包,设置电子邮件、SSH密钥和请求服务的授权。换句话说,我什么都没做。这就是为什么我上报了20个小时,还没开始写代码呢,光前期设置就耗费了8个小时。
第二天,我准备开始真正地干活了。有了MacBook Pro,我用它发了一封电子邮件给经理。我告诉他我已经准备好工作了,正在等待上述的资源。那天,我在我柔和灯光下的工位上待着,玩着手指,直到太阳落山。
我再次计算了一下。根据我的估计,我还只剩4个小时的时间来完成这项工作,这对单个HTML页面来说也不是不可能。但不用说,第二天,我把这剩下的4个小时花在了吃公司赞助的午餐上,伙食很不错,而且我与其他员工玩得很开心。
当预计的20小时到期时,我确保向经理发送了另一封电子邮件,让他知道我确实人一直在公司,但我没有收到我需要的资源。当然,那封电子邮件被无视了。
接下来的星期一,我犹豫地开过了这25英里。令我惊讶的是,经理已经来到卫星办公室,并热情地问候了我。他是个三十来岁,很随和很不错的人。我很不解,他并不像当初要雇我的那时候那么着急了。我们进行了友好的交谈,没有提到任何工作。后来,我们去吃午餐,他付了钱。这是美好的一天。完全没工作。
好吧你可以说我很容易形成习惯,但如果你供我吃喝并每天呵护我,我会习惯这一切。这变成了一个例程。
我来上班,花一些时间在网上阅读以及看视频。我每天发一封电子邮件,所以他们知道我确实去了公司。
然后,我会去吃午饭并和碰见的有趣的人一起玩耍。在一天结束时,我站起来,伸个懒腰,打一个当之无愧的哈欠,然后开车回家。
我习惯了。事实上,我在期待这些。当我终于收到一封带有指向我需要的资源的链接的电子邮件时,我反而有点失望。我重新开始脚踏实地,变回自己工作时的严肃脸。但是,在花了几分钟查看Zip文件后,我才注意到它缺少了我需要的大部分内容。设计师给我发了一些Adobe Illustrator文件,我无法在MacBook上打开它。
我回复了电子邮件来解释我的疑虑,而且一并问了一些其他问题以节省时间。那时,我当初上报的20个小时时间早都已经过了。我现在真的想要完成这项工作了。
点击发送后不久,我收到了一封电子邮件。只有一句:“转发给Alex”,然后Alex得到了这封电子邮件的抄送。
Alex回答说他转发给了Steve。Steve回答说Michelle是设计师,她会了解得更多一些。
Michelle的自动回复称她正在度假,所有询问都应该直接告诉她的经理。
她的经理回复说“谁是Ibrahim?(我的名字)”我的经理回复说他很抱歉还没有向大家介绍我。
作为承包商,在人们注意到我在那里工作之前,我通常就已经完成我的工作并离开那家公司了。但这次,我收到了大量欢迎的电子邮件。这样的邮件持续了一段时间,而我被迫回复那些友好地过了头的邮件。有些人很想跟我本人见面。当我说我在加利福尼亚州,离得远着呢,他们有点失望。以及羡慕,他们说他们羡慕加州美好的天气。
他们很有礼貌地无视我的电子邮件,用抄送来转移我的问题,把我问过的任何事情归为垃圾邮件。我花了很多时间,像一位考古学家在深深的电子邮件之沟内挖掘,希望找到我问题的答案。
你可以想象每当我想起我唯一的任务是构建一个静态HTML页面时,我感觉到的冒名顶替综合症(心虚,怀疑自己的回报不是理所应得的)的程度之深。原本虚报了的20个小时的项目变成了为期7周的冒险,期间我享受免费午餐,每天开车50英里,并翻看电子邮件。
当我最终完成项目时,我在GitHub上将它发送给了团队。
在不久之后,我收到了邀请,整个团队会用Google Hangout开视频会议对我的代码进行Code Review。
我花了一个多月的时间来写一个静态HTML页面,而现在整个团队都要评价我的工作?
那个什么,我要为自己说句话,这个页面也包含一些JavaScript交互,是响应式的,还包括CSS动画......好吧我真的觉得自己像个来冒名顶替的。
当然,视频会议的时间又重新安排了几次。当它终于发生时,我和我的工作已经不是会议的主题了。他们都坐在纽约某个地方的同一个房间里,像一个紧密团结的团体一样聊了一会儿。事实上,他们所说的关于我做的项目的所有内容只有:
那天晚上回家的时候,我意识到自己正面临另一个挑战。我在这家公司工作了7个星期,而我的原始报价为1,500美元。这相当于每年11,100美元或每周214美元。或者直接说,每小时5.35美元。
这几乎还不够我付油钱的。所以,我给他们发了一张发票,我按照原来的每小时费率给他们报了7个星期,总额达18,000美元。我当然感到羞耻,但我还能怎么办呢?
就像我预期的那样,我没有收到回复。如果所有大公司都有什么相同之处,那就是他们并不急于按时支付账单。这么简单的工作要价这么多,我觉得自己像一个骗子,但话又说回来了,我又不是来做慈善的。我每天开车50英里来做这项工作,如果工作没有完成,那不是因为我不想。这是因为他们回复太缓慢了。
接下来的一周我得到了回复。这是一封来自经理的冷邮件,他把我每天的工作日分成不同的时间段。然后他把我工作的那部分时间高亮了,每天标记一个小时的午休时间。最后他用我们商定的小时费率做了一些计算。
显然,我算错了。我错误估算了总数。调整后,他们欠我的总金额是21,000美元。
请确认重新调整后的小时数,以便财务可以给您写个支票。
我很快回复了确认。
原文:https://idiallo.com/blog/18000-dollars-static-web-page
作者简介:Ibrahim Diallo,具有多年开发经验的软件工程师。
本文为 CSDN 翻译
*请认真填写需求信息,我们会在24小时内与您取得联系。