業(yè)務專線：13711534025
從架構(gòu)設計師的角度來看，架構(gòu)就是一套構(gòu)建系統(tǒng)的準則。通過這套準則，我們可以把一個復雜的系統(tǒng)劃分為一套更簡單的子系統(tǒng)的集合，這些子系統(tǒng)之間應該保持相互獨立，并與整個系統(tǒng)保持一致。而且每一個子系統(tǒng)還可以繼續(xù)細分下去，從而構(gòu)成一個復雜的企業(yè)級架構(gòu)。
一 選擇技術(shù)方案和物理架構(gòu)
如何選擇技術(shù)方案和物理架構(gòu)，對很多剛接觸平臺網(wǎng)站研發(fā)的人來說這可能是個頭疼的問題。這些問題的源頭很簡單就是能否提高開發(fā)效率，使平臺具有高性能高負載性。就我遇到的常見的有這么幾個問題：
a） 開發(fā)語言和數(shù)據(jù)庫
一說到開發(fā)語言和數(shù)據(jù)庫，很多人便開始做語言的比較，最常見的爭論有：“asp.net和java哪個好”，“解釋性語言和編譯性語言哪個好”等。我個人覺的最關鍵是你和你的團隊最擅長的開發(fā)語言和數(shù)據(jù)庫是哪個，古語有云：“工欲善其事，必先利其器！”，趁手的開發(fā)語言和數(shù)據(jù)庫有助于事半功倍。試想如果你選擇了一個并不很熟悉的語言，也許這個語言和數(shù)據(jù)庫在基礎性能上的確比你掌握的語言好，但是在研發(fā)過程中學習曲線肯定長。而且遇到問題的時候因為不熟悉的原因，浪費更多的時間去尋找解決方法，而且找到的方法不一定是最好的，說不定還不如你自己用熟悉的語言解決來的快。
也許有朋友會說：“這幾種開發(fā)語言和數(shù)據(jù)庫我都熟悉”，那么就要看你對這幾種開發(fā)語言和數(shù)據(jù)庫的熟悉程度了，對各種開發(fā)語言和數(shù)據(jù)庫的特性了解的越深入，越有助于提高開發(fā)效率。而且目前主流的開發(fā)語言和數(shù)據(jù)庫都提供性能調(diào)優(yōu)，只有深入了解了開發(fā)語言和數(shù)據(jù)庫的特性和原理，那么性能調(diào)優(yōu)就很容易。
個人覺的重要的就這兩點，開發(fā)效率和性能。
b） 成熟框架還是自己實現(xiàn)
目前主流的開發(fā)語言的使用者中有很多前輩都提供了他們自己總結(jié)實現(xiàn)的框架，比如JAVA中的“S-S-H”組合，PYTHON的DJANGOO等。我個人的一些經(jīng)驗是，盡量使用開源的成熟框架，因為平臺研發(fā)初期使用成熟的開源框架，能提高開發(fā)效率，并且在質(zhì)量上有保證。我曾經(jīng)接手過一個平臺的改版，框架是前面開發(fā)人員自己寫的，里面的一些設計思想不是很成熟，導致平臺在負載增高后性能很差，整改起來很麻煩，只能一點一點的分離出來，耗費時間和經(jīng)歷。
有的朋友可能會問什么才是成熟的框架，個人總結(jié)的幾點：
1 能提供使用指南，比如 COOKBOOK， USE GUIDE等。有這些提供，那么入門使用變的容易，也方便維護，而且有助于深入了解其特性和原理。
2 有官方支持，比如官方討論社區(qū)，郵件列表等，并且有BUG收集處理機制。有句話叫大樹底下好乘涼，有了官方支持，當使用過程中遇到問題的時候，直接就可以通過查找前人的使用心得和問題來解決問題，遇到BUG的時候，提交上去，也能找到解決之法。
3 官方在不斷的更新發(fā)布穩(wěn)定版本。這一點很重要，官方如果及時幫你解決目前已知的或者未知的BUG，那么對使用者來講，就沒什么后顧之憂了，如果官方停止更新了，那么我建議還是早點換下家吧，因為如果這個框架好，那么肯定會越來越好，官方也會不斷的更新它。還有就是穩(wěn)定永遠是第一位，可以在不影響生產(chǎn)環(huán)境的情況下進行無縫升級更新。
4 身邊使用者很多，經(jīng)常能看到相關的討論或者總結(jié)。目前很多成熟框架都是國外開發(fā)者發(fā)布的，如果使用者E文不好也是個討厭的事情，那么如果身邊有很多同樣的使用者和很多討論，那么對于使用者來說是種福音，共同探討和學習。
那么除此之外最好是開源的框架，平臺初期訪問量不大，因此對性能的要求不高，成熟的框架的使用都不會出現(xiàn)什么問題。當訪問量急劇增高之后，那么性能要求也變高，一些框架中隱藏的問題也因此出現(xiàn)。這時候如果是開源的框架，使用者可以深入了解它的源代碼，洞悉其實現(xiàn)機制，根據(jù)自己的實際情況進行調(diào)優(yōu)。如果不是那么使用者也只能改變方向去解決問題，條條大路通羅馬。
c） web server/db server/cache server 相關
在架構(gòu)設計中web server/db server/cache server是很重要的一點，我個人覺的這一塊必須是使用具有前瞻性，易配置，能監(jiān)控和維護的產(chǎn)品，總結(jié)的幾點：
1 豐富和深入的配置選項。如果能提供豐富和深入的配置選項，那么在安全和性能調(diào)整上可以很方便的進行操作，并且不中斷實際的生產(chǎn)環(huán)境。
2 基于高并發(fā)模型。比如這幾年熱門的基于epoll的nginx，可以有效的減少連接處理時間，增大同時并發(fā)數(shù)。
3 支持負載均衡和請求分發(fā)。當平臺的訪問量增高之后，單臺服務器肯定是很難支撐，這時候就需要增加服務器來分擔壓力，這時候server的負載均衡和請求分發(fā)就很重要了。
4 高效的緩存機制。高效的緩存機制可以幫助平臺提高負載能力，減少重復資源的讀取和處理時間。比如用于小文件緩存的SQUID，VARNISH，用于數(shù)據(jù)庫緩存的memcached等。
5 實時的狀態(tài)監(jiān)控機制。實時的監(jiān)控狀態(tài)報告，可以有助于平臺維護人員迅速了解平臺性能運行狀況，根據(jù)狀況進行調(diào)整。
如果是開源的那就更好了，可以深入了解其源代碼，并根據(jù)自己的實際需要進行配置和定制。
d） 操作系統(tǒng)
選擇合適的操作系統(tǒng)，個人覺的最主要是穩(wěn)定安全，易管理和維護，易監(jiān)控。穩(wěn)定安全的操作系統(tǒng)一般官方會持續(xù)的發(fā)布補丁和新版本，解決BUG和漏洞等。并且官方或者第三方會不斷的提供新的管理維護監(jiān)控工具，并且能讓管理維護人員通過編寫腳本來維護管理。而且合適的操作系統(tǒng)能讓研發(fā)人員充分利用其特性，發(fā)揮平臺的最大性能。
f） 物理架構(gòu)
這里的物理架構(gòu)是指服務器的搭建方式。有的朋友可能資源有限只有一臺服務器，有的朋友資源充分有十幾臺服務器或者更多，我個人覺的這都不是問題。平臺初期的話，我想大部分訪問量都不高，web server/db server/cache server放在一臺服務器上都沒問題。但是自己心里最好能預估一下這個平臺會發(fā)展到什么樣的規(guī)模，在做架構(gòu)設計的時候，按照事先預估的來決定怎么做物理架構(gòu)，并為以后的架構(gòu)升級做準備。說到這里，想到前百度架構(gòu)師雷鳴說過的一句話，當你的會員數(shù)達到目前的5倍或10倍的時候，架構(gòu)就要升級。
二 平臺研發(fā)
前期做好了技術(shù)方案，就進入到實質(zhì)研發(fā)過程中來了，個人感覺平臺網(wǎng)站的研發(fā)有別于傳統(tǒng)的IT項目研發(fā)，因為以前就是客戶/需求分析人員/美工之間進行交涉，而現(xiàn)在平臺網(wǎng)站研發(fā)會多接觸一個角色叫產(chǎn)品，產(chǎn)品決定了最后的平臺網(wǎng)站是什么樣的，有什么功能，每個功能的流程和用例是什么樣子的，也就是原型設計。并且在研發(fā)人員實現(xiàn)之后，還要由測試人員進行測試。
在上述過程中，產(chǎn)品會經(jīng)常要求研發(fā)人員：“某某功能是這樣的，你趕快給我實現(xiàn)并解決。這個功能不對，要改。那個功能出現(xiàn)問題，要改”，而研發(fā)人員可能正在忙著其他功能的實現(xiàn)，于是很容易產(chǎn)生沖突。在此我推薦使用敏捷開發(fā)方式，設立短的發(fā)布周期進行迭代開發(fā)，產(chǎn)品提出來的問題統(tǒng)一在一個周期內(nèi)解決，到下一個周期一起發(fā)布，到下一個周期再進行下一周期的功能改進和BUG修正。并使用JIRA這種成熟的項目管理系統(tǒng)進行管理，為以前的更改留下歷史，總結(jié)經(jīng)驗。
那么在正常的研發(fā)過程中，特別是團隊研發(fā)，我個人覺的需要注意的幾點：
1 合適的開發(fā)工具。還是那句話“工欲善其事，必先利其器！”，使用合適的開發(fā)工具和插件，能提高開發(fā)效率，節(jié)省開發(fā)成本。團隊使用統(tǒng)一的開發(fā)工具，可以減少出錯的幾率，防止版本沖突等。
2 如何控制代碼質(zhì)量。因為團隊里大家的水平有高有低，所以團隊研發(fā)的時候，需要去建立固定的開發(fā)規(guī)范，比如：“命名規(guī)范”，“代碼包引用規(guī)范等”。當某個人解決某個功能的時候，為了確保代碼質(zhì)量和減少出錯幾率，最好能畫出流程圖和配上設計意圖說明，來進行討論確定，同時也可以幫助新人快速成長。
3 需要引入新框架。有時候，某個成員會覺的某某框架的新特性非常好用或者非常合適手頭的問題，那么就想引入這個新框架，我的建議，在充分了解的基礎上來決定，不能因為某個特性而引入一堆用不到的特性，那樣會讓項目代碼顯的冗余。
4 知識總結(jié)和培訓。當某個成員遇到問題，并解決后或者學習到新東西的時候，不妨拿出來大家一起探討一下，說不定就有助于提高平臺的性能，為大家提供更好的設計思路。
三 架構(gòu)優(yōu)化
“過早優(yōu)化是萬惡之源”，所以關于架構(gòu)優(yōu)化，我放在研發(fā)完成并上線之后來講。個人覺的沒有百分百可用的架構(gòu)，得看你實際的業(yè)務流程和運行情況來進行優(yōu)化。當你運行了一段時間后，收集到一定的數(shù)據(jù)，找出性能的弱點后進行針對性調(diào)整和優(yōu)化，當平臺的負載強度達到一定程度，就得立即著手做架構(gòu)升級。
有的朋友會問，有時候網(wǎng)站就是莫名其妙的變慢，但是不知道從何下手怎么辦，或者憑經(jīng)驗改改這個改改那個選項，好了一點但好的不徹底。我的經(jīng)驗是從數(shù)據(jù)開始，從最外圍開始畫圈，找到源頭。先從外圍開始收集日志，比如access_log訪問日志或sql_log數(shù)據(jù)庫操作日志，找出訪問最多的10條日志和執(zhí)行時間最長的10條日志，然后根據(jù)日志去反查到底是什么引起的操作，然后一條條的解決。如果解決不了，那么就考慮重構(gòu)。其他問題解決方式跟這個差不多，就不贅述了。從我自己已有的經(jīng)驗來看，往往就是因為幾個功能點的惡化，引起了整體的性能變差。
所以在研發(fā)的時候，功能點的實現(xiàn)要好好考慮，前端部分，頁面，圖片等的大小和有效緩存，后端的局部數(shù)據(jù)和全局數(shù)據(jù)的緩存高效利用，數(shù)據(jù)庫層SQL語句盡量避免跨表查詢，數(shù)據(jù)庫索引的利用等。
四 其他相關
存儲
當平臺網(wǎng)站的訪問量不斷增長的同時，數(shù)據(jù)也會跟著不斷的增長，所以早期做好數(shù)據(jù)如何存儲的方案非常重要。
現(xiàn)在比較常見的是HASH URL，根據(jù)文件名的HASH來選擇存儲不同的目錄，比如20091014131213_abc.xxx 那么就存儲到 2009/10/14/a/20091014131213_abc.xxx這樣的目錄下，方便以后根據(jù)目錄來劃分服務器。
搜索
當平臺網(wǎng)站的訪問量不斷增長的同時，數(shù)據(jù)搜索也變成了一個問題。肯定有朋友會說，直接數(shù)據(jù)庫模糊查詢有什么問題，你試想當你的數(shù)據(jù)表里有幾百萬數(shù)據(jù)你用 select * from table where title like '%key%' 沒法用索引，那就是全表掃描，拿得花多少時間，一個人查詢還沒問題，那幾百個呢，那你的平臺不就歇菜了。還好現(xiàn)在已經(jīng)有了成熟方案Lucene，只要按照它提供的接口去實現(xiàn)，你就可以使用。
