整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
輯導語：我們可以發現很多政府網站基本都是選擇靜態發布的，這是因為靜態發布能夠更好的保證網站的速度以及安全性等等，政府網站這類對安全性要求較高的網站多會選擇靜態發布；本文作者分享了關于政府網站選擇靜態發布的原因，我們一起來了解一下。
今年過了年接手了政府網站建設相關的產品工作，發現和以往產品最大的不同是，政府網站建設用的是靜態發布，以前做的移動產品都是動態的。那么政府網站為什么一般都選擇靜態發布呢？今天就來總結分析下。
靜態與動態是相對來說的，靜態網頁就是我們常見的以.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小時內與您取得聯系。
