做项目时我们一直在说框架、架构,那它到底是什么呢? 什么是架构从 dubbo 官网我们可以看到架构设计的发展演变史。 这里把架构分成四类:
刚开始时 PHP + MySQL 就可以形成网站了。 这种模式支持中小型网站是没有问题的,但是一旦形成大型网站就支撑不住了。 所以现在各大主流公司还是会选择 Java。 我们项目中的类会打包成一个 JAR 包运行在服务器里,最初所有模块是在一个 JAR 包的,也就是单一应用,随着用户量的提升、访问量的增大,JAR 包越来越大,单一应用运行起来越来越慢,所以单一架构就不再适合了。 此时引入分布式架构,把一个模块拆分成几个单独的模块以提升效率,一个 JAR 包分成几个 JAR 包运行在不同的服务器上,引入了 MVC 的设计模式。 随着业务量的剧增,几台服务器也已经不够用了,效率比较低,此时每个模块用 N 台服务器进行部署。 当请求进来之后,会按照一些策略,把它随机分配到负载均衡的服务器。此时每个服务器的 request 就比较少了,提高了效率。这个就是分布式服务架构。 每台服务器之间需要通信的,用的就是 RPC 框架。 当分布式架构也不够用了,最后演变成流式架构,此时 SOA 是关键。 Java 开发的主流框架演变之路现在 Spring 基本占据主导地位了,那么在 Spring 广泛应用之前,有哪些主流框架呢:
JSP 负责前端页面的控制,Servelt 负责服务器端的应用程序,JavaBean 是我们的对象,这样我们有了对象、有前端页面、有后台接受请求处理的服务器,就能够搭建一个从前端到后端的整体框架了。 但这个搭配有点麻烦,因为 JSP 既可以写标签,也可以内嵌 Java 代码,<% (Java code) %>,所有东西耦合在一起变得非常麻烦; 而现在纯的 HTML,支持 JS, 支持 HTML 标签,支持 CSS 样式,不支持插入 Java 代码,这就是 JSP 和 HTML 的最大的区别。 现在企业中开发时比如 Spring Boot 的开发,更多的还是用 HTML,或者用一些前端框架比如 freemarker 进行代替,JSP 已经被慢慢淘汰掉了。 但问题时,当前端页面和后段服务器交互时,发送 N 多个 request,写 Servlet 时要写 N 多个对应的处理:
而用 MVC 之后,非常简单,我们来看一下。
这张图很好的展示了每个模块的功能和相互的联系: 用户在浏览器中发送请求之后, browser 把这个请求发给了 controller, 需要它做一些处理, 然后发送到数据库中去查询, 得到结果之后, 把结果发给 View 层进行渲染, 用 html 的标签好看的表示出来, 渲染之后的结果再返回给 controller, 再返回到浏览器里显示出来。 比如在我们在点外卖时,你发送请求给服务员,服务员就是 controller 层,他需要处理订单比如查一下仓库里还有没有这些原材料,排好先后顺序再交给厨师等等,厨师做好之后他还需要再包装一下再送到你手上。 后面所有框架都是依托于 MVC 这种方式来设计的。
这个框架虽然也上了年纪了,但是一些老的项目还在用它。 特别是金融 IT 这一块,数据库 dao 层还是使用的是 Hibernate;而科技公司因为要用到高并发,dao 层用的是 MyBatis,数据交互效率较快。 回到 SSH 框架上来,用过的都知道,它配起来真的麻烦,太多的配置文件了。
SSM 还是现在项目中比较常见的,但其实现在在新项目中用的也比较少了,更多的是用 Spring Boot,因为配置非常简单。 为什么用框架?任何一项技术的产生都是为了解决现有的问题的,框架也不例外。 就拿 Spring 这个框架来说,它提供了项目开发中的一些基础功能,可以使我们程序员更专注于业务逻辑的处理,具体来说我认为有3点最重要:
|
|