互联网创业的准备——框架：从MVC到开放API

sink_cup

<div id="cnblogs_post_body">《互联网创业的准备》系列文章——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/
http://blog.csdn.net/wdwbw/article/details/5336799