07年畢業一直都在軟件公司,14年來到一個互聯網公司,給個人感覺,區別主要在於:css
軟件公司需求相對穩定,可以按照計劃循序漸進的去實施,互聯網公司需求相對來講不穩定,上線比較着急,大部分都是小迭代更新,且更新頻繁,感受有點亂。因此項目管理在軟件公司比較好執行,一開始可能有點混亂,可是隻要是走上一兩個迭代,就能夠穩定的往前走,在互聯網公司應用比較困難。美其名曰敏捷開發,就是爲了給本身找一個不穩定的藉口。html
目前的公司是一家電商公司,在互聯網如火如荼的雙11也能體驗一把,在增長訂單量的同時,也給軟件帶來了更大的挑戰,軟件架構就像一我的的心臟,汽車的發動機,若是系統的架構出了問題,這筆債早晚是要還的,08年奧運會搶票系統,聚美優品等在高併發的狀況下都出現過宕機的狀況,後來都對架構進行了改進。前端
說到軟件架構,可能每一個人都有不一樣的理解,但大體上分爲兩類:web
軟件系統的架構將系統描述爲計算組件及組件之間的交互。redis
計算組件是泛指的,能夠進一步細分爲處理組件,數據組件,鏈接組件能夠是子系統,框架,模塊,類等不一樣粒度的軟件單元數據庫
軟件架構包含了關於一下問題的重要決策,對關鍵問題進行決策。後端
軟件架構並不只僅注重軟件自己的結構和行爲,還組中其餘特性,使用,功能性,性能,彈性,重用,可理解性,經濟和技術的限制的權衡。瀏覽器
下面我將從如下幾個方面來談一下如何創建高性能的web系統:緩存
1、web系統架構服務器
web系統架構圖:
2、web系統優化
一、 網站前端的優化
反向代理服務器工做在HTTP層,相似代理服務器,與普通的代理服務器不一樣的是,服務器在代理的後端,而不是客戶端在代理的後端,能夠考慮使用 eginx作反向代理服務器實現 web 服務器的負載均衡。
由於頁面的加載是從上往下的順序執行的,js文件在加載的時候會阻塞頁面的執行,因此放到頁面最下面能夠先看到頁面的內容,再去加載相應的js文件。
由於瀏覽器的鏈接數是有限的,若是css 和 js 文件過多會致使瀏覽器的延遲等待。
能夠提升網站的併發能力。
對於像js,css,image, html 等靜態內容能夠作內容分發,能夠把用戶定位到最近的服務器上面。
由於頁面每個的回傳都會把cookie文件提交過去,若是cookie 過大會浪費過多的網絡資源。
把靜態文件放到一個獨立的服務器上,能夠考慮用eginx web服務器,eginx 靜態文件的處理速度很是快,不是iis 所能比的。
頁面內容要進行壓縮,較少網絡傳輸的壓力,能夠考慮用Gzip壓縮。
因內容而異,若是是不常常改變的內容,設置緩存的時間要長一些,從而減小服務器的壓力。
iframe 會阻礙頁面的執行,最好不要使用,何況也不利於搜索引擎的收錄。
由於一個標籤在結束以前是不會呈現內容的,若是都把頁面的內容都到一個表格中,只有到</table> 表格中的內容纔會顯示出來。
二、 後臺的優化
創建多級別的緩存策略,能夠考慮先單機緩存,而後再考慮分佈式緩存。分佈式緩存能夠考慮使用 memcached 或者 redis,redis 提供了更多的存儲類型,並支持數據寫入磁盤的功能。
消息隊列能夠對系統進行解耦,並可提升系統的處理能力,減小數據庫的壓力。若是是微軟路線能夠考慮用MSMQ。
由於單例模式的話,會阻礙多線程和多核系統的處理,下降系統的吞吐量和處理能力。
若是字符串內容多的話,考慮使用Stringbulder 增長字符串的處理能力。
三、 數據庫的優化
這種方式是指利用數據庫的複製或鏡像功能,同時在多臺數據庫上保存相同的數據,而且將讀操做和寫操做分開,寫操做集中在一臺主數據庫上,讀操做集中在多臺 從數據庫上,對於讀取比寫更多的站點適合使用這種方式。
表進行分區後,邏輯上表仍然是一張完整的表,只是將表中的數據在物理上存放到多個表空間(物理文件上),這樣查詢數據時,不至於每次都掃描整張表。提升數據庫的查詢性能。
劃分不一樣的業務模塊放到不一樣的數據庫上,如 訂單庫、會員庫、商品庫等。
在常常查詢或分組的列上,創建相應的索引來提升查詢性能。