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
#p#
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工程师平时经常接触“外网远程调用”,大家都比较熟悉:以前是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/
http://blog.csdn.net/wdwbw/article/details/5336799
原文链接:http://www.cnblogs.com/sink_cup/archive/2012/09/19/mvc_rpc_thrift.html