初創網站與開源軟件

前面有一篇文章中提到過開源軟件，不過主要是在系統運維的角度去講的，主要分析一些系統級的開源軟件(例如bind,memcached)，這裏我們討論
的是用於搭建初創網站應用的開源軟件(例如phpbb,phparticle)，運行在Linux，MySQL，Apache,PHP,Java等下面。
創業期的網站往往採用比較簡單的系統架構，或者是直接使用比較成熟的開源軟件。使用開源軟件的好處是搭建速度快，基本不需要開發，買個空間域名，下個軟件
一搭建，用個半天就搞定了，一個嶄新的網站就開張了，在前期可以極大程度的節約時間成本和開發成本。
當然使用開源軟件搭建應用也存在一些侷限性，這是我們要重點研究的，而研究的目的就是如何在開源軟件選型時以及接下來的維護過程中儘量避免。
一方面是開源軟件一般只有在比較成熟的領域纔有，如果是一些創新型的項目很難找到合適的開源軟件，這個時候沒什麼好的解決辦法，如果非要用開源的話一般會
找一個最相似的改一下。實際上目前開源的項目也比較多了，在sf.net上可以找到各種各樣的開源項目。選型的時候儘量應該選取一個程序架構比較簡單的，
不一定越簡單越好，但一定要簡單，一目瞭然，別用什麼太高級的特性，互聯網應用項目不需要太複雜的框架。原因有兩個，一個是框架複雜無非是爲了實現更好的
可擴展性和更清晰的層次，而我們正在做的互聯網應用範圍一般會比開源軟件設計時所考慮的範圍小的多，所以有的應用會顯得設計過度，另外追求完美的層次劃分
導致的太複雜的繼承派生關係也會影響到整個系統維護的工作量。建議應用只需要包含三個層就可以了，數據(實體)層，業務邏輯層，表現層。太複雜的設計容易
降低開發效率，提高維護成本，在出現性能問題或者突發事件的時候也不容易找到原因。
另外一個問題是開源軟件的後期維護和繼續開發可能會存在問題，這一點不是絕對的，取決於開源軟件的架構是否清晰合理，擴展性好，如果是較小的改動可能一般
不會存在什麼問題，例如添加一項用戶屬性或者文章屬性，但有些需求可能就不是很容易實現了。例如網站發展到一定階段後可能會考慮擴展產品線，原來只提供一
個論壇加上cms，現在要再加上商城，那用戶系統就會有問題，如何解決這個問題已經不僅僅是改一下論壇或者cms就可以解決了，這個時候我們需要上升到更
高的層次來考慮問題，是否需要建立針對整個網站的用戶認證系統，實現單點登錄，用戶可以在產品間無縫切換而且保持登錄狀態。由於網站初始的用戶數據可能大
部分都存放在論壇裏，這個時候我們需要把用戶數據獨立出來就會碰到麻煩，如何既能把用戶數據獨立出來又不影響論壇原有系統的繼續運行會是件很頭痛的事情。
經過一段時間的運行，除非是特別好的設計以及比較好的維護，一般都會在論壇裏存在各種各樣亂七八糟的對用戶信息的調用，而且是直接針對數據庫的，這樣如果
要將用戶數據移走的話要修改代碼的工作量將不容忽視，而另外一個解決辦法是複製一份用戶數據出來，以新的用戶數據庫爲主，論壇裏的用戶數據通過同步或異步
的機制實現同步。最好的解決辦法就是在選型時選一個數據層封裝的比較好的，sql代碼不要到處飛的軟件，然後在維護的時候保持系統原有的優良風格，把所有
涉及到數據庫的操作都放到數據層或者實體層裏，這樣無論對數據進行什麼擴展，代碼修改起來都比較方便，基本不會對上層的代碼產生影響。
網站訪問速度問題對初創網站來說一般考慮的比較少，買個空間或者託管服務器，搭建好應用後基本上就開始運轉了，只有到真正面臨極大的速度訪問瓶頸後纔會真
正對這個問題產生重視。實際上在從網站的開始階段開始，速度問題就會一直存在，並且會隨着網站的發展也不斷演進。一個網站最基本的要求，就是有比較快的訪
問速度，沒有速度，再好的內容或服務也出不來。所以，訪問速度在網站初創的時候就需要考慮，無論是採用開源軟件還是自己開發都需要注意，數據層儘量能夠正
確，高效的使用SQL。SQL包含的語法比較複雜，實現同樣一個效果如果考慮到應用層的的不同實現方法，可能有好幾種方法，但裏面只有一種是最高效的，而
通常情況下，高效的SQL一般是那個最簡單的SQL。在初期這個問題可能不是特別明顯，當訪問量大起來以後，這個可能成爲最主要的性能瓶頸，各種雜亂無章
的SQL會讓人看的瘋掉。當然前期沒注意的話後期也有解決辦法，只不過可能不會解決的特別徹底，但還是要吧非常有效的提升性能。看MySQL的
SlowQuery
Log是一個最爲簡便的方法，把執行時間超過1秒的查詢記錄下來，然後分析，把該加的索引加上，該簡單的SQL簡化。另外也可以通過
Showprocesslist查看當前數據庫服務器的死鎖進程，從而鎖定導致問題的SQL語句。另外在數據庫配置文件上可以做一些優化，也可以很好的提
升性能，這些文章在網站也比較多，這裏就不展開。
這些工作都做了以後，下面數據庫如果再出現性能問題就需要考慮多臺服務器了，一臺服務器已經解決不了問題了，我以前的文章中也提到過，這裏也不再展開。
其它解決速度問題的辦法就不僅僅是在應用裏面就可以實現的了，需要從更高的高度去設計系統，考慮到服務器，網絡的架構，以及各種系統級應用軟件的配合，這
裏也不再展開。
良好設計並實現的應用+中間件+良好的分佈式設計的數據庫+良好的系統配置+良好的服務器/網絡結構，就可以支撐起一個較大規模的網站了，加上前面的幾篇
文章，一個小網站發展到大網站的過程基本上就齊了。這個過程會是一個充滿艱辛和樂趣的過程，也是一個可以逐漸過渡的過程，主動出擊，提前考慮，減少救火可
以讓這個過程輕鬆一些。…