從架構設計師的角度來看，架構就是一套構建系統的準則。通過這套準則，我們可以把一個複雜的系統劃分為一套更簡單的子系統的集合，這些子系統之間應該保持相互獨立，並與整個系統保持一致。而且每一個子系統還可以繼續細分下去，從而構成一個複雜的企業級架構。
一選擇技術方案和物理架構
如何選擇技術方案和物理架構，對很多剛接觸平台網站研發的人來說這可能是個頭疼的問題。這些問題的源頭很簡單就是能否提高開發效率，使平台具有高性能高負載性。就我遇到的常見的有這麼幾個問題：
a） 開發語言和數據庫
一說到開發語言和數據庫，很多人便開始做語言的比較，最常見的爭論有：“asp.net和java哪個好”，“解釋性語言和編譯性語言哪個好”等。我個人覺的最關鍵是你和你的團隊最擅長的開發語言和數據庫是哪個，古語有云：“工欲善其事，必先利其器！ ”，趁手的開發語言和數據庫有助於事半功倍。試想如果你選擇了一個並不很熟悉的語言，也許這個語言和數據庫在基礎性能上的確比你掌握的語言好，但是在研發過程中學習曲線肯定長。而且遇到問題的時候因為不熟悉的原因，浪費更多的時間去尋找解決方法，而且找到的方法不一定是最好的，說不定還不如你自己用熟悉的語言解決來的快。
也許有朋友會說：“這幾種開發語言和數據庫我都熟悉”，那麼就要看你對這幾種開發語言和數據庫的熟悉程度了，對各種開發語言和數據庫的特性了解的越深入，越有助於提高開發效率。而且目前主流的開發語言和數據庫都提供性能調優，只有深入了解了開發語言和數據庫的特性和原理，那麼性能調優就很容易。
個人覺的重要的就這兩點，開發效率和性能。
b） 成熟框架還是自己實現
目前主流的開發語言的使用者中有很多前輩都提供了他們自己總結實現的框架，比如JAVA中的“SS -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，只要按照它提供的接口去實現，你就可以使用。
五相關資料
架構實例
來源：讀者歐拉投稿QQ：4465618
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，文章转自月光博客