|
|
A：簡單來看，應(yīng)用平臺就是API，任何Ajax或 Web 2.0類型的網(wǎng)站，都是在應(yīng)用平臺上運用了API來創(chuàng)造出視覺介面的互動效果。例如Yahoo Mail，透過簡單的Request呼叫，來讀取後續(xù)的信件。打造這類網(wǎng)站，如何規(guī)畫解決問題的方式，會決定了網(wǎng)站未來的擴充性（Scalability），而非效能決定網(wǎng)站的發(fā)展。
Q：如何規(guī)畫網(wǎng)站架構(gòu)，才會具有擴充性？
A：將一個網(wǎng)站應(yīng)用，分成幾十個獨立小程式，前端透過 API提供服務(wù)，後端是應(yīng)用程式引擎，這樣做自然會有擴充性。因為應(yīng)用的每一個部分，都有不同等級的使用方式，需要有不同的擴充程度（scaling level），需要不同的機制來處理。以開發(fā)Yahoo Mail而言，是要開發(fā)一個地址服務(wù)程式丶一個讀信服務(wù)丶一個送信服務(wù)，而送信程式完全和讀信程式無關(guān)。以Yahoo的規(guī)模而言，需要讓這些工作完全分離，才有擴充性。
Q：這種規(guī)畫網(wǎng)站的方式，什麼是最重要的關(guān)鍵？
A：關(guān)鍵是你必須建立分離丶模組化的獨立端點，而不是全部放在同一個大籃子里。大多數(shù)現(xiàn)今MVC架構(gòu)（MVC framework）的開發(fā)框架（Framework），使用所謂的前端控制器（Front Control），每一次瀏覽器提出Request請求時，就會呼叫這個前端控制器，再由前端控制器來分辨，使用者想要執(zhí)行哪一支程式。這樣做，一點意義都沒有。
在瀏覽器層次，程式完全能知道使用者想要做什麼事情，例如使用者只是要讀信，程式就不用再把需求送到伺服器，讓伺服器判斷使用者要讀信還是送信。將這類決策工作拉出瀏覽器，由伺服器處理，就會浪費大量伺服器資源，來處理那些對使用者沒有實際功用的工作。擴充性來自架構(gòu)，很多開發(fā)框架，將所有事情綁在一起，限制了架構(gòu)。選錯開發(fā)框架，你就沒有擴充性。
Q：你是說MVC模式不利於網(wǎng)站擴充性？
A：MVC模式比較適合用在網(wǎng)頁控制器（Page Control）的層次。基本上，每一個網(wǎng)頁控制器都是獨立模組，讀信和查地址是不同的網(wǎng)頁控制器，所以，讀信程式就不會干擾到查地址程式。所以，在每一個端點使用MVC模式來打造小型的網(wǎng)頁控制器，是不會有問題。但是，大多數(shù)采用MVC模式的框架，預(yù)設(shè)在網(wǎng)站中采用前端控制器，而非用網(wǎng)頁控制器的方式，這樣的MVC模式，只適合在小型或單一伺服器的網(wǎng)站。
Q：你會如何選擇開發(fā)框架呢？
A：一個框架都不要用。但是，我會從這些開發(fā)框架中，找出我需要的功能，拿出那個我需要的程式模組來用，或者參考其中的設(shè)計想法，而不是套用整個框架。我所看到的大多數(shù)框架，都沒有專注在打造有效能的擴充性和可模組性。
Q：難道開發(fā)者不需要框架或架構(gòu)嗎？
A：網(wǎng)站的確需要有架構(gòu)，每一個人都需要框架，框架是一種解決問題的方法。但是你并不需要通用型框架，用一個前端控制器，來解決所有問題，這樣通常沒辦法成功。每一個問題都不同，你需要引導(dǎo)框架，使用正確的設(shè)計模式，直接解決真正要處理的問題。只生產(chǎn)一款汽車，怎麼可能滿足全世界人的需求！
用框架開發(fā)雛形系統(tǒng)就好，但真正的產(chǎn)品就不要全部套用。從框架開始比較容易，但你要拆開全部的框架，移除Runtime檢查丶拿掉不需要的功能，只留下你會用到的程式模組。你不需要一個通用型框架，因為它無法提供未來的擴充性，但也不用重頭寫起，你需要的是介於兩者之間。
Q：網(wǎng)站需要規(guī)畫到多久以後的擴充需求？
A：我總是痛恨要幫未來考慮太多。當(dāng)你無法預(yù)測未來，你就無法幫未來作決定。
網(wǎng)路變化太快，我通常只規(guī)畫半年內(nèi)的事情。現(xiàn)在決定半年以後的事情，可能會做出錯誤決策，反而讓事情更糟。如果你沒有解決當(dāng)下的問題，而是想像未來會發(fā)生的問題，我認為不值得，我寧可解決眼前看得到的問題，真正聚焦在當(dāng)下需要的產(chǎn)品。
Q：那麼，有任何準則是架構(gòu)人員可以遵循的嗎？
A：最主要的原則是，仔細考慮如何分配程式模組，盡可能將程式拆解成更小的元件，調(diào)校出適當(dāng)?shù)腁PI，你應(yīng)該規(guī)畫的是使用者端點的事情，例如瀏覽器請求的類型是什麼？應(yīng)用程式要如何回應(yīng)？是否可以切割？是否可以把這些工作分配到完全分離的伺服器上執(zhí)行？即使是在同一臺伺服器上，你也能從使用者端點的角度來架構(gòu)應(yīng)用程式，有一天，當(dāng)你的規(guī)模變大後，就可以很容易加入第二臺伺服器，只要在前端伺服器不儲存任何資料，就能進行流量分擔(dān)。一般開發(fā)者最大的錯誤是，讓程式碼之間的交互關(guān)連（interrelation）太深，每個不同的元件都需要和其他外元件溝通，這樣做很難調(diào)校出很乾凈的API。開發(fā)者會無法抽離出效率慢的API放到輔助伺服器中，而讓主要伺服器只執(zhí)行必要API。
Q：切割服務(wù)丶拆解程式的難度是什麼？
A：必須在開始之前，就要非常了解問題。當(dāng)你寫完第一個版本的程式，才著手拆解問題，那幾乎是不可能，很難事後處理。這的確很難，因為問題會一直改變。但是，若你從簡單的架構(gòu)開始，并且保持這個精神來區(qū)隔程式模組。每次當(dāng)網(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：基本精神很簡單，只要用資料防火墻的概念來設(shè)計網(wǎng)站。網(wǎng)路防火墻會嚴密監(jiān)控每一個通訊埠，只讓沒有安全疑慮的封包通過，但網(wǎng)站開發(fā)者剛好相反，只擋掉自以為有危險的內(nèi)容。開發(fā)者不能信賴任何從外部取得的資料，借用防火墻概念和手法，建立資料防火墻，就能提高網(wǎng)站安全性。
Q：好的架構(gòu)師需要什麼樣的條件？
A：必須非常了解技術(shù)，了解每一個細節(jié)，例如設(shè)計資料儲存機制，要了解哪種資料可以儲存丶可以存多大的檔案，放多少資料丶每秒鐘可以放多快？如何復(fù)制資料？前端必須使用哪種資料格式等。架構(gòu)師可以不用像 DBA，知道如何修復(fù)Oracle資料庫的錯誤，但是要能夠了解Oracle資料庫擁有的能耐。這種人很難找，必須要失敗過很多次，才會有足夠的經(jīng)驗。
Q：臺灣還有不少舊網(wǎng)站使用php 4，他們應(yīng)該現(xiàn)在升級到php 5嗎？還是等待php 6？
A：盡快升級到php 5。只要作一些測試和修改，就能得到更好的效能和安全，為什麼不做？不需等待php 6，開源社群的運作方式，無法承諾推出時間。很多新功能已經(jīng)放到php 5.3版中，趕快從4升到5最重要。
php技術(shù)：PHP發(fā)明人談MVC和網(wǎng)站設(shè)計架構(gòu) 貌似他不支持php用mvc，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
