Q：越來越多Web 2.0網(wǎng)站走向應用平臺，你認為打造這類平臺的關鍵為何？

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

Q：如何規(guī)畫網(wǎng)站架構，才會具有擴充性？

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

Q：這種規(guī)畫網(wǎng)站的方式，什麼是最重要的關鍵？

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

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

Q：你是說MVC模式不利於網(wǎng)站擴充性？

A：MVC模式比較適合用在網(wǎng)頁控制器（Page Control）的層次?；旧?，每一個網(wǎng)頁控制器都是獨立模組，讀信和查地址是不同的網(wǎng)頁控制器，所以，讀信程式就不會干擾到查地址程式。所以，在每一個端點使用MVC模式來打造小型的網(wǎng)頁控制器，是不會有問題。但是，大多數(shù)采用MVC模式的框架，預設在網(wǎng)站中采用前端控制器，而非用網(wǎng)頁控制器的方式，這樣的MVC模式，只適合在小型或單一伺服器的網(wǎng)站。

Q：你會如何選擇開發(fā)框架呢？

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

Q：難道開發(fā)者不需要框架或架構嗎？

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

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

Q：網(wǎng)站需要規(guī)畫到多久以後的擴充需求？

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

Q：那麼，有任何準則是架構人員可以遵循的嗎？

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

Q：切割服務丶拆解程式的難度是什麼？

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

Q：除了擴充性以外，如何提高網(wǎng)站效能呢？

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

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

Q：那麼，網(wǎng)站的安全性又需注意哪些原則？

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

Q：好的架構師需要什麼樣的條件？

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

Q：臺灣還有不少舊網(wǎng)站使用PHP 4，他們應該現(xiàn)在升級到PHP 5嗎？還是等待PHP 6？

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

最新評論