PHP的架構通常用於小型項目嗎？SegmentFault

像大型項目怎麼辦呢？不用架構。都自己手寫膜？
還是不用PHP。用其他語言做？

回複內容：

像大型項目怎麼辦呢？不用架構。都自己手寫膜？
還是不用PHP。用其他語言做？

猶豫了一下還是來回答一下這個問題，這是我面試的時候經常問的問題，因為每個架構和每個項目都是不一樣的，選擇架構是一件非常看經驗和思考判斷能力的東西。

項目大小隻是決策的一個根據而已，甚至還是不怎麼重要的一個根據。下面聊聊我認為選擇架構時需要注意的地方

團隊成員情況 & 未來團隊成員情況 & 所在地職業市場情況

首先，如果團隊現在和未來都只有你一個人（比如自己的toy project），那選自己最想用的就好。但只要不是這個情況，你最好先得瞭解市面上常見的各種架構，然後忘記自己的個人偏好。

瞭解你的團隊成員的現在情況，考慮你的團隊未來的發展速度，未來可能加入的團隊成員的情況，以及你所在地職業市場情況。打比方說，Laravel或許是個不錯的選擇，但如果你在二三線城市，團隊又必須高速發展大量招人，選擇Laravel可能很快會讓你陷進“composer和現代PHP技能培訓班”的窘境，布教是一項偉大的事業，但不是你的職業

專案生命週期 & 未來演變方向

這就是我覺得遠遠比項目大小要重要的因素之一。有的項目，作為貴司的主營業務是需要長期維護，持續迭代的。而另一些項目可能作為一些邊角、過渡的項目，可能做完以後不會再有什麼後續的需求。最後還有一些外包／類外包的項目，交付以後就沒有需求／後續需求可以當另一個項目。

再大的項目，需求再多，如果是第三種，無需考慮未來演變的，那麼架構的擴充性就能夠被犧牲（從而換取開發速度或其他好處），打比方說wordpress改改之類的選擇就可以被考慮。再小的項目，如果是貴司的主營業務，持續迭代的，那麼就算工作量再小，也必須謹慎考慮架構的擴充性。

那麼，什麼是架構的擴充性呢？ CI是擴充性很好的架構嗎？ZendFramework1/2是擴充性很好的架構嗎？

答案是，看未來演變方向。有的項目未來的壓力在訪問流量大，有的壓力在資料量大檢索頻繁，也有項目壓力在需求迭代快，變動頻繁而周期短。項目面臨的問題越是普遍，那麼預設各種解決方案的架構可能越能減少重複造輪子，反之項目面臨的問題越是極端，那麼輕量化的那些架構可能更適合讓你的團隊自己研究解決方案嫁接到架構中。另外，項目維護的時間越長，變動越難預測，採用預設各種解決方案的架構的風險就會越大（那些預設的解決方案恰好能解決你的每個問題的機率越來越小）

架構本身的基本素質

效能和跑分。除了phalcon和Yaf兩個C實現的架構，其他架構請認為一樣快。另外除非你在主持類似新浪微博更換PHP架構這樣的事，或者說除非你管理的項目web機器超過100台，請忽略PHP架構的效能因素

psr和composer親和性。這是雙刃劍，前面已經聊過怎麼看待這個特質了。

安全性。某些架構甚至本身自己有安全性漏洞不多說。另外如果架構層面提供了一些安全方面的東西，建議還是要簡單看一遍代碼，有時那可能反而不如自己寫。

功能性。也就是預設的解決方案的數量和品質，前面有提過。

模組化程度。架構內的各個部分是否能夠自訂，自訂的代價多高。

業務代碼量(？)很難找到對應的詞，總之有第三個特性和前面兩個（功能性&模組化程度）一起，無法達到三者兼得。功能特別多，模組化程度又高可以隨意定製、替換的架構，往往普通的業務代碼也要寫一堆。 一句話能寫出一大堆功能的架構，往往模組化程度不理想，不容易自訂。 模組化程度高，而業務代碼不囉嗦的架構，則往往沒有豐富的預設功能。

周邊生態和活躍程度以及相容性。活躍的架構就還有成長和改進的空間，但相應過於活躍有時會導致應用無法相容。另一個指標是周邊的生態，有沒有其他人基於這個架構開發一些周邊的模組／外掛程式之類的東西。

最後，如果一定要用“大”“小”這樣粗暴的詞語來描述架構和項目的話，我的建議是大項目用小架構，小項目用大架構。如果你看懂了我前面的說法，那應該能理解為什麼我會這麼說。

小型項目用一些流行的架構什麼的。
大型項目，都會自己寫架構的。而自己寫的也會參考一些成熟的架構，去掉一些不用的功能或著最佳化。
而你要是學習的話建議先看看thinkphp 之後看看laravel 最後看看Phalcon 。

小論壇PunBB和大論壇Discuz!都是沒有採用架構的PHP程式,可見,架構不是項目必需的東西.
PHP本身就是一個Web架構,自己分離介面和邏輯,實現MVC即可,比如:
前台:

/post.php?id=1024                        //頁面控制器(處理輸入,調用模型,整合資料,輸出視圖)    /include/common.php                  //執行一些公用操作,載入公用庫(承上啟下).        /config.php                      //全域配置        /include/functions.php           //系統函數(模型,SQL增刪改查,預先處理參數化查詢防止SQL注入)        /themes/default/functions.php    //主題自訂函數    /include/database.php                //按需串連資料庫    /themes/default/post.php             //視圖(htmlspecialchars/HTMLPurifier防止XSS)        /themes/default/header.php       //公用頭部(common.js)        /themes/default/footer.php       //公用尾部

後台:

/admin/post.php                                //頁面控制器(處理輸入,調用模型,整合資料,輸出視圖)    /include/common_admin.php                  //執行一些公用操作,載入公用庫(承上啟下).        /config.php                            //全域配置        /include/functions.php                 //系統函數(模型,SQL增刪改查,預先處理參數化查詢防止SQL注入)        /admin/themes/default/functions.php    //後台主題自訂函數    /include/database.php                      //按需串連資料庫    /admin/themes/default/post.php             //視圖(htmlspecialchars/HTMLPurifier防止XSS)        /admin/themes/default/header.php       //公用頭部(common.js)        /admin/themes/default/footer.php       //公用尾部

越大的項目，越需要架構來統一思想和規範，不然開發人員一多，各搞各的，還怎麼玩？只是架構本身選擇自己開發，還是選擇用現有來源架構的問題。

中型大型完全沒有壓力，可超大型就不太合適了。應該來說適合中型中大型應用開發

不知道在你眼裡百度貼吧算不算大項目，在沒有遷到hhvm前一直是用的php，

不是要用，是必然要用。但是大公司的架構不一定是外面熟知的那些架構。比如百度，是根據Yaf擴充的、

這個要看情況，PHP確實比較適合中小型項目，因為PHP開發週期短，效率比較高。但是大型的公司也會采

用PHP,比如新浪微博，他有能力改進PHP，有人有那個實力去寫PHP高可用擴充，能把PHP的效能發揮到極

致，然後藉助於Nosql，可以把高並發完全淩駕於mysql之上。現在微博的Redis叢集是非常大的，有好多

操作根本進不到資料庫操作那一層，在Re/mc中就解決了，所以PHP用於什麼樣的項目還是要看團隊，看駕

馭PHP的能力。

大型項目一樣有用php的呀，你看一個架構敢叫企業級開發架構，那一般就可以開發大型項目，當然這個大型還得看你項目具體有多大

小、中、大型的項目都可以採用架構！有條件的話，建議盡量使用架構。

既然別人已經寫好了那麼多架構，那麼就不要再去重複造輪子了，而是學習怎麼使用它。

去學習一些重量級的架構，像Symfony、Yii、Phalcon、Laravel等等，
這些架構在很多大項目中都有使用。當然如果你以後參與到中、大項目中，也很可能會接觸到他們，
你現在學習並使用他們，是為你以後打下鋪墊！

一個重量級的架構，牽涉到的東西很多，也有助於深入學習PHP。

https://github.com/lloydzhou/router

項目何為大何為小，一般所謂的大項目都被分解為若干小項目，這些“小項目”又會有各自的語言和架構的實現，

無論大小項目，基本效能瓶頸都不在php，除非你故意寫的很爛，即便如此php也是極快的。
瓶頸多在資料庫。

