做php已經5年多了，想往架構級phper發展。請問，架構級需要掌握哪些知識，循序漸進的過程怎麼走？麻煩說的細一點
回複內容：
記得 Laruence 說過，修鍊的路大概如下：
PHP -> C -> PHP擴充 -> Linux 編程 -> 網路編程 -> 成了
然後我就開始努力學習C，擴充，linux.....
直到有天發現，尼瑪，這還是phper嗎？
=========我是一條分割線==============
補充一下：
沒有只限於php的架構師存在，放下php的標籤。
把方向改為 web 架構師，道路就清晰多了。PHP請求來了處理一下，請求結束就銷毀。作為僅僅掌控一層生命週期的程式。何來架構師，無非就是配置一下Nginx，PHP-fpm，Memcache，HaProxy ，MySQL 等軟體。
PHP程式員應該掌握系統底層和網路通訊的知識，比如多進程、多線程、Socket、Epoll等。PHP核心，擴充開發，C/C++都需要去學習。網路通訊方面建議看一下 swoole。Swoole: PHP的非同步、並行、分布式擴充
正在朝架構師的方向努力，個人意見，僅供參考：
架構師最基本的職責是將一個大系統分解為一些列程式員可以處理小模組，並在他們遇到技術痛點時給予協助。由此而來，php架構師必須要掌握的東西有：
1. 資料結構、演算法。至少要做到會用，知道什麼時候用集合，什麼時候用隊列，什麼時候用排序隊列，每種資料結構支援哪些操作，每個操作的時間複雜度是多少；能夠將實際問題用適合的資料結構描述。
2. 資料存放區: Mysql Redis 等；主從分離後並發資料一致性；關聯式資料庫和非關聯式資料庫的理論；資料庫範式，什麼時候需要反範式；SQL查詢最佳化；能夠將實際問題表述為合適資料庫結構。可閱讀《SQL查詢煩人入門》《Redis入門指南》《MySql技術內幕》
3. webserver：Nginx, Lighttpd。可閱讀《深入理解Nginx》
4. 緩衝：瀏覽器，前端伺服器，後端伺服器的多級緩衝。可閱讀《構建高效能web網站》
5. 訊息佇列：資料非同步寫入的實現方案。
6. 設計理論：物件導向，物件導向基本原則，對耦合的深入理解；設計模式，重構，代碼壞味道；架構模式。推薦：《設計模式》《大話設計模式》《重構》《敏捷式軟體開發 (Agile Software Development)：原則、模式與實踐》。
7. 設計文檔編寫：架構師需要把自己想法清楚的傳達給每個團隊成員，除了基本文檔撰寫能力，UML必知必會，visio等繪圖工具必須。
8. 軟體工程：架構師必須有能力為自己負責的項目選擇合適的開發流程，瀑布方式、螺旋迭代方式、敏捷，沒有好壞之分，只有適合於不適合；
對於只需要的php的項目，有以上能力就可以坐在架構師的位置上了。總結一下，想做架構，就不要把自己定位為phper，php只是一種的服務端指令碼語言。
但是，還有但是：
只需要php項目規模不會很大，價值也不會很大。php只是一個指令碼語言，適合做業務和快速構建產品原型。產品規模大了以後，後端很定是要遷移到Java、C++等靜態語言的。如果你不會Java、C++這類語言。那恐怕永遠也無法成為一個牛B的架構師。
所以這是一個讓人很糾結的問題，寫php多年的人，是否應該轉移到Java或C++陣營。我見過的架構師確實，php，C++，Java隨便寫的。就會一門語言就想做架構，那也只是想想的。
現在很多架構都是各個語言之間在互相學習的，何況是 架構，很多語言也是。
但這些對於架構師來說也並非是重要的。
我們要有什麼技能，首先來看看架構師要達成的目標有哪些。
既需要掌控整體又需要洞悉局部瓶頸並依據具體的業務情境給出解決方案
確認和評估系統需求，給出開發規範，搭建系統實現的核心構架，並澄清技術細節、掃清主要痛點。主要著眼於系統的“技術實現”。因此他/她應該是特定的開發平台、語言、工具的大師，對常見應用情境能馬上給出最恰當的解決方案，同時要對所屬的Team Dev有足夠的瞭解，能夠評估自己的團隊實現特定的功能需求需要的代價。 系統架構師負責設計系統整體架構，從需求到設計的每個細節都要考慮到，把握整個項目，使設計的項目盡量效率高，開發容易，維護方便，升級簡單等。
百度百科抄的。
上面的在把要點提煉出來，就是：
- 瞭解“業務情境”的情況下給出解決方案。
- 對所屬Team Dev有足夠的瞭解。
- 對於項目風險的控制。
- 對於開發流程，和系統架構的設計、把控與實施。
懂技術，可以不精，但一定要廣，可以根據需求正確的設計架構，規範開發流程，把控開發上的技術風險。
懂業務，對於業務情境有大概瞭解，至少需要在與專業的業務人員溝通時不會有障礙，並且能對於情境做正確的需求分析。
懂管理，主要是對於團隊的瞭解，任務分解中的風險，正確傳達需求。
話說回來，做架構，不懂業務行不行？不行！
如果真有通用的架構，那就不需要那麼多架構師了，所有業務領域都找個通用的架構來就好了。可能不是通用，但是大同小異啊？是的，這個“小異”弄不好是會死人的。
當然，互連網時代很多業務模式都是創新的，根本沒人懂這個業務怎麼玩，那對於架構師的要求也就不一樣了，玩法變了，變出什麼呢？所謂的“敏捷開發”，迭代更新。這就意味著架構師不需要懂業務嗎？不是的，這個只是一個摸著石頭過河，然後，有經驗了，遇到瓶頸之前加緊重構。
本屌經驗不多，剛畢業，半年經驗，但是發現如果把php作為純粹地技術研究，而不是為了賺錢，那就繼續深入，研究源碼，作為一項追求。本it狗錢還沒賺夠，只能學學其他東西，多掌握幾項技能，而把專心研究php這個偉大工程留給我賺夠錢之後了你職業生涯何必和php綁定呢，php工作幾年馬上轉:
c/c++ ->服務端架構設計 -> java 系列架構 -> jvm系列語言
c/c++ 優秀開源服務端有：
nginx 效能卓越，
ace 設計無人匹敵，
traffic server 設計和效能都不錯
java的也很有很多，推薦你看看，你就知道 外面的世界多精彩了。
jvm系列語言也有很多選擇，scala語言的kafka 卓越的訊息佇列，storm等等。
如果還繼續深入php不想轉的話，hhvm是個好選擇。
見多識廣比抱死一顆爛樹強多了，花時間學習 zend php如何寫擴充還不如去睡覺說點我的看法。屬於只看過豬跑的。
我理解的架構師職責就是提供整體的解決方案，就是負責給出功能實現的具體方案，從閱讀需求到功能設計到技術選型、最佳化重構、測試發布復原，甚至代碼風格都要給出。
這一切都以一個至多個文檔來體現，所以文檔能力對架構師而言是必須的，而決定輸出文檔品質的，就是架構師的核心能力，這包括對需求的閱讀理解能力、設計能力和技術廣度及深度。
對架構師而言，理解需求和抽象設計，應該是硬實力，這兩者達不到一定程度，是無法勝任架構師的。
除此之外，技術選型是個很重要的環節，這決定整個團隊之後所依賴的技術走向，需要權衡很多東西。
workflow的設計也很重要，好的workflow能極大提高團隊效率，如何配合技術選型來引入更多的自動化，也是架構師需要考慮的問題。
單純的phper很難成為架構師，除非是那麼兩三個人的破公司頂個架構師的名頭而已。
因為視野太窄了。
架構師的知識面要求很廣，光會一門語言是不行的。
