buyaotutou的博客

命令太多了，记不住软件安装包名字复杂，不知道去哪里找安装和部署步骤复杂，容易出错其实上述问题不仅仅是新手，即便是运维在安装、部署的时候一样会觉得麻烦、容易出错。特别是我们即将进入微服务阶段学习，微服务项目动辄就是几十台、上百台服务需要部署，有些大型项目甚至达到数万台服务。而由于每台服务器的运行环境不同，你写好的安装流程、部署脚本并不一定在每个服务器都能正常运行，经常会出错。这就给系统的部署运维带来了很多困难。那么，有没有一种技术能够避免部署对服务器环境的依赖，减少复杂的部署流程呢？

MP没有限制分页的方式的，也可以使用之前的PageHelper来实现，不过需要额外引入PageHelper的依赖，既然我们已经用来MP的依赖，我们为了方便可以直接使用MP的分页。函数的返回值也是E，其实和PageHelper一样，传的参数不光是参数还有分页结果，只不过传的时候没有结果而已，填好之后再返回带有结果的E。其中缺少的仅仅是分页条件，而分页条件不仅仅用户分页查询需要，以后其它业务也都有分页查询的需求。用的最多的就是Page，Page里面包含分页的参数，页码，每页的大小，排序方式等信息。

首先，我们定义一个单独实体类来与info字段的属性匹配。Data;@Data。

QueryWrapper和LambdaQueryWrapper通常用来构建selectdelete、update的where条件部分UpdateWrapper和LambdaUpdateWrapper通常只有在set语句比较特殊才使用尽量使用LambdaQueryWrapper和LambdaUpdateWrapper避免硬编码为什么有了MP实现自动的增删改查，以及条件构造器了，还要自定义SQL？通过两个案例解释一下。

在Mybatis上加了Plus，表示对Mybatis的加强和升级，但他不是来替代Mybatis的。MyBatisPlus想成为Mybtis最佳的合作伙伴。下面蓝色是Plus。官网链接为了简化开发而生。润物无声，只做增强不做改变，引入它不会对现有工程产生影响，如丝般顺滑。表明引入MyBatisPlus，对现有工程产生影响，之前针对Mybatis的代码可以照常运行，在开发新功能时候可以使用MyBatisPlus，或者对之前功能进行改造，都可以。效率至上。

微服务是一种软件架构风格，它是以专注于单一职责的很多小型项目为基础，组合出复杂的大型应用。之前开发项目大多采用单体架构，最大特点，开发过程中，不过多少功能，都写在一个项目中，但对于大型互联网项目不适用。随着项目功能越来越多，小项目变成大项目，开发人员成千上万，一起开发会很混乱。此时微服务就很适合了。这时候我们就要打破单体架构的边界，每一个小的项目就变成微服务，微服务在一起就构成了微服务集群，这种架构就是微服务架构。