开发者学堂课程【高校精品课-厦门大学 -JavaEE 平台技术：Spring技术栈】学习笔记，与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/80/detail/15959
Spring技术栈
在前面看到 spring 的框架，主要是用于实现在服务器上面的控制器层以及逻辑层的代码，那在 spring 里分了两个技术站来实现这些代码，分别是传统阻塞式的 servlet 的技术站和非阻塞的响应式的技术站，阻塞的 servlet 技术站是基于传统的 servlet 的容器技术，它利用 servlet 来实现基于 web 的服务器端的应用，那当客户端向服务器端发起请求的时候，服务器端则会针对每一个请求去开启一个线程来处理这个请求，在这个现实里面，它会读取网络的数据，去读写数据库，去做计算，最后产生返回给前端的结果，返回回去，整个过程都在一个独立的线程里面完成。
那众所周知，如果说当同时有多个请求来访问服务器的时候，服务器就会开启多个线程，而每个线程都会占据一定的内存。
同样线程多了，CPU 也需要消耗更多的资源来进行线程的切换。众所周知每一台物理的服务器，它的CPU和内存都是有限的，所以它不可能无限的去接收这个请求来开除无线的线程，那一般都会在上面去做一个线程池去限制能够同时处理的请求数，这样的一种技术看起来没有什么多大的问题，但是知道在服务器上运行的每一个请求里面，其实都有包含了一些慢速的操作，如通过网络去读取数据或者去读取数据库，这些跟 io 有关的操作其实是会使得线程处于等待的状态，也就是它不能充分的利用 CPU 的资源，但由于前面定义了一个线程池的概念，这些处于阻塞状态的线程其实会使得新到的请求没有办法得到技术的处理，尽管现在的 CPU 并不是非常的忙碌，所以把这一类的技术命名为阻塞式的技术。
响应式技术则采取了完全不同的想法来处理这个问题，它会把整个的任务分解成为若干个小的任务，也就是分解成为像 io 这样的慢速的任务，或者说像计算类的这种高速的任务。
当一个请求发到响应式的服务器的时候，它不是简单用一个线程来处理这个请求，而是把它的半数的操作，比如说 io 的这种操作置于一个事件队列里来侦听是否有完成了这样的一个慢速的操作，所以慢速的操作并不会独占一个线程从而使得有限的资源被这些慢速的操作给阻塞了，但只有当这些慢速的操作完成了以后，它才会开
启一个线程去执行它的快速高速的这些计算类的操作。
这样的一种方式其实是基于一种事件驱动的这个思想来实现这个服务器上面的这样的一个请求的处理，所以在这样的一种模式下，CPU 不会再因为 IO 的操作而处于
等待的状态，所以它能够在有限的物理资源的情况下能够去处理更多的请求，然后把这一类的技术称作为响应式的技术站。
由于这两种技术看到是完全不同的，所以这意味着在这两个技术站里所有的技术框架都是不同的，但 servlet 中间主要是用Spring MVC来实现服务器端的控制器来处理HTTP的请求以及返回HTTP的回应。
在这个逻辑层主要使用了 gdbc 或者 gpa 去访问数据库，反应式的技术站采用了 web flux 来实现服务器端的控制器层，它基于的服务器也不再是come kaite 的服务器，而是异步的高速服务器。那它访问数据层的这些技术也跟 servlet 的技术站的技术是完全不同的。
在这两种技术站中间，其实它并没有一个明显的优劣的比较，其实在大多数情况下使用的还是 servlet 的技术站，因为这样的一个技术站相对来说比较符合传统的编程习惯，但对于一些 io 操作非常频繁的应用，传统的 servlet 的技术站会使得资源不能得到充分的利用，那就会转而使用这种响应式的技术站，比如说在后面会讲到的微服务的网关，因为它本身的操作并不多，它是属于一个网络i o操作频繁的一个
系统，那就会基于这项技术实现微服务的网关。
