Web应用框架
百度百科是这么解释的：
Web应用框架（Web application framework）是一种开发框架，用来支持动态网站、网络应用程序及网络服务的开发。其类型有基于请求的和基于组件的两种框架。
web框架可以分为基于请求的（request-based）和基于组件的（component-based）两大阵营。前者的代表有Struts和Spring MVC等，后者的成员则有JSF、Tapestry等等。
- 基于请求的框架较早出现，它用以描述一个web应用程序结构的概念和传统的静态Internet站点一样，是将其机制扩展到动态内容的延伸。对一个提供HTML和图片等静态内容的网站，网络另一端的浏览器发出以URI形式指定的资源的请求，Web服务器解读请求，检查该资源是否存在于本地，如果是则返回该静态内容，否则通知浏览器没有找到。Web应用升级到动态内容领域后，这个模型只需要做一点修改。那就是web服务器收到一个URL请求（相较于静态情况下的资源，动态情况下更接近于对一种服务的请求和调用）后，判断该请求的类型，如果是静态资源，则照上面所述处理；如果是动态内容，则通过某种机制（CGI、调用常驻内存的模块、递送给另一个进程如Java容器）运行该动态内容对应的程序，最后由程序给出响应，返回浏览器。在这样一个直接与web底层机制交流的模型中，服务器端程序要收集客户端籍get或post方式提交的数据，转换，校验，然后以这些数据作为输入运行业务逻辑后生成动态的内容（包括HTML、JavaScript、CSS、图片等）。
- 基于组件的框架采取了另一种思路，它把长久以来软件开发应用的组件思想引入到web开发。服务器返回的原本文档形式的网页被视为由一个个可独立工作、重复使用的组件构成。每个组件都能接受用户的输入，负责自己的显示。上面提到的服务器端程序所做的数据收集、转换、校验的工作都被下放给各个组件。现代web框架基本上都采用了模型、视图、控制器相分离的MVC架构，基于请求和基于组件两种类型大都会有一个控制器将用户的请求分派给负责业务逻辑的模型，运算的结果再以某个视图表现出来，所以两大分类框架的区别主要在视图部分，基于请求的框架仍然把视图也就是网页看作是一个文档整体，程序员要用HTML、Javascript和CSS这些底层的代码来写“文档”，而基于组件的框架则把视图看作由积木一样的构件拼成，积木的显示不用程序员操心（当然它们也是由另一些程序员开发出来的），只要设置好它绑定的数据和调整它的属性，把他们大大从编写HTML、Javascript和CSS这些界面的工作中解放出来。
上面是百度百科的回答，下面我又找到了知乎一篇文章的描述：
- 基于“组件”（Component ，GUI设计也常称控件）、事件驱动的架构，最常见的是微软的.NET。基本思想是把程序分成很多组件，每个组件都可以触发事件，调用特定的事件处理器来处理（比如在一个HTML按钮上设置onClick事件链接到一个PHP函数）。这种设计远离HTTP，HTTP请求完全抽象，映射到一个事件。事实上这种设计原本最常应用于传统桌面GUI程序的开发，例如Delphi，Java Swing等。所有表现层的组件比如窗口，或者HTML表单都可以由IDE来提供，我们只需要在IDE里点击或拖动鼠标就能够自动添加一个组件，并且添加一个相应的事件处理器。
- 基于“WEB页面/文件”，例如CGI和PHP/ASP程序。程序的文件分别存储在不同的目录里，与URL相对应。当HTTP请求提交至服务器时，URL直接指向某个文件，然后由该文件来处理请求，并返回响应结果。比如http://www.website.conm/news/readnews.php?id=1234可以想像，我们在站点根目录的news目录下放置一个readnews.php文件。这种开发方式最自然，最易理解，也是PHP最常用的方式。要注意产生的URL对搜索引擎不友好，不过你可以用服务器提供的URL重写方案来处理，例如Apache的mod_rewrite。
- 基于“动作”(Action)。这是MVC架构的WEB程序所采用的最常见的方式。目前主流的WEB框架像Struts、Webwork(Java)，Ruby on Rails(Ruby),Zend Framework(PHP)等都采用这种设计。URL映射到控制器(controller)和控制器中的动作(action)，由action来处理请求并输出响应结果。这种设计和上面的基于文件的方式一样，都是请求/响应驱动的方案，离不开HTTP。比如 http://www.website.com/news/read/id/1234 可以想像在实际代码中，我们会有一个控制器newsController，其中有一个readAction。不同框架可能默认实现方式稍有不同，有的是一个Controller一个文件，其中有多个Action，有的是每个Action一个文件。这种方式的URL通常都很漂亮，对搜索引擎友好，因为很多框架都自带有URL重写功能。可以自由规定URL中controller、action及参数出现的位置。
另外，还有更直接的基于URL的设计方案，那就是REST。通过人为规定URL的构成形式（比如Action限制成只有几种）来促进网站之间的互相访问，降低开发的复杂性，提高系统的可伸缩性。REST对于Web Services来说是一个创新。虽然本文讨论的是单个项目所采用的架构，而REST是为了解决网站之间的通讯问题，但REST的出现，会对单个项目的架构造成影响（很显然你在开发时就要构造规范的URL）。将来混用REST和MVC应该也是一种趋势。RoR提供很好的REST支持，Zend Framework也提供了Zend_Rest来支持REST，包括Server和Client。
除了上面之外，我还总结有以下内容：
4. 微服务架构 (Microservices Architecture) 微服务架构是一种设计方法，其中应用程序被构建为一组小的服务，每个服务执行单一功能，运行在其自己的进程中，并通过轻量级通信机制（通常是HTTP资源API）进行通信。每个服务都围绕业务能力构建，并独立于其他服务进行部署。（Docker、Kubernetes、API Gateway）
5. 无服务器架构 (Serverless Architecture) 无服务器架构允许开发者编写和部署代码而不需要关注底层服务器。运行时，代码在状态为无的容器中执行，这些容器由云提供商动态管理。开发者只需关注代码和应用逻辑，而无需管理服务器或运行时环境。（AWS Lambda、Azure Functions、Google Cloud Functions）
参考文章：深度解析四大主流软件架构模型：单体架构、分布式应用、微服务与Serverless的优缺点及场景应用