当学习吧,我有个开源项目是魔改了ruoyi-vue的,加入了我喜欢的技术以及删除了一些我认为一个系统并不一定是需要的功能,有兴趣的朋友可以先看下这个单体项目,可以更加理解等会儿要演示的流程:
https://gitee.com/Lewis-qq398529803/lewis-springboot-vue.git
不废话直接流程。
这是原本的单体项目项目结构:
首先聚合项目大家应该懂,首先就是调整成聚合项目的模样,在嵌入springcloud完成之前,不要进行功能的拆分,会导致工作量严重增加,当然老手就不用在意这句话该咋搞咋搞。
考虑到正常项目中,必然有一个专门提供接口被调用的模块,于是首先创建一个lewis-api
模块将当前所有的内容放到其中,这样首先保证项目跟之前没有大的区别也是保证能运行的情况下再做下一步。
创建完成后的项目结构:
第一步自然是引入包,其中包括了以下:
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-dependenciesartifactId>
<version>Hoxton.SR8version>
<type>pomtype>
dependency>
<dependency>
<groupId>com.alibaba.cloudgroupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discoveryartifactId>
<version>2.2.5.RELEASEversion>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-openfeignartifactId>
<version>2.1.3.RELEASEversion>
dependency>
要注意的是:spring-cloud-dependencies的版本是跟springboot的版本有兼容问题的
具体可以去看:https://spring.io/projects/spring-cloud
# Spring配置
spring:
application:
# 服务名
name: lewis-api
cloud:
# nacos配置
nacos:
discovery:
server-addr: 127.0.0.1:8848
config:
server-addr: 127.0.0.1:8848
项目启动类添加两个注解:
@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})
@EnableDiscoveryClient
@EnableFeignClients
public class LewisApplication {
public static void main(String[] args) {
SpringApplication.run(LewisApplication.class, args);
System.out.println("============================= Lewis系统启动成功 =============================\n");
}
}
到这一步,是可以跟之前单体项目一模一样的直接启动的,没有任何影响。
注意:如果你跟我用的都是idea,有几率出现缓存卡死爆红找不到主类的问题,这个时候直接退出idea,把项目的关于idea的配置文件:.iml、.idea、target等等直接物理删除,重新启动就ok了。
启动成功后,可以在nacos客户端看到刚刚配置的服务名:
虽然目前你可能有些懵,但微服务只需要你稍微改变一下下观念,就可以很简单的懂了,不保证你精通,但会用是没问题的。
以下全是个人的理解,说的不对的地方可以指出。
首先我一开始呈现的是单体项目,可以理解为编程早期的模样,因为当时的业务逻辑并不会过于复杂,代码量没上来所以单体项目更适合快速开发的效率。
但慢慢的越来越多的功能的加入,会开始发现项目开始臃肿,并且每次部署都需要对线上的版本进行停服维护等操作,以及开发过程中开发人员的相互干扰开始慢慢的体现出来。
那么这个时候就推出了模块化的思想,也就是聚合工程。但聚合工程的解耦能力也并不是特别ok,会经常需要调用其他模块的某些接口等,那么这种情况下,通常程序猿们会考虑不去调用controller层,而是去调用service层,那么这里的耦合度就开始加强了,这种方法使用多了后,聚合工程的弊端也就提现出来了。
那么这个时候微服务的思想就开始出现并且流行起来了,当我们把服务分的足够细,细到甚至某个业务都成为一个小小的服务成为一个接口的时候,任何地方都可以通过调用接口也就是类似于http请求这般调用所需要的服务,那么耦合度会大大降低,同时一个服务的宕机、重启、维护等等行为不会对整个系统有重大的影响,并且服务可以进行集群化管理,更加防止某个服务的死亡等等。
那么这时候就可以开始微服务具体需要做什么了:
首先,注册中心的概念:服务的注册与发现。或许通过字面意思也就可以似懂非懂了,总结一句话就是将一个服务当做一个对象放到注册中心,而对象就需要有一个名字,那么同一个注册中心的其他服务就可以利用这个名字,来调用自身需要的接口。
为什么需要这么操作?直接http请求不是少了这么多麻烦的事情?
原因其实很简单:
或许有很多说的不对的地方,以后或许我也会发现自己哪个地方理解是错误的,但并不影响我这一整条的逻辑是走得通的,学习过程中总有一堆堆的错误等着未来的我来嫌弃现在的自己。
所以朋友们可以借鉴,可以听着乐,毕竟我写文章通常也是写给自己看的。
下课。