《互聯網創業的准備》系列文章——http://cnblogs.com/sink_cup/
《互聯網創業的准備——后勤：電腦、郵箱、會議》http://www.cnblogs.com/sink_cup/archive/2012/09/14/pc_mac_linux.html
《互聯網創業的准備——架構》http://www.cnblogs.com/sink_cup/archive/2012/09/14/web_arch.html
《互聯網創業的准備——帶寬與CDN》http://www.cnblogs.com/sink_cup/archive/2012/09/14/web_bandwidth.html
MVC是傳統web服務的常用框架，直到出現新的需求：私有API、開放API，還有業務龐大后進行soa拆分，這就需要新的框架了。
關於MVC，有一個經典講解：http://www.symfony-project.org/jobeet/1_2/Doctrine/zh_CN/04
對這張圖進行修改和細化：
1、controller只支持http(s)，不支持cli命令行
http參數的獲取和cli完全不一樣，web服務用不上cli，所以只支持http(s)。
2、一個uri應只支持一種http method
從安全和http規范兩個方面來說，一個uri應只支持一種http method，不能讓一個請求即支持get又支持put、post，所以在controller中的每個action都要指定一種http method，如果請求不符合method，返回錯誤。
安全：假如修改個人簽名的頁面提交地址為http://example.com/user/status，參數為content=xxxx，用戶請求時驗證本人cookie即可。這個頁面接口應該只支持post，如果同時支持get，會出現什么問題？user 1發表了一張圖片<img src="http://example.com/user/status?content=某商城促銷，地址xxxxx" alt="" />，很明顯這張圖片是無法顯示的。當user 1的所有好友user 2、user 3看到這張圖片時，瀏覽器嘗試載入圖片，就會自動把user 2、user 3的簽名改成廣告。這就是典型的sns攻擊的原理。
http規范：http://book.douban.com/subject/3094230/
3、MVC各層職責與禁止
index.php：職責——作為入口——根據路由規則，把uri請求映射到某個controller；作為出口——接收controller層返回的數據，然后輸出
controller：職責——取http數據$_GET、$_POST、put、delete，然后作為參數傳遞給model層，把model層返回的數據傳遞給view層。一個uri只支持一種http method。禁止——使用$_REQUEST。
model：職責——處理業務，向下調用dao（數據訪問對象），由於不知道下層用的是什么sql，所以無法寫sql。禁止——寫SQL，取http數據（$_GET、$_POST）。
dao：職責——根據原子業務，封裝各種存儲（mysql、pgsql、mongodb、hbase、memcache、redis、file）。確保當從mysql遷移到pgsql時，對外接口輸入和輸出不變。禁止——對外暴露用的是什么sql。
view：職責——只對數據進行顯示格式處理。禁止——業務邏輯。
4、輸出
頁面返回html，訂閱是atom。
5、異常
經過了PP面向過程的初級階段，進入中等階段class + return false的OOP，再進入高級階段class + exception的徹底OOP，就會發現OOP的簡潔易於維護。
Exception從底層說起比較清晰。
dao：catch 數據庫異常（php是PDOException），throw 自定義錯誤碼DaoException（打詳細log，這種數據庫錯誤應由log平台發出警報給工程師）。
model：catch DaoException，throw 自定義錯誤碼ModelException。
controller：catch ModelException、catch所有Exception，return http狀態碼、content-type、數據、模板名稱。如果是http狀態碼是302，還需要return uri。
index.php：index.php作為出口，接收到controller傳來的結果，header輸出http狀態碼，根據http status code決定是跳轉還是輸出，根據content-type決定是輸出html、json還是atom。
todo參考：《錯誤碼與狀態碼》
細化之后如下圖：
todo細化：view層之多模板templates、view層之多layout與模塊化、bigpipe
MVC框架細化到這個程度，能很好的支持傳統web服務，直到出現了新的挑戰：
1、移動互聯網的需求，官方app需要api（開放或私有）：iPhone、Android智能手機逐漸普及，在手機上使用互聯網服務更方便，各公司推出官方手機app，需要api。
2、開放帳號和數據的需求，第三方app需要api（開放）：隨着sns的興起，各大sns社區發現開放數據給開發者app，能夠形成生態圈，能夠盈利，OAuth這種授權方案流行了起來。開放的數據如果屬於用戶，那需要先開放帳號，用戶登錄授權第三方app獲得頭像、好友列表。如果是地圖這種自有數據，則無需開放帳號。
3、開放帳號的需求：為什么到各個網站都要重新注冊呢？於是出現了OpenID，但是使用不夠方便，小白不容易理解，而且OpenID只做認證，各公司如果支持OpenID沒有什么額外的價值。后來各社區開放數據時，采用了OAuth，OAuth用於授權也包含了類似OpenID的認證功能。所以現在流行用OAuth登錄，而不是OpenID。比如在別的網站上或者app里“用Google帳號登錄”、“用微博帳號登錄”、“用QQ帳號登錄”並且授權導入頭像。
4、業務龐大后，按照soa進行拆分，也會面臨跨產品線（服務）如何內部調用的問題。參考淘寶的數據拆分演進。
框架進化如下：
soa服務拆分，內部各產品線之間如何調用數據？
即使只有1個業務，比如一個web提供服務，Android、iPhone app也提供服務，那web和外網api如何調用共同的底層？
用http？
因為web工程師經常接觸“外網遠程調用”，大家都比較熟悉：以前是SOAP（http + xml），現在是https + json、https rest + json。
在“內網遠程調用”使用http + json不可以嗎？
雖然內網外網都是RPC，但外網要求：安全第一、性能第二；而內網要求：性能第一、內網無需考慮安全。
用http是很簡單，大家都熟悉無學習成本，http比https性能高一些，但性能還是太低，因為http是應用層，調用傳輸層的tcp，而socket是tcp的封裝接口，所以socket比http性能高很多。todo參考《http與socket性能比較》。
Facebook很早就發現這個問題，開發了socket協議的跨語言遠程服務調用框架，這就是thift，2008年進入Apache開源項目。
而國內普遍落后一些，某博用http，因為性能低，就在web層加了memcache以保證性能。
類似的內部遠程調用框架還有：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/