/ 中存储网

API优先架构或者胖瘦服务器之争

2013-10-15 00:00:00 来源:中存储
自2007年Apple发布了iPhone,网络应用及网站在小屏幕上的呈现机会显著的增高,从而各大网站及机构不得不对其应用进行适当的改变。然而考虑到数据体积、应用程序扩展性、新特性的发布及维护等问题,应用程序的架构也不得不按需进行改变,比如Twitter的面向服务。近日leaseweblabs上发表了一篇文章,详述了API优先架构。
  以下为译文:
  在API优先架构中,API用户会被视为应用程序的主要用户。这意味着API不会再作为MVC中View的替代,它将拥有最高的优先权。其中最主要的区别就是:在“API优先”中,架构会始终执行一个完整、响应式及文档化的API。而当目标指向移动(应用联连接到API)、代理商(表示层会使用API)及高整合、解耦的多产品环境中,这一点尤为重要。
  MVC
  MVC架构已经流行了很长一段时间,在2004年RoR发布后,MVC变得愈加炙手可热。在MVC情况下用户和员工分别使用前端和后端两个不同部分,可以大幅提高应用程序中组件的重用率。合适的使用MVC策略,可以让应用程序的很多部分都得以重用,其中包括DBAL/ORM、Business Logic、Presentation及AAA。AAA(Authentication、Authorization、Accounting)允许员工模拟用户行为,使用相同的登录界面及共享日志设备。
  移动中的视图层
  在2007年,Apple发布了iPhone,从那起网络应用程序(及网站)在小屏幕上的展示率迅速升高。同时MVC对小屏的兼容一直非常优秀,需要做的只是在手机或平板上开一个视图层的分支并做相关调整。这种建立独立视图层的策略被称为“mobile first”,也是最具成本效益及激进的修改途径。另一个替代方案是建立两个视图层:1个为移动设备,另一个为桌面设备。移动端的通常以“m.”的子域名开头(比如m.csdn.net),非常简单及直观的一个途径。
  在MVC中加入API
  “HTML5 vs Native”应用开发之争可谓是如火如荼,引用Danny Brown的话就是:
  当公司在建立移动应用时会面临一个重要的抉择,Native或者是HTML5。每个方案都有自己的优势,然而错误的选择必将付出高昂的代价。
  选择Native则需要建立一个完整、响应式及文档化的API,然而选择HTML5只需要重设计视图层。每种方案都有自己的优越性,只有相应的场景下才有胜负之分。所谓存在即有道理,没有哪种方案是永远的失败者:在MVC上建立API作为视图。下面就看一下,为什么许多人都选择了另一种。
  首先,MVC途径需要200ms的页面加载时间。在这个途径下,服务器做3样事:数据库抽象、业务逻辑及呈现,这也是其为什么被称为fat server的原因。API并不会承担呈现工作,只执行每个请求较小的业务逻辑,也因此被命名为thin server。一个好的API会经过高度的优化,加载时间通常低于20ms。这就意味着,在执行多重调用时(高达10),一个完整页面的渲染时间不会超过300ms。
  当下,如果你在使用MVC并且缺乏1个API,最容易做的事情就是添加一些View,用以输出JSON,并称之为“restful API”,唯一需要做的就是写一些文档并取悦于老板。实际上,在整个周期中,这个API完全不可用,因为其并不具备扩展性,同时还慢的可怕。
  Twitter及API优先架构
  在2010年,Twitter公布了他们的“API first”策略。鉴于其应用程序使用的是JavaScript,因此称之为JavaScript架构,类似于移动应用的架构。这允许他们完全重利用已有的API,这些开始时临时使用的API,在以后开发周期中却成为应用的基础。通过使用一个restful JSON API,他们的API专注于JavaScript应用程序的最佳整合。但Twitter同样使用了传统页面支撑其应用,他们曾发布:
  为了不通过JavaScript支持crawler及用户,我们需要同时运行在服务器及客户端上的1个渲染系统。
  使用传统网页交付方式,同时使用API优先策略,这里简单称之为“Hybrid”。下图列举了不同的途径:
  结论
  优化重用可以降低成本,但是只有在强壮的架构策略下才能得以实现。虽然重整代码以增加架构上的依从(compliance)并不能直接给业务带来价值,却可以降低应用未来修改时的成本,然而这种程度的说服力显然难以服众。