如何開發高性能低成本的網站之技術選擇

每一個企業都是慢慢發展起來的，在起步階段成本是一個不得不考慮的重大問題 。直接入正題：

 

前臺框架:  ASP.NET MVC + Jquery + Json + Flash , ASP.NET MVC 高性能速度快，Jquery 簡潔成熟的Js基礎框架 , Json 數據格式體積小 ，傳輸快。Flash 用於開發複雜的頁面交互應用。

 

緩存方案：

Memcached , 基於Key-Value的傳統Cache儲存方式 , 高性能 ， 並且它內置LRU（Least Recently Used）機制自動維護緩存數據,從而 提升緩存的性能和負載能力。

MongoDb , 數據庫級別的緩存解決方案 , 適合海量的數據緩存 , 支持查詢

 

權限模型:

基於ASP.NET MVC 的RBAC , 控制對象粒度到Action , 控制操做粒度 是否能訪問。權限基於Cookie/緩存記錄認證信息 , 在用戶登陸時就計算出該用戶的全部權限並緩存。

(優勢：直接經過AOP作橫切面控制，不須要設置權限點 ；缺點：沒法控制到同一個Action有增、刪、改、查等更細的操做粒度，不一樣的操做須要製做不一樣的Action , 表面上要多幾個Action , 其實這樣作職責更加分離，更加符合OO的觀點)

 

多語言解決方案：

         服務端, 基於資源文件，完美配合ASP.NET MVC 前段框架 ,進行各項數據驗證及提示等

         客戶端, 一樣基於資源文件, 對Page頁面採用script 導入序列化的資源文件 ,按名詞空間引用 ，如Resources.Book.AreYouSure 的Js變量. 對於flash等能夠經過Json 傳遞。

 

數據通訊：

服務端，WCF , WebService

客戶端,  HttpRequest 數據類型Json

 

數據訪問層：標準接口化，不對數據實現依賴。

         Entity Framwork , 適合只使用SQL Server 的解決方案, 開發效率最高

         NHibernate , 支持多數據平臺 ，開發效率較高 , 性能通常

         ADO.NET, 徹底靠開發實現,開發效率低 , 性能較高

         性能和效率按正常水平評估

 

解耦辦法：

         IOC , 依賴注入 ,

         AOP , 橫切面攔截 ,權限中的推薦作法

 

負載均衡：

         Nginx , Web前端的負載均衡解決方案 , Nginx 開源免費，高性能 .

 

頁面提速：

      實時性要求不高的頁面能夠作靜態化 ，頁面的部分動態內容能夠經過SSI處理 ,而後數據更新就主動生成頁面。頁面靜態化,經過XSLT的CMS生成機制能夠對生成的頁面內容進行壓縮。

      靜態資源文件拆分出去作獨立站點,加上服務端的GZIP/Deflate壓縮等操做,最好配上二級域名，已加快客戶端HTTP下載.更加方便之後作CDN.

 

SSO:

      若是有多個站點，統一認證能夠下降開發維護等成本.

 

數據庫：

      Mysql ,  成熟，開源.

 

　　最近12306.cn網站事件引發了不少人對架構的思考。這種訪問量巨大的網站究竟該如何來作架構，下面是個人想法：

　　由於要考慮到通用拋開業務單純從技術層面分析，要承載海量用戶的訪問，要求網站高性能和高可用、安全可靠 、高可收縮性 、易於維護 等等一堆硬性的要求。對架構師來講是極大的考驗。先上圖：

1、對高性能的解決方案大多都是負載均衡，但負載均衡應該作在那一層或者哪幾層呢？

1.1、首先是 DNS解析層面的負載均衡 ,  這一層不但能夠作負載還能夠作分網(電信、網通和教育網)路由 ， 和靜態內容(圖片之類的東西)路由 ,把靜態內容獨立出來自己就有利於作CDN、性能優化和平常維護。這一層的路由性能是最高的，固然硬件和網絡等因素不考慮。

1.2、web前端的負載均衡 , 這一層的能夠作硬件層面的負載均衡(eg:F5)或者軟件層面的負載均衡(eg:Apache/LVS/ Nginx),選擇仍是比較多的。但這一層的負載均衡要考慮自己有須要的負載均衡 , 我這裏採用Keep alived.

1.3、Web這一層如何提升性能， 固定性內容使用靜態化 ， 動態內容提升性能原則是」剃刀原則」直接訪問數據庫或者緩存(包括本地和分佈式緩存)。

　　看一個案例：

 

　　剛 開始的架構圖：

 

 

使用一段時間以後發現WCF應用服務是瓶頸 ，就想到這一層的負載均衡，怎麼作呢？因而就有了以下的解決方案：

 

 

 

　　 在應用服務器前面加了一個WCF路由和負載均衡的服務器。可是部署沒多久就撤下去了。緣由是WCF路由服務器成爲了新的瓶頸，而後多層應用層面的路由對性能的損耗增長，穩定性反而降低,維護成本增長。

 

　　 分析問題的自己爲何要用WCF？這裏不是WCF這個技術很差，而是使用的場景不對. 自己簡單的業務爲何要經過WCF服務訪問數據庫呢？爲何不直接訪問數據庫，而後把重複訪問的數據提起出來作緩存。這樣才真正符合「剃刀原則」。

 

1.4、數據庫集羣 ， 不一樣的數據作法相差很大。Oracle 自己有RAC的作起來比較方便。mySql也有本身的集羣機制。這裏說說對Sql Server 的一些思考：

 

 

前段放IP負載均衡(eg:LVS)，開發不用管後面數據的儲存，只是將讀寫分離，寫Master集羣，讀slave集羣,集羣之間經過 微軟企業級解決方案實現： 

Master 集羣之間作Row級別的同步 , Master-Master Row-Level Synchronization

Master to Slave 的數據同步Master-Subordinate Cascading Replication

 

 

2、安全可靠，我以爲能夠從幾個層面上去把握

2.一、網絡佈局的層面 ，一些安全機制薄弱的應該置於內網 ，邊界位置的嚴格驗證，防火牆等。

2.二、通訊層面，對安全要求較高的數據傳輸要使用證書加密。

2.三、應用層面，嚴格對數據來源過濾和檢查，對不可信數據攔截

2.四、數據庫層面，敏感數據的儲存方式須要高強度加密(好比SHA512+適當的Salt)。(不要讓相似CSDN密碼泄露事件發生在我設計的架構上)

2.五、OS層面，自動化的系統補丁安裝，殺毒防護程序之類自動更新。

2.六、維護層面，維護人員的責任制

 

 

3、高可收縮性

      架構圖上畫一個集羣，不必定部署一個真的集羣，集羣多大？最小一臺，最大能夠擴展到IP端能容納的數據量 ， 若是多級負載加上集羣就能夠實現海量的集羣就能夠叫着「雲」！

首先DNS 負載均衡 ，網站A記錄能夠指向多個Data Center , 最小能夠只有一個。ningx集羣 、 web集羣 、 分佈式緩存集羣 和 數據庫集羣均可以很方便的進行收縮。

 

 

 

4、易維護

      主要是架構自己具有的容災能力，而後有自動監控的平臺，緊急狀況經過Email或者短信通知維護人員進行相應的處理。

       偌大一個web集羣，維護成本是很高的。下降維護成本就須要同組件去完成，web集羣或者圖片集羣之間的內容同步 ， 數據庫和緩存的集羣通常都已經有成熟解決辦法，不是很費事。

       緊急狀況的預案等須要提早作好規劃，每隔一段時間進行論證和更新。