什么是微服务（通俗易懂）

微服务概念

微服务架构简介

微服务架构是一种软件开发风格，它将一个应用拆分成一系列小的服务，

每个服务运行在自己的进程中，并且这些服务之间通过轻量级的通信机制（通常是HTTP API）进行交互。

这些服务围绕业务功能构建，可以独立部署，通常使用不同的编程语言和数据存储技术，并尽量减少集中式管理。

好像有点简单过头了，不过对于刚了解的同学这三句话应该也差不多了

-----------------------------------------帅气的分割线----------------------------

微服务的核心概念包括：

• 独立性：每个微服务都可以独立运行，在自己的进程中执行，独立于其他服务。
• 轻量级通信：服务间通过HTTP API等轻量级机制通信。
• 多样性：支持使用不同的编程语言和数据存储技术。
• 自治：鼓励团队独立管理自己的服务，实现快速开发和部署。

微服务的起源与发展

微服务一词最早由Martin Fowler与James Lewis于2014年提出。它是对单体架构的一种回应，旨在解决传统大型、复杂系统的扩展性差、可靠性低和高维护成本等问题。微服务架构通过将大型应用拆分成互相独立的小服务来提高系统的灵活性和可维护性。

微服务与单体架构的区别

• 模块独立性：单体架构中，所有模块耦合在一起，而微服务每个模块作为独立的服务，减少了代码量和复杂度。
• 数据存储多样性：微服务允许每个服务使用最适合的数据存储技术，而单体架构通常共用一个数据库。
• 技术多样性：微服务支持在不同服务中使用不同的开发技术，增加了开发的灵活性。

微服务架构的本质

微服务的关键在于提供一个基础架构，使得各服务能够独立部署、运行和升级，同时保持服务间的松耦合。这种架构不仅涉及技术层面，还包括统一的界面风格、权限管理、安全策略、上线过程、日志审计、调度方式和访问入口等方面，旨在实现敏捷开发和部署，以及团队间的有效协作。

适用场景

微服务适用于业务功能相对独立的系统。对于底层或高度耦合的系统（如操作系统内核、数据库系统等），由于功能间紧密相关，拆分为微服务可能不适合，因为这会导致集成工作量大增，而无法实现真正的服务独立性。

微服务开发框架

目前流行的微服务开发框架包括：

• Spring Cloud：广泛使用的微服务框架。
• Dubbo：高性能的Java RPC框架。
• Dropwizard：关注单个微服务开发的轻量级框架。
• Consul/Etcd：提供服务发现和配置的工具。

单项目的缺点

随着功能越来越复杂 单体就越来越多

团队写作成本高

系统发布效率低

系统可用性差

分布式服务优缺点

分布式架构要考虑的问题

微服务是一种经过良好设计的分布式架构方案,微服务架构特征:

团队独立可以让项目独立开发 每个项目可以用不同的技术开发 相当于开发出更独立的多套系统 从架构到三层到数据库 都可以有一定的独立性

SpringCloud的使用与作用

服务拆分与远程调用

什么时候需要拆分

拆分需要注意什么

拆分后的项目架构

两个服务独立存在 有独立的 common和 service类 并且有相应的配置文件 类似两个独立存在的服务 称为两个独立的模块module

原本的项目会根据common和service分为两部分 现在我们要将他们中的一部分提取出来组成新模块

maven聚合

工程结构有两种 一种是完全分为多个project,一种是分为多个Module并且利用maven聚合,根据项目大小决定最后拆分的模块的大小这里的代码放到一起 可以在一个代码仓库之中管理 但在部署时分开部署 maven聚合适合除了超大型项目之外的很多项目

拆分具体操作:)

第一步是进行好

模块的创建

第二步是主要的步骤 就是进行好文件的转移以及结构的再搭建

我们要将原本的pom文件中的依赖进行拷贝,拷贝到新的pom文件之中,不确定的依赖文件不要着急导入,后面有需要再进行补充,

操作:点击光标所在位置进行好相关的依赖项的导入

上面是配置文件的操作 接  下来记性结构的搭建

  我们创建一个.java文件 作为该模块的main函数 进行模块启动 从底部进行搭建

@MapperScan("com.hmall.item.mapper")

@SpringBootApplication

public class ItemApplication{

        public static void main(String[] args){

                SpringApplication.run(ItemApplicaiton.class,args);

}

创建好Application类并调用自身

创建完主函数之后

在对其他的内容继续进行创建结构如下

现在我们有了具体的分类包和启动类

配置文件修改重点是数据库对接

我们再来看看resource里的内容

配置文件同样要配置到resources文件夹之中

拷贝过去后我们进行修改

好的

我们假设有每个微服务对应的sql文件

或者就是照着原本的数据库进行好拷贝

下方都是拷贝的application.yaml的一部分 我对这里做点讲解

看一下这里的数据库的ip地址

spring.datasource.url=jdbc:mysql://<主机名>:<端口号>/<数据库名>?serverTimezone=UTC&useSSL=false 可以这么理解每个部分的含义

这里${hm.db.host}

以及下方的${hm.db.pw}

都是一种代数表达式

然后我们可以看到application-local.xml文件里面的内容

local文件里的内容对于host和password进行了详细的定义

确保了在进行多个微服务拓展是的可用性

继续回到applicaiton.xml的通用注释

这里是日志的相关的内容

在日志之中进行的配置

level就说明所有的日志的级别都是debug级别

path的配置可以让每个微服务的日志都被分别存储在不同的文件夹下

这里的log会存在项目中

为了让swagger更好地运行 那么我们这里对api-rule-resourses的内容进行好相应的调试

保证api-rule-resourses正确定位,让生成的接口文档能够正确地显示出新的微服务里的controller的内容

我们来继续

完善功能

把相关的文件拷贝过来

在导入实际的相关文件的时候

会遇到依赖报错

可以复制需要的包 把报错的import语句删除 这时候软件的自动导包功能就会发挥作用

这里有一个小细节domain->mapper->service->control的操作顺序比较方便