PHP工程師往架構師方向需要注意哪些。

突然看到這篇文章, 值得反省, 樂在其中, 在接下來的發展中不被淘汰的都來看看，

如何成為乙個架構師

先明確這裡所指的php工程師，是指主要以php進行web系統的開發，沒有使用其的語言工作過。工作經驗大概在3~4年，普通的web系統（百萬級訪問，千成級資料以內或業務邏輯不是特別複雜）開發起基本得心應手，沒有什麼問題。但他們會有這樣的誤點：

◆ 除了php不使用其它的語言，可能會點shell 指令碼。

◆ 對php的掌握不精（很多php手冊都沒有看完，庫除外）。

◆ 知識面比較窄（面對需求，除開使用php和mysql，不知道其它的解決辦法）。

◆ php**以過程為主，認為物件導向的實現太繞，看不懂。

這些phper在遇到需要高效能，處理高併發，大量資料的專案或業務邏輯比較複雜（系統需要解決多領域業務的問題）時，缺少思路。不能分析問題的本質，技術判斷力比較差，對於問題較快能找出臨時的解決辦法，但常常在不斷臨時性的解決辦法中，系統和自己一步步走向崩潰。那怎麼提高自己呢？怎麼可以挑戰難度更高的系統？

更高的挑戰在那裡？

結合我自己的經驗，我列出一些具體挑戰，讓大家先有個感性的認識。

高效能系統的挑戰在那裡？

◆ 如何選擇web伺服器？要不要使用fast-cgi 模式；

◆ 要不要使用反向**服務？選擇全記憶體快取還是硬碟快取？

◆ 是否需要負載均衡？是基於應用層，還是網路層？如何保證高可靠性？

◆ 你的php**效能如何，使用優化工具後怎麼樣？效能瓶頸在那裡？是否需要寫成c的擴充套件？

◆ 使用者訪問有什麼特點，是讀多還是寫多？是否需要讀寫分離？

◆ 資料如何儲存？寫入速度和讀出速度如何？資料增漲訪問速讀如何變化？

◆ 如何使用快取？怎麼樣考慮失效？資料的一致性怎麼保證？

高複雜性系統的挑戰在那裡？

◆ 能否識別業務所對應的領域？是乙個還是多個？

◆ 能否合理對業務進行抽象，在業務規則變化能以很小的代價實現？

◆ 資料的一致性、安全性可否保證？

◆ 是否撐握了物件導向的分析和設計的方法？

這裡所列出的問題，你都能肯定的回答，說明在技術上你基本已經可能成為架構師了。如何你還不能回答，你需要在以下幾個方向加強。

怎麼樣提高，突破瓶頸

如何你還不能回答，你需要在以下幾個方向加強：

◆ 分析你所使用的技術其原理和背後執行的機制，這樣可以提高你的技術判斷力，提高你技術方案選擇的正確性；

◆ 學習大學期間重要的知識，作業系統原理，資料結構和演算法。知道你以前學習都是為了考試，但現在你需要為自己學習，讓自己知其所以然；

◆ 重新開始學習c語言，雖然你在大學已經學過。這不僅是因為你可能需要寫php擴充套件，而且還因為，在做c的應用中，有乙個時刻關心效能、記憶體控制、變數生命週期、資料結構和演算法的環境；

◆ 學習物件導向的分析與設計，它是解決複雜問題的有效的方法。學習抽象，它是解決複雜問題的唯一之道。