关于mutil-moudle项目与微服务的理解

起因

在学习微服务知识以及跟着做gulimall之前, 开发上遇到的springboot项目基本都是单个模块的项目 ,

后来到学习微服务项目才动手去做多个模块的项目。

gulimall

mutil-moudle

经过

在学习springcloud的时候，课程基本都是先讲什么注册中心，配置中心，网关，负载均衡, openFeign这样的知识，导致我想当然的就任务nacos, gateway , eureka 这样的技术都是springcloud的东西, 简单的把微服务理解成了多个模块的springboot , 然后会引入一些别的技术

那么我们继续来回顾一下微服务的特点：

服务按照业务来划分，每个服务通常只专注于某一个特定的业务、所需代码量小，复杂度低、易于维护。
每个微服都可以独立开发、部署和运行，且代码量较少，因此启动和运行速度较快。
每个服务从设计、开发、测试到维护所需的团队规模小，一般 8 到 10 人，团队管理成本小。
采用单体架构的应用程序只要有任何修改，就需要重新部署整个应用才能生效，而微服务则完美地解决了这一问题。在微服架构中，某个微服务修改后，只需要重新部署这个服务即可，而不需要重新部署整个应用程序。
在微服务架构中，开发人员可以结合项目业务及团队的特点，合理地选择语言和工具进行开发和部署，不同的微服务可以使用不同的语言和工具。
微服务具备良好的可扩展性。随着业务的不断增加，微服务的体积和代码量都会急剧膨胀，此时我们可以根据业务将微服务再次进行拆分；除此之外，当用户量和并发量的增加时，我们还可以将微服务集群化部署，从而增加系统的负载能力。
微服务能够与容器（Docker）配合使用，实现快速迭代、快速构建、快速部署。
微服务具有良好的故障隔离能力，当应用程序中的某个微服发生故障时，该故障会被隔离在当前服务中，而不会波及到其他微服务造成整个系统的瘫痪。
微服务系统具有链路追踪的能力。

上面做出标记的部分可以着重理解 ,

但是springboot本身也提供了多模块的写法

在Spring Boot中使用多模块和Spring Cloud微服务理念有冲突吗？ - 知乎 (zhihu.com)
用Spring Boot开发Multi Module应用，应该包含一个Application Project和若干个Library
Project。每个Library Project包含一些服务，便于Application Project引l用(Maven dependency))调用，当然其他Library Projecti也可以引用调用

每一个Library Project的Maven POM.里面不会包含Spring Boot Maven plugin,也就是不会单
独把一个Library打包成独立的可执行Jar。只有Application Project才会有Spring Boot Maven
plugin,最终打包成的可执行Jar包含其他Library Project的依赖。这个Jar跑起来以后，所有的Java
代码都是运行在一个JVM里的，Application和Library,之间的调用是一个JVM内部的调用。

我们再来简单了解一下什么是 Monolithic（单体）应用程序

这种应用程序不是说只负责单个任务，但它们需要几个任务来完成特定的职责。在单体应用程序中，所有服务都打包成一个包，并作为一个进程运行。在单个应用程序中，用户界面、数据访问层和数据存储层是==紧密耦合==的。通常，大型团队使用单块应用程序，它们不适合基于容器的部署。

这样做的好处就是项目非常容易部署, 因为所有的组件都打包在一个包中

那么无论用Spring Boot开发Single Module还是Multi Module应用，都是Monolithic架构。

但是对于微服务项目, 他的每一个构成部分都会是一个独立的jar , 这些jar可以运行在不同的JVM中, 因此可以使用Docker隔离开, 如果这么做, 这些微服务的互相调用就是跨JVM的