为什么放弃jsp

在刚进入开发工作的时候,我使用的框架就是SSH,前端用JSP+jquery的方式去渲染去交互.今天我们先说jsp,而jquery放到以后再说.
前端的发展历程先不说太多了,直接进入干货.
jsp的痛点

1. 动态资源和静态资源全部耦合在一起，服务器压力大，因为服务器会收到各种http请求，例如css的http请求，js的，图片的等等。一旦服务器出现状况，前后台一起玩完，用户体验极差。
2. UI出好设计图后，前端工程师只负责将设计图切成html，需要由java工程师来将html套成jsp页面，出错率较高（因为页面中经常会出现大量的js代码），修改问题时需要双方协同开发，效率低下。
3. jsp必须要在支持java的web服务器里运行（例如tomcat，jetty，resin等），无法使用nginx等（nginx据说单实例http并发高达5w，这个优势要用上），性能提不上来。
4. 第一次请求jsp，必须要在web服务器中编译成servlet，第一次运行会较慢。
5. 每次请求jsp都是访问servlet再用输出流输出的html页面，效率没有直接使用html高（是每次哟，亲~）。
6. jsp内有较多标签和表达式，前端工程师在修改页面时会捉襟见肘，遇到很多痛点。
7. 如果jsp中的内容很多，页面响应会很慢，因为是同步加载。
8. 需要前端工程师使用java的ide（例如eclipse），以及需要配置各种后端的开发环境，你们有考虑过前端工程师的感受吗。

基于上述的一些痛点，我们应该把整个项目的开发权重往前移，实现前后端真正的解耦！

开发模式
以前老的方式是：

1. 产品经历/领导/客户提出需求
2. UI做出设计图
3. 前端工程师做html页面
4. 后端工程师将html页面套成jsp页面（前后端强依赖，后端必须要等前端的html做好才能套jsp。如果html发生变更，就更痛了，开发效率低）
5. 集成出现问题
6. 前端返工
7. 后端返工
8. 二次集成
9. 集成成功
10. 交付

新的方式是：
11. 产品经历/领导/客户提出需求
12. UI做出设计图
13. 前后端约定接口&数据&参数
14. 前后端并行开发（无强依赖，可前后端并行开发，如果需求变更，只要接口&参数不变，就不用两边都修改代码，开发效率高）
15. 前后端集成
16. 前端页面调整
17. 集成成功
18. 交付

---

请求方式
以前老的方式是：
1.客户端请求
2.服务端的servlet或controller接收请求（后端控制路由与渲染页面，整个项目开发的权重大部分在后端）
3.调用service,dao代码完成业务逻辑
4.返回jsp
5.jsp展现一些动态的代码

新的方式是：

1. 浏览器发送请求
2. 直接到达html页面（前端控制路由与渲染页面，整个项目开发的权重前移）
3. html页面负责调用服务端接口产生数据（通过ajax等等，后台返回json格式数据，json数据格式因为简洁高效而取代xml）
4. 填充html，展现动态效果，在页面上进行解析并操作DOM。
   （有兴趣的童鞋可以访问一下阿里巴巴等大型网站，然后按一下F12，监控一下你刷新一次页面，他的http是怎么玩的，大多数都是单独请求后台数据，使用json传输数据，而不是一个大而全的http请求把整个页面包括动+静全部返回过来）

总结一下新的方式的请求步骤：
大量并发浏览器请求—>web服务器集群(nginx)—>应用服务器集群(tomcat)—>文件/数据库/缓存/消息队列服务器集群
同时又可以玩分模块，还可以按业务拆成一个个的小集群，为后面的架构升级做准备。

---