单体应用
所谓的单体应该可以简单理解为，一个war包中包含了一个项目的所有功能，即所有功能对堆积在一起
在一个项目中，包含了四个模块，这4个模块都是通过mvc方式调用
这样项目过大时，会显得很臃肿，也难以扩展，因此可以采用微服务架构方式
负载均衡
当web前端在同一时刻访问java后端时，可能会出现访问量太大，服务器压力过大的问题，于是出现了负载均衡，会将controller部署多套，当web请求时，会根据负载均衡算法去得到请求的具体服务器，主要是在web前端往后端发请求这一层添加负载均衡
有多个service服务器（这多个是controll部署的多套），在nginx中配置，一个请求可以打到service1，service2，service3，service4中的任意一个，具体请求哪个，需要根据负载均衡算法决定，具体的算法如下：
1、轮询法：
轮询法：就是将用户的请求轮流分配给服务器，就像是挨个数数，轮流分配。这种算法比较简单，他具有绝对均衡的优点，但是也正是因为绝对均衡它必须付出很大的代价，例如它无法保证分配任务的合理性，无法根据服务器承受能力来分配任务。
2、随机法：
随机法：是随机选择一台服务器来分配任务。它保证了请求的分散性达到了均衡的目的。同时它是没有状态的不需要维持上次的选择状态和均衡因子，但是随着任务量的增大，它的效果趋向轮询后也会具有轮询算法的部分缺点。
3、最小连接法：
最小连接法：将任务分配给此时具有最小连接数的节点，因此它是动态负载均衡算法。一个节点收到一个任务后连接数就会加1，当节点故障时就将节点权值设置为0，不再给节点分配任务。
4、权重法：
权重法：每个服务器的权重不一样，例如service1权重为10，service2权重为2，那么在请求时，service1请求10次，service2请求2次
微服务
随着单体应用的java项目太大时，过于臃肿，可以将其拆分成多个小项目，在注册中心中进行注册，此时，图2中的函数调用会变成通过网络调用。
除了这样拆分以外，不同的controll为也会被拆分为多个小项目，具体根据业务进行拆分，其中servcie包含了图2中的service和dao等
拆分后，可以看着订单模块controller、支付模块controller、商品模块controller、用户模块controller分别为不同的小项目，这些直接可以看作是相互独立的，订单模块service、支付模块service、商品模块service、用户模块service分别看出是不同的小项目，servcie项目在部署到服务器后，会记录到注册中心（同一个service可以部署多个服务器，都有注册中心统一管理），然后controller调用service以及service之间的互相调用，都通过注册中心来实现，确定具体调用哪一个机器的service
