一、单体架构和分布式架构的区别
单体架构:将业务的所有功能集中在一个项目中开发,打成一个包部署。
优点:架构简单、部署成本低
缺点:耦合度高(维护困难、升级困难)
例如下面的huike_spring项目就是一个典型的单体架构,将huike-business(商机模块)、huike-clues(线索模块)、huike-contract(合同)等功能模块都集中在一个项目中开发。
这样的单体架构项目耦合度高,像huike_spring一样,把所有的功能模块都塞在一个服务里面。如果项目比较大的情况下,编译和打包可能都需要十几分钟,并且改动自己一处的代码都可能影响到别人的代码,具体的访问模式如下图。
二、分布式架构
分布式架构:根据业务功能对系统做拆分,每个业务功能模块作为独立项目开发,称为一个服务。例如可以把上图中商城项目中的每个模块分别拆分成支付服务、商品服务、订单服务、用户服务。
三、微服务
3.1、微服务的概念
分布式架构的最终目的就是让项目之间低耦合,不会让项目与项目之间产生过多的影响。微服务就是分布式架构的其中一种方案。每个微服务都有自己独立的数据库,每个微服务之间低耦合,可以使用自己各自擅长的技术。微服务之间产生的耦合就存在于微服务之间的调用,我们称为远程调用。
3.2、微服务的技术选型
市面上比较常用的实现微服务的两种框架:SpringCloud、Dubbo
其中Dubbo的注册中心是redis和zookeeper,这两类并不是专门做注册中心的,并且服务的远程调用采用的是Dubbo协议,而不是常见的http协议,所以这样又增加了学习成本。因此市面上常用的是SpringCloud以及SpringCloudAlibaba
3.3、企业中常见的技术选型
以下是企业中常见的技术选型,需要注意的是由3.2中的图我们可以知道SpringCloudAlibaba在服务调用是支持Dubbo协议的,所以SpringCloud可以Dubbo联合使用。
3.4、微服务的特征
单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责
自治:团队独立、技术独立、数据独立,独立部署和交付
面向服务:服务提供统一标准的接口,与语言和技术无关
隔离性强:服务调用做好隔离、容错、降级,避免出现级联问题
微服务的最终目的是为了实现各个模块之间的低耦合,每个模块之间互不影响,各自开发各自的功能模块。
下图是微服务的访问方式:每个微服务还有自己独立的数据库,不能直接访问别的微服务的数据库。
四、nacos的使用
4.1、创建两个微服务
我们分别创建两个微服务,分别为UserService和OrderService,并且他们都有自己独立的数据。
4.2、微服务中引入nacos
在cloud-demo父工程的pom文件中的<dependencyManagement>中引入SpringCloudAlibaba的依赖
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>2.2.6.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
注意<dependencyManagement>标签里面并不是强制要求子模块下载这个依赖,而是确定版本号,子模块需要这个依赖,还是需要再模块中引入这个依赖。
所以在user-service和order-service中的pom文件中引入nacos-discovery依赖
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
接下来在user-service和order-service的application.yml中添加nacos地址
spring:
cloud:
nacos:
server-addr: localhost:8848
重启两个服务后,在nacos的注册中心页面中就能看见两个服务
所以在SpringCloud中使用nacos只有两步:
1、在pom.xml文件中添加nacos的依赖
2、在对应的yml配置文件中添加nacos的地址
4.3、环境隔离
在命名空间页面点击右上角的新增命名空间
新增一个dev命名空间
这样就能在服务管理和配置管理页面新增一个dev命名空间
可以看见服务管理页面中的dev命名空间看不见任何的微服务,那是因为不同namespace之间相互隔离,不同namespace的服务互相不可见,而我刚才是把微服务注册到了public的命名空间中,在dev命名空间是看不见的。
4.4、nacos配置中心的作用
首先需要在pom.xml中引入相关的依赖
<!--nacos配置管理依赖-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
4.4.1 在nacos的配置列表页面添加Data Id为userservice-dev.yaml的配置文件
4.4.2、使用bootstrap.yaml配置文件读取nacos中的配置
首先在user-service服务中添加bootstrap.yaml配置文件,在bootstrap.yaml配置文件中设置读取nacos中配置信息的设置。
bootstrap.yaml配置文件的优先级高于application.yml配置文件的优先级,所以当项目启动的时候1、首先会加载bootstrap.yaml配置文件的信息。
2、通过bootstrap.yaml配置文件中的信息再去加载nacos中userservice-dev.yaml中的配置信息
3、最后再读取本地的application.yml中配置文件的信息。
4.4.3、 bootstrap.yaml配置文件读取的规则
${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}作为文件id,和nacos配置中心里面的Data Id相对应。本例中,就是去读取userservice-dev.yaml中的内容。
需要注意的是,微服务注册到nacos中的名字是由Spring.cloud.nacos.discovery.service决定的,不是由Spring.application.name决定的,Spring.application.name只是为了拉取nacos中相对应的Data Id中的配置
4.4.4、在微服务中拉取nacos配置的步骤
1、引入相关的依赖
2、在nacos的配置列表中设置相关配置
3、微服务中添加bootstrap.yaml配置文件