为什么我们要放弃jsp？ jsp( 二 ) _知识分享

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

文章插图
1. 客户端请求2. 服务端的servlet或controller接收请求（路由规则由后端制定，整个项目开发的权重大部分在后端）3. 调用service,dao代码完成业务逻辑4. 返回JSP5. jsp展现一些动态的代码
新的方式：
1. 浏览器发送请求2. 直接到达html页面（路由规则由前端制定，整个项目开发的权重前移）3. html页面负责调用服务端接口产生数据（通过ajax等等）4. 填充html，展现动态效果。
有兴趣的童鞋可以访问一下阿里巴巴等大型网站，然后按一下F12，监控一下你刷新一次页面，他的http是怎么玩的，大多数都是单独请求后台数据，使用 json传输数据，而不是一个大而全的http请求把整个页面包括动+静全部返回过来
这样做的好处是：
1. 可以实现真正的前后端解耦，前端服务器使用nginx 。
前端服务器放的是css，js，图片等等一系列静态资源。甚至你还可以css，js，图片等资源放到特定的文件服务器，例如阿里云的oss，并使用cdn加速，前端服务器负责控制页面引用，跳转，调用后端的接口，后端服务器使用tomcat 。
这里需要使用一些前端工程化的框架比如nodejs，react，router，react，redux，webpack
2. 发现bug，可以快速定位是谁的问题，不会出现互相踢皮球的现象。
页面逻辑，跳转错误，浏览器兼容性问题，脚本错误，页面样式等问题，全部由前端工程师来负责。
接口数据出错，数据没有提交成功，应答超时等问题，全部由后端工程师来解决。
双方互不干扰，前端与后端是相亲相爱的一家人。
3. 在大并发情况下，我可以同时水平扩展前后端服务器，比如淘宝的一个首页就需要2000台前端服务器做集群来抗住日均多少亿+的日均pv 。
去参加阿里的技术峰会，听他们说他们的web容器都是自己写的，就算他单实例抗10万http并发，2000台是2亿http并发，并且他们还可以根据预知洪峰来无限拓展，很恐怖，就一个首页。
4. 减少后端服务器的并发压力，除了接口以外的其他所有http请求全部转移到前端nginx上。
5. 即使后端服务暂时超时或者宕机了，前端页面也会正常访问，只不过数据刷不出来而已。
6. 也许你也需要有微信相关的轻应用，那样你的接口完全可以共用，如果也有app相关的服务，那么只要通过一些代码重构，也可以大量复用接口，提升效率。
7. 页面显示的东西再多也不怕，因为是异步加载。

文章插图
注意：
1. 在开需求会议的时候，前后端工程师必须全部参加，并且需要制定好接口文档，后端工程师要写好测试用例，不要让前端工程师充当你的组专职测试，推荐使用
chrome的插件postman，service层的测试用例拿junit写。
2. 上述的接口并不是java里的interface，说白了调用接口就是调用你controler里的方法。
3. 加重了前端团队的工作量，减轻了后端团队的工作量，提高了性能和可扩展性。
4. 我们需要一些前端的框架来解决类似于页面嵌套，分页，页面跳转控制等功能。（上面提到的那些前端框架）。
5. 如果你的项目很小，或者是一个单纯的内网项目，那你大可放心，不用任何架构而言，但是如果你的项目是外网项目，呵呵哒。
6. 以前还有人在使用类似于velocity/freemarker等模板框架来生成静态页面，现在这种做法也被淘汰掉了。
7. 这篇文章主要的目的是说JSP在大型外网Java web项目中被淘汰掉，可没说JSP可以完全不学，对于一些学生朋友来说，servlet等相关的Java web基础还是要掌握牢的，不然你以为Spring MVC这种框架是基于什么来写的？
【为什么我们要放弃jsp？ jsp】