Q：越來(lái)越多Web 2.0網(wǎng)站走向應(yīng)用平臺(tái),，你認(rèn)為打造這類平臺(tái)的關(guān)鍵為何,？ 

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

Q：如何規(guī)畫(huà)網(wǎng)站架構(gòu),，才會(huì)具有擴(kuò)充性,？ 

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

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

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

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

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

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

Q：你會(huì)如何選擇開(kāi)發(fā)框架呢,？ 

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

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

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

用框架開(kāi)發(fā)雛形系統(tǒng)就好,，但真正的產(chǎn)品就不要全部套用,。從框架開(kāi)始比較容易，但你要拆開(kāi)全部的框架,，移除Runtime檢查丶拿掉不需要的功能,，只留下你會(huì)用到的程式模組。你不需要一個(gè)通用型框架,，因?yàn)樗鼰o(wú)法提供未來(lái)的擴(kuò)充性,，但也不用重頭寫(xiě)起，你需要的是介於兩者之間,。 

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

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

Q：那麼,，有任何準(zhǔn)則是架構(gòu)人員可以遵循的嗎,？ 

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

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

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

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

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

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

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

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

Q：好的架構(gòu)師需要什麼樣的條件,？ 

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

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

A：盡快升級(jí)到PHP 5。只要作一些測(cè)試和修改,，就能得到更好的效能和安全,，為什麼不做？不需等待PHP 6,，開(kāi)源社群的運(yùn)作方式,，無(wú)法承諾推出時(shí)間。很多新功能已經(jīng)放到PHP 5.3版中,，趕快從4升到5最重要,。