MVC设计模式、单体架构、前后端分离、微服务

萌新程序员在学习web开发时一定对单体架构、前后端分离架构、MVC、微服务这几个名词不陌生，想要搞清它们之间的关系，但互联网的信息分散杂乱，有些文章之间甚至还互相冲突。

我也迷迷糊糊，但本着刨根问底的精神。下面是我多日搜索、学习而来的总结，希望对同样存在疑惑的你提供一些参考。当然本人水平有限，或许存在纰漏，也请批评指正！

正文开头，先给出每个名词的解释：

单体架构

单体架构也称为单体系统或者单体应用，就是把一种系统中的所有的功能、模块耦合在一个应用中的架构方式。

在项目中，我们通常将需求分为三个部分：数据库、服务器处理、前端展示。如果这些需求都实现在了同一个应用中，那么这个项目就是单体架构的。

基于单体架构的项目最终会打包成一个唯一的包或者war包；它会以一个进程的方式来运行。

但值得注意的是，单体架构并不能指我们理解中的单机应用。只要你的应用联网，那必然存在客户端和服务器端。

前后端分离

前后端分离是最近几年火起来的概念，当然它的诞生肯定远早于此。它其实包含两个不同的概念，互联网上很多以讹传讹，将这两个概念混淆不清。

一，它是指前后端分离开发，这是从公司开发部门的组织架构的层面上讲。与之对应的自然有前后端混合开发了。直接讲两者区别并无大用，这里要细讲一下开发的有关历史更能促进理解。

首先可以明确的史实是：过去是前后端混合开发，现在的趋势是前后端分离开发。

为什么过去是前后端混合开发？有很多原因，比如说过去程序员还是个稀缺的高端职业，人少自然能者多劳，一个程序员要干很多事，自然前端后端全都要干。同样，以前还主要是MIS（管理信息系统）的时代，一般系统或者网站的功能不多，几个人一起合作就不需要分工的很细致。

这里还要重点提一下JSP：它的特点就是允许开发人员在html中写JAVA代码。这种特殊的功能满足过去的混合开发需求，但缺点很明显，代码高度耦合，前后端甚至在同一个文件中。现在已经几乎被淘汰了，是前后端混合开发时代的眼泪。

同理PHP也会导致耦合，但它如日中天，我认为至少很长一段时间内还不会被淘汰，原因就在于PHP和MySQL之间浑然天成，效率高，开源，而且简单易用。

为什么现在提倡前后端分离开发？这其实就是程序员分工的结果。前端关注浏览器html等等，后端关注服务器和数据库等等。这种专事专人的分工提高了工作效率。而且由于众多模板、引擎、工具等，只用关注一端的程序员的门槛大大降低。现在除了一些小公司和外包企业，基本有规模的互联网行业公司都采用前后端分离。

不过额外提一嘴，虽然前后端分离是社会大势所趋，但它更利好zbj。作为学生或劳动者，即使你以就业为导向，你也至少专精一端而且熟悉另一端。

二，它指软件架构层面的前后端分离。在这种意思中，web开发的前端和后端之间采用API进行交互，俩方的程序之间完全解耦。这种软件架构也对应上面讲的前后端开发模式。实际开发中，前后端先约定传递的数据类型等信息，前端程序员写前端页面，然后调用假数据来测试前端页面的功能，等后端写好API等功能后再进行共同测试：前端通过HTTP请求调用后端提供的接口服务，后端调整接口参数和数据处理的相关功能。前后端无强依赖，如果需求变更，只要接口和参数不变，就不用两边都修改代码，开发效率高。

正因为两个不同含义之间关系紧密，才在传播过程中更容易混淆。如果你是正在学习的学生，完成某个课设作业想要采用前后端分离，那你指的应该是第二个含义。

MVC

MVC是一种经典的设计模式，Model-View-Controller，即模型-视图-控制器。M主要负责数据与模型，V主要负责显示，C主要负责交互与业务。

具体的解释其他文章和书籍之间也大差不差，应该没人对这个基础解释有疑问。

但重点是在我寻找资料时，出现了令人疑惑的两种说法：

MVC就是一种单体架构；

MVC是一种前后端分离模式；

很迷惑吧？看似两个完全相悖的说法，但结合前面的解释其实不难理解。

首先明确MVC是项目内部架构， 前后端分离是周边系统架构。

为什么MVC是一种单体架构？因为模型-视图-控制器都在一个应用内，如果你手边有一个完整的程序的话，可以打开你的IDEA project文件，你会发现你写的代码都在src文件夹里，你的代码是集中的。

为什么MVC是一种前后端分离模式？这指的是改进后的一种MVC架构，改进的MVC模式中，输入的是Ajax请求，输出的是JSON数据，比如REST就能实现此功能。这在一定程度上进行了解耦，也可以使用前后端分离。

MVC架构是我们在学习路上不可避开的课程。不论是你在学校学习的过程中，还是进入一个企业，较小的程序非常适合使用MVC，这种设计模式简洁高效，而且易于管理。比如有SSH和SSM框架都是值得学习参考的。

微服务

系统由多个服务构成，每个服务可以单独独立部署，每个服务之间是松耦合的，服务的内部是高内聚的，外部是低耦合的。高内聚就是每一个服务只关注完成一个功能。

更重要的是，微服务架构的设计只是过去架构的迭代，而不是完整的重新设计，因此我们可以看到如何使用其他架构的片段来创建标准微服务架构。

简单的说，微服务实际上是一个大型程序中集成和很多小程序，但这些小程序共用前端，而这些不同的后端服务就称为一个个微服务。我个人的理解是，微服务将M层简化，将C层变成了一个个轻量的Service.

结尾

本人水平有限，或许存在纰漏，也请批评指正！