MVC是传统web服务的常用框架,直到出现新的需求:私有API、开放API,还有业务庞大后进行soa拆分,这就需要新的框架了。 关于MVC,有一个经典讲解:http://www./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:///user/status,参数为content=xxxx,用户请求时验证本人cookie即可。这个页面接口应该只支持post,如果同时支持get,会出现什么问题?user 1发表了一张图片<img src="http:///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./jobeet/1_2/Doctrine/zh_CN/04 http://www./doc/guide/1.1/zh_cn/basics.mvc 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 |
|