PHP語言的創始者Rasmus Lerdorf認為,程式不用寫得完美,而是要簡單有效,這是最重要,也是最困難的事。

PHP是全世界上使用率最高的網頁開發語言,臺灣每4個網站,就有1個用PHP語言開發。1995年發明PHP語言的Rasmus Lerdorf,也是打造出Yahoo全球服務網站的架構師之一,他首度來臺分享如何架構網站擴充性、安全性和效能的祕訣。

Q:越來越多Web 2.0網站走向應用平臺,你認為打造這類平臺的關鍵為何?

A:簡單來看,應用平臺就是API,任何Ajax或Web 2.0類型的網站,都是在應用平臺上運用了API來創造出視覺介面的互動效果。例如Yahoo Mail,透過簡單的Request呼叫,來讀取後續的信件。打造這類網站,如何規畫解決問題的方式,會決定了網站未來的擴充性(Scalability),而非效能決定網站的發展。

Q:如何規畫網站架構,才會具有擴充性?

A:將一個網站應用,分成幾十個獨立小程式,前端透過API提供服務,後端是應用程式引擎,這樣做自然會有擴充性。因為應用的每一個部分,都有不同等級的使用方式,需要有不同的擴充程度(scaling level),需要不同的機制來處理。以開發Yahoo Mail而言,是要開發一個地址服務程式、一個讀信服務、一個送信服務,而送信程式完全和讀信程式無關。以Yahoo的規模而言,需要讓這些工作完全分離,才有擴充性。

Q:這種規畫網站的方式,什麼是最重要的關鍵?

A:關鍵是你必須建立分離、模組化的獨立端點,而不是全部放在同一個大籃子裡。大多數現今MVC架構(MVC framework)的開發框架(Framework),使用所謂的前端控制器(Front Control),每一次瀏覽器提出Request請求時,就會呼叫這個前端控制器,再由前端控制器來分辨,使用者想要執行哪一支程式。這樣做,一點意義都沒有。

在瀏覽器層次,程式完全能知道使用者想要做什麼事情,例如使用者只是要讀信,程式就不用再把需求送到伺服器,讓伺服器判斷使用者要讀信還是送信。將這類決策工作拉出瀏覽器,由伺服器處理,就會浪費大量伺服器資源,來處理那些對使用者沒有實際功用的工作。擴充性來自架構,很多開發框架,將所有事情綁在一起,限制了架構。選錯開發框架,你就沒有擴充性。

Q:你是說MVC模式不利於網站擴充性?

A:MVC模式比較適合用在網頁控制器(Page Control)的層次。基本上,每一個網頁控制器都是獨立模組,讀信和查地址是不同的網頁控制器,所以,讀信程式就不會干擾到查地址程式。所以,在每一個端點使用MVC模式來打造小型的網頁控制器,是不會有問題。但是,大多數採用MVC模式的框架,預設在網站中採用前端控制器,而非用網頁控制器的方式,這樣的MVC模式,只適合在小型或單一伺服器的網站。

Q:你會如何選擇開發框架呢?

A:一個框架都不要用。但是,我會從這些開發框架中,找出我需要的功能,拿出那個我需要的程式模組來用,或者參考其中的設計想法,而不是套用整個框架。我所看到的大多數框架,都沒有專注在打造有效能的擴充性和可模組性。

Q:難道開發者不需要框架或架構嗎?

A:網站的確需要有架構,每一個人都需要框架,框架是一種解決問題的方法。但是你並不需要通用型框架,用一個前端控制器,來解決所有問題,這樣通常沒辦法成功。每一個問題都不同,你需要引導框架,使用正確的設計模式,直接解決真正要處理的問題。只生產一款汽車,怎麼可能滿足全世界人的需求!

用框架開發雛形系統就好,但真正的產品就不要全部套用。從框架開始比較容易,但你要拆開全部的框架,移除Runtime檢查、拿掉不需要的功能,只留下你會用到的程式模組。你不需要一個通用型框架,因為它無法提供未來的擴充性,但也不用重頭寫起,你需要的是介於兩者之間。

Q:網站需要規畫到多久以後的擴充需求?

A:我總是痛恨要幫未來考慮太多。當你無法預測未來,你就無法幫未來作決定。
網路變化太快,我通常只規畫半年內的事情。現在決定半年以後的事情,可能會做出錯誤決策,反而讓事情更糟。如果你沒有解決當下的問題,而是想像未來會發生的問題,我認為不值得,我寧可解決眼前看得到的問題,真正聚焦在當下需要的產品。

Q:那麼,有任何準則是架構人員可以遵循的嗎?

A:最主要的原則是,仔細考慮如何分配程式模組,盡可能將程式拆解成更小的元件,調校出適當的API,你應該規畫的是使用者端點的事情,例如瀏覽器請求的類型是什麼?應用程式要如何回應?是否可以切割?是否可以把這些工作分配到完全分離的伺服器上執行?即使是在同一臺伺服器上,你也能從使用者端點的角度來架構應用程式,有一天,當你的規模變大後,就可以很容易加入第二臺伺服器,只要在前端伺服器不儲存任何資料,就能進行流量分擔。一般開發者最大的錯誤是,讓程式碼之間的交互關連(interrelation)太深,每個不同的元件都需要和其他外元件溝通,這樣做很難調校出很乾淨的API。開發者會無法抽離出效率慢的API放到輔助伺服器中,而讓主要伺服器只執行必要API。

Q:切割服務、拆解程式的難度是什麼?

A:必須在開始之前,就要非常了解問題。當你寫完第一個版本的程式,才著手拆解問題,那幾乎是不可能,很難事後處理。這的確很難,因為問題會一直改變。但是,若你從簡單的架構開始,並且保持這個精神來區隔程式模組。每次當網站發生變化時,問題的變化也只會影響到一小部分,你就能夠非常清楚那個地方,能夠直接解決問題。就好像樂高遊戲一樣,蓋好每一個小塊積木,哪邊還有不足,就只需要再補上一小塊就好,不用對整體改變太多。

Q:除了擴充性以外,如何提高網站效能呢?

A:要提高效能,得先知道每一支程式花了多少時間。我會問,使用者送出Request請求後,要多久才會收到第一個Byte的資料?很多開發人員不曉得這個時間(First Byte Latency)是多久,不曉得自己的程式碼用掉多少時間?可以透過Profile來追蹤效能,畫出視覺化的效能流程圖,來了解瓶頸在哪。

甚至要考慮到單一機器上的延遲,透過系統層級的追蹤程式,知道程式執行的每一個系統呼叫(System Call)耗費多久。還要考慮瀏覽器中的延遲,從使用者實際感受的速度來改善網頁執行方式等。
每次你增加一個新功能,要能計算出新功能會增加多少毫秒,想一想這麼做值不值得。

Q:那麼,網站的安全性又需注意哪些原則?

A:基本精神很簡單,只要用資料防火牆的概念來設計網站。網路防火牆會嚴密監控每一個通訊埠,只讓沒有安全疑慮的封包通過,但網站開發者剛好相反,只擋掉自以為有危險的內容。開發者不能信賴任何從外部取得的資料,借用防火牆概念和手法,建立資料防火牆,就能提高網站安全性。

Q:好的架構師需要什麼樣的條件?

A:必須非常了解技術,了解每一個細節,例如設計資料儲存機制,要了解哪種資料可以儲存、可以存多大的檔案,放多少資料、每秒鐘可以放多快?如何複製資料?前端必須使用哪種資料格式等。架構師可以不用像DBA,知道如何修復Oracle資料庫的錯誤,但是要能夠了解Oracle資料庫擁有的能耐。這種人很難找,必須要失敗過很多次,才會有足夠的經驗。

Q:臺灣還有不少舊網站使用PHP 4,他們應該現在升級到PHP 5嗎?還是等待PHP 6?

A:盡快升級到PHP 5。只要作一些測試和修改,就能得到更好的效能和安全,為什麼不做?不需等待PHP 6,開源社群的運作方式,無法承諾推出時間。很多新功能已經放到PHP 5.3版中,趕快從4升到5最重要。採訪整理⊙王宏仁


Advertisement

更多 iThome相關內容