從架構設計師的角度來看，架構就是一套構建系統的準則。通過這套準則，我們可以把一個復雜的系統劃分為一套更簡單的子系統的集合，這些子系統之間應該保持相互獨立，并與整個系統保持一致。而且每一個子系統還可以繼續細分下去，從而構成一個復雜的企業級架構。

一 選擇技術方案和物理架構

如何選擇技術方案和物理架構，對很多剛接觸平臺網站研發的人來說這可能是個頭疼的問題。這些問題的源頭很簡單就是能否提高開發效率，使平臺具有高性能高負載性。就我遇到的常見的有這么幾個問題：

a） 開發語言和數據庫

一說到開發語言和數據庫，很多人便開始做語言的比較，最常見的爭論有：“asp.net和java哪個好”，“解釋性語言和編譯性語言哪個好”等。我個人覺的最關鍵是你和你的團隊最擅長的開發語言和數據庫是哪個，古語有云：“工欲善其事，必先利其器！”，趁手的開發語言和數據庫有助于事半功倍。試想如果你選擇了一個并不很熟悉的語言，也許這個語言和數據庫在基礎性能上的確比你掌握的語言好，但是在研發過程中學習曲線肯定長。而且遇到問題的時候因為不熟悉的原因，浪費更多的時間去尋找解決方法，而且找到的方法不一定是最好的，說不定還不如你自己用熟悉的語言解決來的快。

也許有朋友會說：“這幾種開發語言和數據庫我都熟悉”，那么就要看你對這幾種開發語言和數據庫的熟悉程度了，對各種開發語言和數據庫的特性了解的越深入，越有助于提高開發效率。而且目前主流的開發語言和數據庫都提供性能調優，只有深入了解了開發語言和數據庫的特性和原理，那么性能調優就很容易。

個人覺的重要的就這兩點，開發效率和性能。

b） 成熟框架還是自己實現

目前主流的開發語言的使用者中有很多前輩都提供了他們自己總結實現的框架，比如JAVA中的“S-S-H”組合，PYTHON的DJANGOO等。我個人的一些經驗是，盡量使用開源的成熟框架，因為平臺研發初期使用成熟的開源框架，能提高開發效率，并且在質量上有保證。我曾經接手過一個平臺的改版，框架是前面開發人員自己寫的，里面的一些設計思想不是很成熟，導致平臺在負載增高后性能很差，整改起來很麻煩，只能一點一點的分離出來，耗費時間和經歷。

有的朋友可能會問什么才是成熟的框架，個人總結的幾點：

1 能提供使用指南，比如 COOKBOOK， USE GUIDE等。有這些提供，那么入門使用變的容易，也方便維護，而且有助于深入了解其特性和原理。

2 有官方支持，比如官方討論社區，郵件列表等，并且有BUG收集處理機制。有句話叫大樹底下好乘涼，有了官方支持，當使用過程中遇到問題的時候，直接就可以通過查找前人的使用心得和問題來解決問題，遇到BUG的時候，提交上去，也能找到解決之法。

3 官方在不斷的更新發布穩定版本。這一點很重要，官方如果及時幫你解決目前已知的或者未知的BUG，那么對使用者來講，就沒什么后顧之憂了，如果官方停止更新了，那么我建議還是早點換下家吧，因為如果這個框架好，那么肯定會越來越好，官方也會不斷的更新它。還有就是穩定永遠是第一位，可以在不影響生產環境的情況下進行無縫升級更新。

4 身邊使用者很多，經常能看到相關的討論或者總結。目前很多成熟框架都是國外開發者發布的，如果使用者E文不好也是個討厭的事情，那么如果身邊有很多同樣的使用者和很多討論，那么對于使用者來說是種福音，共同探討和學習。

那么除此之外最好是開源的框架，平臺初期訪問量不大，因此對性能的要求不高，成熟的框架的使用都不會出現什么問題。當訪問量急劇增高之后，那么性能要求也變高，一些框架中隱藏的問題也因此出現。這時候如果是開源的框架，使用者可以深入了解它的源代碼，洞悉其實現機制，根據自己的實際情況進行調優。如果不是那么使用者也只能改變方向去解決問題，條條大路通羅馬。

c） web server/db server/cache server 相關

在架構設計中web server/db server/cache server是很重要的一點，我個人覺的這一塊必須是使用具有前瞻性，易配置，能監控和維護的產品，總結的幾點：

1 豐富和深入的配置選項。如果能提供豐富和深入的配置選項，那么在安全和性能調整上可以很方便的進行操作，并且不中斷實際的生產環境。

2 基于高并發模型。比如這幾年熱門的基于epoll的nginx，可以有效的減少連接處理時間，增大同時并發數。

3 支持負載均衡和請求分發。當平臺的訪問量增高之后，單臺服務器肯定是很難支撐，這時候就需要增加服務器來分擔壓力，這時候server的負載均衡和請求分發就很重要了。

4 高效的緩存機制。高效的緩存機制可以幫助平臺提高負載能力，減少重復資源的讀取和處理時間。比如用于小文件緩存的SQUID，VARNISH，用于數據庫緩存的memcached等。

5 實時的狀態監控機制。實時的監控狀態報告，可以有助于平臺維護人員迅速了解平臺性能運行狀況，根據狀況進行調整。

如果是開源的那就更好了，可以深入了解其源代碼，并根據自己的實際需要進行配置和定制。

d） 操作系統

選擇合適的操作系統，個人覺的最主要是穩定安全，易管理和維護，易監控。穩定安全的操作系統一般官方會持續的發布補丁和新版本，解決BUG和漏洞等。并且官方或者第三方會不斷的提供新的管理維護監控工具，并且能讓管理維護人員通過編寫腳本來維護管理。而且合適的操作系統能讓研發人員充分利用其特性，發揮平臺的大性能。

f） 物理架構

這里的物理架構是指服務器的搭建方式。有的朋友可能資源有限只有一臺服務器，有的朋友資源充分有十幾臺服務器或者更多，我個人覺的這都不是問題。平臺初期的話，我想大部分訪問量都不高，web server/db server/cache server放在一臺服務器上都沒問題。但是自己心里最好能預估一下這個平臺會發展到什么樣的規模，在做架構設計的時候，按照事先預估的來決定怎么做物理架構，并為以后的架構升級做準備。說到這里，想到前百度架構師雷鳴說過的一句話，當你的會員數達到目前的5倍或10倍的時候，架構就要升級。

二 平臺研發

前期做好了技術方案，就進入到實質研發過程中來了，個人感覺平臺網站的研發有別于傳統的IT項目研發，因為以前就是客戶/需求分析人員/美工之間進行交涉，而現在平臺網站研發會多接觸一個角色叫產品，產品決定了最后的平臺網站是什么樣的，有什么功能，每個功能的流程和用例是什么樣子的，也就是原型設計。并且在研發人員實現之后，還要由測試人員進行測試。

在上述過程中，產品會經常要求研發人員：“某某功能是這樣的，你趕快給我實現并解決。這個功能不對，要改。那個功能出現問題，要改”，而研發人員可能正在忙著其他功能的實現，于是很容易產生沖突。在此我推薦使用敏捷開發方式，設立短的發布周期進行迭代開發，產品提出來的問題統一在一個周期內解決，到下一個周期一起發布，到下一個周期再進行下一周期的功能改進和BUG修正。并使用JIRA這種成熟的項目管理系統進行管理，為以前的更改留下歷史，總結經驗。

那么在正常的研發過程中，特別是團隊研發，我個人覺的需要注意的幾點：

1 合適的開發工具。還是那句話“工欲善其事，必先利其器！”，使用合適的開發工具和插件，能提高開發效率，節省開發成本。團隊使用統一的開發工具，可以減少出錯的幾率，防止版本沖突等。

2 如何控制代碼質量。因為團隊里大家的水平有高有低，所以團隊研發的時候，需要去建立固定的開發規范，比如：“命名規范”，“代碼包引用規范等”。當某個人解決某個功能的時候，為了確保代碼質量和減少出錯幾率，最好能畫出流程圖和配上設計意圖說明，來進行討論確定，同時也可以幫助新人快速成長。

3 需要引入新框架。有時候，某個成員會覺的某某框架的新特性非常好用或者非常合適手頭的問題，那么就想引入這個新框架，我的建議，在充分了解的基礎上來決定，不能因為某個特性而引入一堆用不到的特性，那樣會讓項目代碼顯的冗余。

4 知識總結和培訓。當某個成員遇到問題，并解決后或者學習到新東西的時候，不妨拿出來大家一起探討一下，說不定就有助于提高平臺的性能，為大家提供更好的設計思路。

三 架構優化

“過早優化是萬惡之源”，所以關于架構優化，我放在研發完成并上線之后來講。個人覺的沒有百分百可用的架構，得看你實際的業務流程和運行情況來進行優化。當你運行了一段時間后，收集到一定的數據，找出性能的弱點后進行針對性調整和優化，當平臺的負載強度達到一定程度，就得立即著手做架構升級。

有的朋友會問，有時候網站就是莫名其妙的變慢，但是不知道從何下手怎么辦，或者憑經驗改改這個改改那個選項，好了一點但好的不徹底。我的經驗是從數據開始，從最外圍開始畫圈，找到源頭。先從外圍開始收集日志，比如access_log訪問日志或sql_log數據庫操作日志，找出訪問最多的10條日志和執行時間最長的10條日志，然后根據日志去反查到底是什么引起的操作，然后一條條的解決。如果解決不了，那么就考慮重構。其他問題解決方式跟這個差不多，就不贅述了。從我自己已有的經驗來看，往往就是因為幾個功能點的惡化，引起了整體的性能變差。

所以在研發的時候，功能點的實現要好好考慮，前端部分，頁面，圖片等的大小和有效緩存，后端的局部數據和全局數據的緩存高效利用，數據庫層SQL語句盡量避免跨表查詢，數據庫索引的利用等。

四 其他相關

存儲

當平臺網站的訪問量不斷增長的同時，數據也會跟著不斷的增長，所以早期做好數據如何存儲的方案非常重要。

現在比較常見的是HASH URL，根據文件名的HASH來選擇存儲不同的目錄，比如20091014131213_abc.xxx 那么就存儲到 2009/10/14/a/20091014131213_abc.xxx這樣的目錄下，方便以后根據目錄來劃分服務器。

搜索

當平臺網站的訪問量不斷增長的同時，數據搜索也變成了一個問題。肯定有朋友會說，直接數據庫模糊查詢有什么問題，你試想當你的數據表里有幾百萬數據你用 select * from table where title like '%key%' 沒法用索引，那就是全表掃描，拿得花多少時間，一個人查詢還沒問題，那幾百個呢，那你的平臺不就歇菜了。還好現在已經有了成熟方案Lucene，只要按照它提供的接口去實現，你就可以使用。

本文名稱：平臺網站架構設計的經驗之談
分享網址：http://m.newbst.com/news2/144902.html

成都網站建設公司_創新互聯，為您提供網站策劃、小程序開發、網站維護、響應式網站、App設計、全網營銷推廣

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯