偶得一空閑時，開始整理一些東西來與大家共享，為這個世界上IT苦旅的人節省一些時間。因為涉及較多內容，我會漸漸補充內容
一，選擇：
首先選擇網站技術架構，如果我們不是做面向服務型，電子商務型網站或管理網站，我們一般不用考慮J2EE,SSH等方案，一般選擇前端部分主要為PHP框架,后端采用多種語言及組件的混合結構來提供服務。
二，基本結構：
1. Web服務：
網上有很多關於Web服務器的選擇，如果為將來的擴展及高並發做准備，最好是前端用Nginx,Nginx在反向代理，高並發的資源消耗上是很少的，而且文檔雖沒有Apache完善，但也至少比Lighttpd的文檔多些，當然,Lighttpd性能在靜態文件方面占優勢,這里就不說太多這方面的分析了,容易讓一般人產生困惑,這里就選擇Nginx做Web服務,(隨站網站流量增加,它會改變職能為前端代理及部分緩存工作,如果你采用AS式服務集群,它還會被當成主控服務器.進行一些負載策略的工作)
2. 數據服務:
如果我們不想花銀子,用不起Oracle那些昂貴的方案(如Data Guard, Real Application Clusters, MAA(Maximum Availablity Architecture),但我們又想要較復雜的商務數據功能,那MySQL當然是首選了,不過不知道被oracle收購后,這樣的日子還能過多久,不用擔心,我們還有ProgreSQL,至於如今炒得火熱的NoSQL數據庫,大家不必報太高期望,我用過一些,這些數據庫一般都是無事務機制,關系Join等功能都較弱,一般處理一些海量的非事務性數據還行.一般適合高 發網站里混合數據中心的一個存貯方式.
3.數據備份
不同的數據有不同的備份方式,一般要用腳本開發一些自動備份工具.定期備份,因為一開始還沒有用到分布式的數據庫系統,簡單的周期性備份是必須的.一般數據庫都有冷備份,熱備份的命令,但還是要工具化它們,因為隨着系統增長,維護工作越來越多,等到專門的維護小組成立時,可能一切都晚太多了.
經過以上的方案分析與構建,一般會形成一個簡單可運維的網站了.
三，第一次優化：
1.代理:
隨着網站訪問量上升,隨之而來有很多問題出現:比如安全問題 ,有惡意攻擊,垃圾式的訪問, 還有網站主動安全策略SSL給服務器帶來性能消耗過大問題.為了解決這些問題,同時我們還在靈活處理對高並發訪問的分發,或者訪問跳轉,也就是常說的負載均衡策略的靈活實施,我們要在網站服務器上加上反向代理服務器,一般反向代理服務器能處理高並發的連接,性能優越,Nginx是較優選擇.Nginx同時也支持高效的緩存機制.
2.緩存：
網站的訪問一般資源可以分為靜態化資源,動態化資源.靜態化資源不是指靜態網頁,而提指最終響應數據變化周期長的資源.比如靜態網頁,比如一些索引目錄性數據,比如通過動態網頁訪問的一些不常變化的資源,比如圖片,音視頻等素材性數據,舊的報表,字典性數據等,都可以看成靜態化數據,這些數據完全不必每次都經過網站服務器去數據庫里查找,再經過IO讀取(當然,操作系統會對數據文件,及普通文件有OS級是的緩存,這個要等到后面分析),所以需要對這些數據進行緩存,緩存分為服務器式緩存及應用邏輯中的緩存兩類,
服務器式緩存就是代理的方式把靜態資源生成后放到緩存服務器上,客戶端直接從這些緩存服務器上取得數據,緩存服務器有很多開源實現,有老牌的Squid,Nginx也支持不錯的緩存.緩存服務器一般都是在網站前端進行.這是緩存策略的一部分
應用邏輯的緩存是在網站服務器的應用邏輯中.對一些數據進行緩存,以方便在邏輯處理中重復從數據庫或存貯中去取得這些數據.這個層次緩存一般利用 memcached,Ncache,ehCache,OSCache等等.
3.靜態化：
四，第二次優化：
1.分布式服務器集群
2.分布式存貯
a. 分布式文件
b.分布式多媒體
c.分布式數據庫（Sharding，Cluster或集群）
五，第三次優化
1.優化緩存及分布方式
2.混合其它方案。
六，第四次
1.日志分析。
2.數據倉庫
3.搜索引擎，SEO
七，多層次運維：