MVC是傳統(tǒng)web服務的常用框架，直到出現(xiàn)新的需求：私有API、開放API，還有業(yè)務龐大后進行soa拆分，這就需要新的框架。

關于MVC，有一個經(jīng)典講解：http://www.symfony-project.org/jobeet/1_2/Doctrine/zh_CN/04

對這張圖進行修改和細化：

1、controller只支持http(s)，不支持cli命令行

http參數(shù)的獲取和cli完全不一樣，web服務用不上cli，所以只支持http(s)。

2、一個uri應只支持一種http method

從安全和http規(guī)范兩個方面來說，一個uri應只支持一種http method，不能讓一個請求即支持get又支持put、post，所以在controller中的每個action都要指定一種http method，如果請求不符合method，返回錯誤。

安全：假如修改個人簽名的頁面提交地址為http://example.com/user/status，參數(shù)為content=xxxx，用戶請求時驗證本人cookie即可。這個頁面接口應該只支持post，如果同時支持get，會出現(xiàn)什么問題？user 1發(fā)表了一張圖片<img src="http://example.com/user/status?content=某商城促銷，地址xxxxx" alt="" />，很明顯這張圖片是無法顯示的。當user 1的所有好友user 2、user 3看到這張圖片時，瀏覽器嘗試載入圖片，就會自動把user 2、user 3的簽名改成廣告。這就是典型的sns攻擊的原理。

http規(guī)范：http://book.douban.com/subject/3094230/

3、MVC各層職責與禁止

index.php：職責——作為入口——根據(jù)路由規(guī)則，把uri請求映射到某個controller；作為出口——接收controller層返回的數(shù)據(jù)，然后輸出

controller：職責——取http數(shù)據(jù)$_GET、$_POST、put、delete，然后作為參數(shù)傳遞給model層，把model層返回的數(shù)據(jù)傳遞給view層。一個uri只支持一種http method。禁止——使用$_REQUEST。

model：職責——處理業(yè)務，向下調(diào)用dao（數(shù)據(jù)訪問對象），由于不知道下層用的是什么sql，所以無法寫sql。禁止——寫SQL，取http數(shù)據(jù)（$_GET、$_POST）。

dao：職責——根據(jù)原子業(yè)務，封裝各種存儲（mysql、pgsql、mongodb、hbase、memcache、redis、file）。確保當從mysql遷移到pgsql時，對外接口輸入和輸出不變。禁止——對外暴露用的是什么sql。

view：職責——只對數(shù)據(jù)進行顯示格式處理。禁止——業(yè)務邏輯。

4、輸出

頁面返回html，訂閱是atom。

5、異常

經(jīng)過了PP面向過程的初級階段，進入中等階段class + return false的OOP，再進入高級階段class + exception的徹底OOP，就會發(fā)現(xiàn)OOP的簡潔易于維護。

Exception從底層說起比較清晰。

dao：catch 數(shù)據(jù)庫異常（php是PDOException），throw 自定義錯誤碼DaoException（打詳細log，這種數(shù)據(jù)庫錯誤應由log平臺發(fā)出警報給工程師）。

model：catch DaoException，throw 自定義錯誤碼ModelException。

controller：catch ModelException、catch所有Exception，return http狀態(tài)碼、content-type、數(shù)據(jù)、模板名稱。如果是http狀態(tài)碼是302，還需要return uri。

index.php：index.php作為出口，接收到controller傳來的結果，header輸出http狀態(tài)碼，根據(jù)http status code決定是跳轉還是輸出，根據(jù)content-type決定是輸出html、json還是atom。

todo參考：《錯誤碼與狀態(tài)碼》

細化之后如下圖：

todo細化：view層之多模板templates、view層之多l(xiāng)ayout與模塊化、bigpipe

#p#

MVC框架細化到這個程度，能很好的支持傳統(tǒng)web服務，直到出現(xiàn)了新的挑戰(zhàn)：

1、移動互聯(lián)網(wǎng)的需求，官方app需要api（開放或私有）：iPhone、Android智能手機逐漸普及，在手機上使用互聯(lián)網(wǎng)服務更方便，各公司推出官方手機app，需要api。

2、開放帳號和數(shù)據(jù)的需求，第三方app需要api（開放）：隨著sns的興起，各大sns社區(qū)發(fā)現(xiàn)開放數(shù)據(jù)給開發(fā)者app，能夠形成生態(tài)圈，能夠盈利，OAuth這種授權方案流行了起來。開放的數(shù)據(jù)如果屬于用戶，那需要先開放帳號，用戶登錄授權第三方app獲得頭像、好友列表。如果是地圖這種自有數(shù)據(jù)，則無需帳號。

3、開放帳號的需求：為什么到各個網(wǎng)站都要重新注冊呢？于是出現(xiàn)了OpenID，但是不夠方便，小白不容易理解，而且OpenID只做認證，各公司如果支持OpenID沒有什么額外的價值。后來各社區(qū)開放數(shù)據(jù)時，采用了OAuth，OAuth用于授權也包含了類似OpenID的認證功能。所以現(xiàn)在流行用OAuth登錄，而不是OpenID。比如在別的網(wǎng)站上或者app里“用Google帳號登錄”、“用微博帳號登錄”、“用QQ帳號登錄”并且授權導入頭像。

4、業(yè)務龐大后，按照soa進行拆分，也會面臨跨產(chǎn)品線（服務）如何內(nèi)部調(diào)用的問題。

框架進化如下：

當業(yè)務龐大時，按照soa，進行服務拆分，內(nèi)部各產(chǎn)品線之間如何調(diào)用數(shù)據(jù)？

即使只有1個業(yè)務，比如一個web提供服務，Android、iPhone app也提供服務，那web和外網(wǎng)api如何調(diào)用共同的底層？

用http？

因為web工程師平時經(jīng)常接觸“外網(wǎng)遠程調(diào)用”，大家都比較熟悉：以前是http + xml，現(xiàn)在是https + json、https rest + json。

在“內(nèi)網(wǎng)遠程調(diào)用”使用http + json不可以嗎？

都是RPC，外網(wǎng)要求：安全第一、性能第二，內(nèi)網(wǎng)要求：性能第一、內(nèi)網(wǎng)無需考慮安全。

用http是很簡單，http比https性能高一些，但性能還是太低，因為http是應用層，調(diào)用傳輸層的tcp，而socket是tcp的封裝接口，所以socket比http性能高很多。todo參考《http與socket性能比較》。

Facebook很早就發(fā)現(xiàn)這個問題，開發(fā)了socket協(xié)議的跨語言遠程服務調(diào)用框架，這就是thift，2008年進入Apache開源項目。

而國內(nèi)普遍落后一些，某博用http，因為性能低，就在web層加了memcache以保證性能。

類似的內(nèi)部遠程調(diào)用框架還有：Google Protocol Buffers。

todo：《php thrift》

參考資料：

http://www.symfony-project.org/jobeet/1_2/Doctrine/zh_CN/04

http://www.yiiframework.com/doc/guide/1.1/zh_cn/basics.mvc

http://www.biaodianfu.com/oauth-openid.html

http://zh.wikipedia.org/wiki/OAuth

http://zh.wikipedia.org/wiki/OpenID

http://www.ibm.com/developerworks/cn/java/j-lo-apachethrift/

http://blog.csdn.net/wdwbw/article/details/5336799

原文鏈接：http://www.cnblogs.com/sink_cup/archive/2012/09/19/mvc_rpc_thrift.html