下载掌阅APP，畅读海量书库
立即打开
简单来说，Web是运行在互联网上的一个超大规模的分布式系统，通过对数据的一些可视化进行展现的一种工具。
网页开发的设计初衷是一个静态信息资源的发布媒介。通过超文本标记语言（HTML）描述信息资源；通过统一资源标识符（URI）定位信息资源；通过超文本传输协议（HTTP）请求信息资源。
HTML、URI（URL地址是URI的一个特例）和HTTP这3个规范构成了Web的核心体系结构，也是一个网页不可或缺的3种协议体系。用简单一点的话来说，用户通过客户端（浏览器）的URL找到网站（如 www.baidu.com ），同样此地址可以为IP的形式，通过浏览器发出HTTP请求，运行Web服务的服务器收到请求后返回此客户机URL中请求的HTML页面。
对于网络协议，Web是基于TCP/IP协议的。TCP/IP协议把计算机连接在一起，而Web在这个协议族之上进一步将计算机的信息资源连接在一起，形成现在社会中的万维网。每一个运行着的Web服务都相当于在万维网中提供的相关功能和资源。
我们开发的Web应用就是提供信息或者功能的Web资源，成为Web这个全球超大规模分布式系统中的一部分。
1991年8月6日，Tim Berners Lee在alt.hypertext新闻组贴出了一份关于World Wide Web的简单摘要，标志着Web页面在Internet上的首次登场。最早的Web主要被一批科学家们用来共享和传递信息。全世界的Web服务器也就几十台。第一个Web浏览器是Berners Lee在NeXT机器上实现的，其只能“跑”在NeXT机器上。苹果和乔布斯的粉丝对NeXT的历史肯定耳熟能详。真正使得Web开始流行起来的是Mosaic浏览器，这便是曾经大名鼎鼎的Netscape Navigator的前身。
Berners Lee在1993年建立了万维网联盟（World Wide Web Consortium，W3C），负责Web相关标准的制定。浏览器的普及和W3C的推动，使得Web上可以访问的资源逐渐丰富起来。这个时候Web的主要功能就是浏览器向服务器请求静态HTML信息。1995年，马云在美国看到了互联网，更准确地说他其实看到的是Web。阿里早先做的黄页就是把企业信息通过HTML进行展示的Web应用。
传统网页开发可称之为Web 1.0时代，非常适合创业型小项目，出产速度快。对于网页而言，不分前后端，1～5人可完成所有开发工作。页面上由JSP、PHP等语言直接生成相关的数据和页面，在服务端生成后，直接通过浏览器展现，基本上是服务端给什么，浏览器就展现什么。这种页面简单而且交互能力弱，对数据的处理和呈现方式也比较单一。而网页的显示控制一般是在Web的服务层（Server）而不是交由独立的View层控制和管理。
这种模式的优点是：开发简单明快，只需要在服务器或者主机中启动一个Tomcat或Apache等类似的服务器就能开发相关的网页，甚至是生产环境。因为其逻辑和代码简单，所以对于开发和调试同样简单、便捷，对于业务不复杂的情况可以进行快速迭代和功能新增等，非常适合小型公司和个人创业等应用环境。
但是业务总会越变越复杂，这点是不可避免的，需求总是没有止境的。业务复杂度的变化会让控制页面的服务层（Service）越来越多，这造成了整个系统的复杂化和多元化。同样，开发团队的扩张也导致参与人员很可能从几个人快速扩展到几十人，在这种情况下会遇到一些典型问题，如图1-1所示。
图1-1 传统网页越来越复杂
·提供的服务越来越多，调用关系变得复杂，前端搭建本地环境不再是一件简单的事。不同的个人提供的页面和其他人提供的页面可能会有细节上的差异，即使考虑团队协作，往往最后呈现的页面和想象中的也会有一些差距。
·前端的样式更新操作变得复杂且造成系统的不稳定。因为所有的页面都是基于后端自动生成的，所以对于一些前端样式的更新和更改可能需要将整个代码逻辑重构，甚至重新上线一个崭新的系统。这样使得系统能提供的服务变得不稳定且难度增加，而单个页面的生成出错可能会导致所有的页面不可用。
·JSP等代码的可维护性变差。随着一个项目的体量增大，其代码的维护一定会越来越难。单一代码负责前台和后端的数据处理，导致职责不清晰，而且由于开发人员的水平和书写习惯不同，以及各种紧急需求，揉杂大量业务代码和其他历史代码，甚至意义不明的无用代码和注释，积攒到一定阶段时，往往会带来大量的维护成本。
为了降低复杂度，以后端为出发点，就有了Web Server层的架构升级，对业务、显示页面、数据的处理进行了逻辑分层，并且为了减少相关的重复，出现了一些后端框架，如Structs、Spring MVC等，这就是后端出现的MVC时代。
注意：
MVC全名Model View Controller，是模型（Model）、视图（View）和控制器（Controller）的缩写。它是一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
这样的处理使得代码可维护性得到明显好转。MVC是个非常好的协作模式，从架构层面让开发者懂得什么代码应该写在什么地方。为了让View层更简单、便捷，适合后端开发者的书写，还可以选择Smarty、Velocity和Freemaker等模板，限制在模板里使用Java代码，更符合工程化的思维。这样看起来虽然功能是变弱了，但正是这种限制使得前后端分工变得更清晰。这个阶段的典型问题是：
（1）前端开发重度依赖开发环境。在这种架构下，前后端协作有两种模式：
·一种是前端写好静态页面（emo），等待页面完成后，让后端去套用该静态页面（模板），这样的写法也是现在传统的网页开发常用的方式。淘宝、京东等几乎所有的Web服务提供商在早期及现在依旧有大量业务线是这种模式。其优点是Web服务的测试版可以本地开发，并且可以在局域网中形成类似于自己的完整“开发环境”和“测试环境”，很高效。当然缺点依旧存在：还需要后端套模板，其实相当于并没有将所有的前后端逻辑分离。后端进行模板的套用后还需要前端确定，来回沟通、调整的成本比较大，而且并不适合仅通过文档就可以完成全部的开发工作。
·另一种协作模式是前端负责浏览器端的所有开发和服务器端的View层模板开发。其优点是UI相关代码都是用前端去写，后端不用太关注。但其缺点依旧是前端开发重度绑定后端环境，致使环境成为影响前端开发效率的重要因素。
（2）简单而言，还是由于前后端职责依旧纠缠不清而导致的问题。对于之前的小型应用而言，追求极度的工程化思想是没必要且增加成本的，但是对于现阶段的大型应用或追求用户体验的应用而言，前后端的分离是必要的。
说明：
AJAX正式提出后，加上CDN开始大量用于静态资源存储，于是出现了JavaScript的火热及之后的SPA（Single Page Application，单页面应用）时代。
伴随着JavaScript技术的发展和浏览器、网速带宽等版本的更新，为了追求更佳的用户体验和开发方式（类似Spring MVC），则开始出现了浏览器端的分层架构。
·首先是对于前后端接口的约定。如果后端的接口不够规范，且后端的业务模型不够稳定，那么前端开发会很痛苦。因此应通过规定的接口规则等方式来编写相关的代码，并严格遵守。经过实践和积累后的接口规则成熟后，还可以用来模拟数据，使得前后端可以在约定接口后实现高效、并行开发。
·其次是对前端开发复杂度的控制。SPA应用大多数以功能交互型为主，大量的JavaScript代码进行前台的显示和用户操作的反馈，以及一部分对于数据的处理和简单的运算等。但是对于大量JavaScript代码的组织及与View层的绑定等，都不是容易的事情。
为了降低前端开发的复杂度，相继涌现出了大量框架，如EmberJS、KnockoutJS和AngularJS等，这些框架总的原则是先按类型分层，比如Templates、Controllers和Models，然后再在层内做切分，这种方式简称SPA，如图1-2所示。
图1-2 SPA方式示意图
SPA的好处很明显，例如：
·前后端职责很清晰。前端工作在浏览器端，后端工作在服务端。清晰的分工可以让开发并行，测试数据的模拟不难，前端可以本地开发；后端则可以专注于业务逻辑的处理，以及输出RESTful等接口。
·前端开发的复杂度可控。前端代码很重，但合理的分层能让前端代码各司其职。如简单的模板特性的选择就有很多讲究，如限制什么，留下哪些，代码应该如何组织等。
·部署相对独立，只要通过前后端接口的形式，无论是调试，或者是开发新功能都非常方便。
但依旧有如下一些不可避免的缺点。
·大量代码不能复用。比如后端依旧需要对数据做各种校验，校验逻辑无法复用浏览器端的代码；如果可以复用，那么后端的数据校验可以相对简单化。
·全异步，对SEO不利，无法获得相关的内容，往往还需要服务端做同步渲染的降级方案。
·性能并非最佳。大量的JavaScript方式会影响用户体验，特别是在移动互联网环境下。
·SPA不能满足所有需求，依旧存在大量多页面应用。URL Design需要后端配合，前端无法完全掌控。