|
|
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)?a href=/pingce/yingyong/ target=_blank class=infotextkey>應(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)的事情。現(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最重要。
php技術(shù)：PHP發(fā)明人談MVC和網(wǎng)站設(shè)計(jì)架構(gòu) 貌似他不支持php用mvc，轉(zhuǎn)載需保留來(lái)源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
